Merge tag 'for-6.5-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
"More fixes, some of them going back to older releases and there are
fixes for hangs in stress tests regarding space caching:
- fixes and progress tracking for hangs in free space caching, found
by test generic/475
- writeback fixes, write pages in integrity mode and skip writing
pages that have been written meanwhile
- properly clear end of extent range after an error
- relocation fixes:
- fix race betwen qgroup tree creation and relocation
- detect and report invalid reloc roots"
* tag 'for-6.5-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: set cache_block_group_error if we find an error
btrfs: reject invalid reloc tree root keys with stack dump
btrfs: exit gracefully if reloc roots don't match
btrfs: avoid race between qgroup tree creation and relocation
btrfs: properly clear end of the unreserved range in cow_file_range
btrfs: don't wait for writeback on clean pages in extent_write_cache_pages
btrfs: don't stop integrity writeback too early
btrfs: wait for actual caching progress during allocation
diff --git a/.clang-format b/.clang-format
index 0d1ed87..0bbb199 100644
--- a/.clang-format
+++ b/.clang-format
@@ -254,6 +254,7 @@
- 'for_each_free_mem_range'
- 'for_each_free_mem_range_reverse'
- 'for_each_func_rsrc'
+ - 'for_each_group_device'
- 'for_each_group_evsel'
- 'for_each_group_member'
- 'for_each_hstate'
diff --git a/.gitattributes b/.gitattributes
index c9ba5bf..2325c52 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -2,3 +2,4 @@
*.[ch] diff=cpp
*.dts diff=dts
*.dts[io] diff=dts
+*.rs diff=rust
diff --git a/.gitignore b/.gitignore
index 7f86e08..9fd4c95 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,7 +16,6 @@
*.bin
*.bz2
*.c.[012]*.*
-*.cover
*.dt.yaml
*.dtb
*.dtbo
@@ -34,7 +33,6 @@
*.lz4
*.lzma
*.lzo
-*.mbx
*.mod
*.mod.c
*.o
@@ -51,7 +49,6 @@
*.symversions
*.tab.[ch]
*.tar
-*.usyms
*.xz
*.zst
Module.symvers
@@ -112,7 +109,6 @@
#
/include/config/
/include/generated/
-/include/ksym/
/arch/*/include/generated/
# stgit generated dirs
diff --git a/.mailmap b/.mailmap
index 650689d..5dd3181 100644
--- a/.mailmap
+++ b/.mailmap
@@ -5,14 +5,17 @@
# same person appearing not to be so or badly displayed. Also allows for
# old email addresses to map to new email addresses.
#
-# For format details, see "MAPPING AUTHORS" in "man git-shortlog".
+# For format details, see "man gitmailmap" or "MAPPING AUTHORS" in
+# "man git-shortlog" on older systems.
#
# Please keep this list dictionary sorted.
#
Aaron Durbin <adurbin@google.com>
Abel Vesa <abelvesa@kernel.org> <abel.vesa@nxp.com>
Abel Vesa <abelvesa@kernel.org> <abelvesa@gmail.com>
+Abhijeet Dharmapurikar <quic_adharmap@quicinc.com> <adharmap@codeaurora.org>
Abhinav Kumar <quic_abhinavk@quicinc.com> <abhinavk@codeaurora.org>
+Ahmad Masri <quic_amasri@quicinc.com> <amasri@codeaurora.org>
Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.com>
Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com>
@@ -29,6 +32,7 @@
Alexander Mikhalitsyn <alexander@mihalicyn.com> <aleksandr.mikhalitsyn@canonical.com>
Alexandre Belloni <alexandre.belloni@bootlin.com> <alexandre.belloni@free-electrons.com>
Alexandre Ghiti <alex@ghiti.fr> <alexandre.ghiti@canonical.com>
+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>
@@ -36,8 +40,11 @@
Alex Shi <alexs@kernel.org> <alex.shi@intel.com>
Alex Shi <alexs@kernel.org> <alex.shi@linaro.org>
Alex Shi <alexs@kernel.org> <alex.shi@linux.alibaba.com>
+Aloka Dixit <quic_alokad@quicinc.com> <alokad@codeaurora.org>
Al Viro <viro@ftp.linux.org.uk>
Al Viro <viro@zenIV.linux.org.uk>
+Amit Blay <quic_ablay@quicinc.com> <ablay@codeaurora.org>
+Amit Nischal <quic_anischal@quicinc.com> <anischal@codeaurora.org>
Andi Kleen <ak@linux.intel.com> <ak@suse.de>
Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>
Andreas Herrmann <aherrman@de.ibm.com>
@@ -53,6 +60,8 @@
Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com>
André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com>
Andy Adamson <andros@citi.umich.edu>
+Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org>
+Anirudh Ghayal <quic_aghayal@quicinc.com> <aghayal@codeaurora.org>
Antoine Tenart <atenart@kernel.org> <antoine.tenart@bootlin.com>
Antoine Tenart <atenart@kernel.org> <antoine.tenart@free-electrons.com>
Antonio Ospite <ao2@ao2.it> <ao2@amarulasolutions.com>
@@ -61,15 +70,25 @@
Ard Biesheuvel <ardb@kernel.org> <ard.biesheuvel@linaro.org>
Arnaud Patard <arnaud.patard@rtp-net.org>
Arnd Bergmann <arnd@arndb.de>
+Arun Kumar Neelakantam <quic_aneela@quicinc.com> <aneela@codeaurora.org>
+Ashok Raj Nagarajan <quic_arnagara@quicinc.com> <arnagara@codeaurora.org>
+Ashwin Chaugule <quic_ashwinc@quicinc.com> <ashwinc@codeaurora.org>
+Asutosh Das <quic_asutoshd@quicinc.com> <asutoshd@codeaurora.org>
Atish Patra <atishp@atishpatra.org> <atish.patra@wdc.com>
+Avaneesh Kumar Dwivedi <quic_akdwived@quicinc.com> <akdwived@codeaurora.org>
Axel Dyks <xl@xlsigned.net>
Axel Lin <axel.lin@gmail.com>
+Balakrishna Godavarthi <quic_bgodavar@quicinc.com> <bgodavar@codeaurora.org>
+Banajit Goswami <quic_bgoswami@quicinc.com> <bgoswami@codeaurora.org>
+Baochen Qiang <quic_bqiang@quicinc.com> <bqiang@codeaurora.org>
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@linaro.org>
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@spreadtrum.com>
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@unisoc.com>
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang7@gmail.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
+Ben Dooks <ben-linux@fluff.org> <ben.dooks@simtec.co.uk>
+Ben Dooks <ben-linux@fluff.org> <ben.dooks@sifive.com>
Ben Gardner <bgardner@wabtec.com>
Ben M Cahill <ben.m.cahill@intel.com>
Ben Widawsky <bwidawsk@kernel.org> <ben@bwidawsk.net>
@@ -90,12 +109,15 @@
Brian King <brking@us.ibm.com>
Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.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>
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
Chao Yu <chao@kernel.org> <yuchao0@huawei.com>
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessm.com>
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org>
+Chris Lew <quic_clew@quicinc.com> <clew@codeaurora.org>
Christian Borntraeger <borntraeger@linux.ibm.com> <borntraeger@de.ibm.com>
Christian Borntraeger <borntraeger@linux.ibm.com> <cborntra@de.ibm.com>
Christian Borntraeger <borntraeger@linux.ibm.com> <borntrae@de.ibm.com>
@@ -116,7 +138,10 @@
Daniel Borkmann <daniel@iogearbox.net> <dborkman@redhat.com>
Daniel Borkmann <daniel@iogearbox.net> <dxchgb@gmail.com>
David Brownell <david-b@pacbell.net>
+David Collins <quic_collinsd@quicinc.com> <collinsd@codeaurora.org>
David Woodhouse <dwmw2@shinybook.infradead.org>
+Dedy Lansky <quic_dlansky@quicinc.com> <dlansky@codeaurora.org>
+Deepak Kumar Singh <quic_deesin@quicinc.com> <deesin@codeaurora.org>
Dengcheng Zhu <dzhu@wavecomp.com> <dczhu@mips.com>
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@gmail.com>
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@imgtec.com>
@@ -133,6 +158,7 @@
Domen Puncer <domen@coderock.org>
Douglas Gilbert <dougg@torque.net>
Ed L. Cashin <ecashin@coraid.com>
+Elliot Berman <quic_eberman@quicinc.com> <eberman@codeaurora.org>
Enric Balletbo i Serra <eballetbo@kernel.org> <enric.balletbo@collabora.com>
Enric Balletbo i Serra <eballetbo@kernel.org> <eballetbo@iseebcn.com>
Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
@@ -145,6 +171,7 @@
Felipe W Damasio <felipewd@terra.com.br>
Felix Kuhling <fxkuehl@gmx.de>
Felix Moeller <felix@derklecks.de>
+Fenglin Wu <quic_fenglinw@quicinc.com> <fenglinw@codeaurora.org>
Filipe Lautert <filipe@icewall.org>
Finn Thain <fthain@linux-m68k.org> <fthain@telegraphics.com.au>
Franck Bui-Huu <vagabon.xyz@gmail.com>
@@ -168,20 +195,29 @@
Gregory CLEMENT <gregory.clement@bootlin.com> <gregory.clement@free-electrons.com>
Guilherme G. Piccoli <kernel@gpiccoli.net> <gpiccoli@linux.vnet.ibm.com>
Guilherme G. Piccoli <kernel@gpiccoli.net> <gpiccoli@canonical.com>
+Gokul Sriram Palanisamy <quic_gokulsri@quicinc.com> <gokulsri@codeaurora.org>
+Govindaraj Saminathan <quic_gsamin@quicinc.com> <gsamin@codeaurora.org>
Guo Ren <guoren@kernel.org> <guoren@linux.alibaba.com>
Guo Ren <guoren@kernel.org> <ren_guo@c-sky.com>
+Guru Das Srinagesh <quic_gurus@quicinc.com> <gurus@codeaurora.org>
Gustavo Padovan <gustavo@las.ic.unicamp.br>
Gustavo Padovan <padovan@profusion.mobi>
Hanjun Guo <guohanjun@huawei.com> <hanjun.guo@linaro.org>
Heiko Carstens <hca@linux.ibm.com> <h.carstens@de.ibm.com>
Heiko Carstens <hca@linux.ibm.com> <heiko.carstens@de.ibm.com>
+Heiko Stuebner <heiko@sntech.de> <heiko.stuebner@bqreaders.com>
+Heiko Stuebner <heiko@sntech.de> <heiko.stuebner@theobroma-systems.com>
+Heiko Stuebner <heiko@sntech.de> <heiko.stuebner@vrull.eu>
Henk Vergonet <Henk.Vergonet@gmail.com>
Henrik Kretzschmar <henne@nachtwindheim.de>
Henrik Rydberg <rydberg@bitmath.org>
Herbert Xu <herbert@gondor.apana.org.au>
Huacai Chen <chenhuacai@kernel.org> <chenhc@lemote.com>
Huacai Chen <chenhuacai@kernel.org> <chenhuacai@loongson.cn>
+J. Bruce Fields <bfields@fieldses.org> <bfields@redhat.com>
+J. Bruce Fields <bfields@fieldses.org> <bfields@citi.umich.edu>
Jacob Shin <Jacob.Shin@amd.com>
+Jack Pham <quic_jackp@quicinc.com> <jackp@codeaurora.org>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@google.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk.kim@samsung.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
@@ -209,10 +245,12 @@
Jayachandran C <c.jayachandran@gmail.com> <jnair@caviumnetworks.com>
<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>
Jean Tourrilhes <jt@hpl.hp.com>
+Jeevan Shriram <quic_jshriram@quicinc.com> <jshriram@codeaurora.org>
Jeff Garzik <jgarzik@pretzel.yyz.us>
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
+Jeffrey Hugo <quic_jhugo@quicinc.com> <jhugo@codeaurora.org>
Jens Axboe <axboe@kernel.dk> <axboe@suse.de>
Jens Axboe <axboe@kernel.dk> <jens.axboe@oracle.com>
Jens Axboe <axboe@kernel.dk> <axboe@fb.com>
@@ -220,6 +258,7 @@
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
+Jilai Wang <quic_jilaiw@quicinc.com> <jilaiw@codeaurora.org>
Jiri Pirko <jiri@resnulli.us> <jiri@nvidia.com>
Jiri Pirko <jiri@resnulli.us> <jiri@mellanox.com>
Jiri Pirko <jiri@resnulli.us> <jpirko@redhat.com>
@@ -230,14 +269,17 @@
Jiri Slaby <jirislaby@kernel.org> <xslaby@fi.muni.cz>
Jisheng Zhang <jszhang@kernel.org> <jszhang@marvell.com>
Jisheng Zhang <jszhang@kernel.org> <Jisheng.Zhang@synaptics.com>
+Jishnu Prakash <quic_jprakash@quicinc.com> <jprakash@codeaurora.org>
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
John Crispin <john@phrozen.org> <blogic@openwrt.org>
+John Fastabend <john.fastabend@gmail.com> <john.r.fastabend@intel.com>
John Keeping <john@keeping.me.uk> <john@metanate.com>
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
John Stultz <johnstul@us.ibm.com>
<jon.toppins+linux@gmail.com> <jtoppins@cumulusnetworks.com>
<jon.toppins+linux@gmail.com> <jtoppins@redhat.com>
+Jonas Gorski <jonas.gorski@gmail.com> <jogo@openwrt.org>
Jordan Crouse <jordan@cosmicpenguin.net> <jcrouse@codeaurora.org>
<josh@joshtriplett.org> <josh@freedesktop.org>
<josh@joshtriplett.org> <josh@kernel.org>
@@ -246,6 +288,7 @@
<josh@joshtriplett.org> <josht@vnet.ibm.com>
Josh Poimboeuf <jpoimboe@kernel.org> <jpoimboe@redhat.com>
Josh Poimboeuf <jpoimboe@kernel.org> <jpoimboe@us.ibm.com>
+Jouni Malinen <quic_jouni@quicinc.com> <jouni@codeaurora.org>
Juha Yrjola <at solidboot.com>
Juha Yrjola <juha.yrjola@nokia.com>
Juha Yrjola <juha.yrjola@solidboot.com>
@@ -253,6 +296,8 @@
Iskren Chernev <me@iskren.info> <iskren.chernev@gmail.com>
Kalle Valo <kvalo@kernel.org> <kvalo@codeaurora.org>
Kalyan Thota <quic_kalyant@quicinc.com> <kalyan_t@codeaurora.org>
+Karthikeyan Periyasamy <quic_periyasa@quicinc.com> <periyasa@codeaurora.org>
+Kathiravan T <quic_kathirav@quicinc.com> <kathirav@codeaurora.org>
Kay Sievers <kay.sievers@vrfy.org>
Kees Cook <keescook@chromium.org> <kees.cook@canonical.com>
Kees Cook <keescook@chromium.org> <keescook@google.com>
@@ -261,6 +306,8 @@
Keith Busch <kbusch@kernel.org> <keith.busch@intel.com>
Keith Busch <kbusch@kernel.org> <keith.busch@linux.intel.com>
Kenneth W Chen <kenneth.w.chen@intel.com>
+Kenneth Westfield <quic_kwestfie@quicinc.com> <kwestfie@codeaurora.org>
+Kiran Gunda <quic_kgunda@quicinc.com> <kgunda@codeaurora.org>
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
@@ -269,8 +316,13 @@
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
Krzysztof Kozlowski <krzk@kernel.org> <krzysztof.kozlowski@canonical.com>
+Kshitiz Godara <quic_kgodara@quicinc.com> <kgodara@codeaurora.org>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Kuogee Hsieh <quic_khsieh@quicinc.com> <khsieh@codeaurora.org>
+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>
Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com>
Leonard Göhrs <l.goehrs@pengutronix.de>
@@ -278,25 +330,34 @@
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
Leon Romanovsky <leon@kernel.org> <leonro@nvidia.com>
+Liam Mark <quic_lmark@quicinc.com> <lmark@codeaurora.org>
Linas Vepstas <linas@austin.ibm.com>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
<linux-hardening@vger.kernel.org> <kernel-hardening@lists.openwall.com>
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
+Lior David <quic_liord@quicinc.com> <liord@codeaurora.org>
Lorenzo Pieralisi <lpieralisi@kernel.org> <lorenzo.pieralisi@arm.com>
Luca Ceresoli <luca.ceresoli@bootlin.com> <luca@lucaceresoli.net>
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
+Luo Jie <quic_luoj@quicinc.com> <luoj@codeaurora.org>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
Maciej W. Rozycki <macro@orcam.me.uk> <macro@linux-mips.org>
+Maharaja Kennadyrajan <quic_mkenna@quicinc.com> <mkenna@codeaurora.org>
+Maheshwar Ajja <quic_majja@quicinc.com> <majja@codeaurora.org>
+Malathi Gottam <quic_mgottam@quicinc.com> <mgottam@codeaurora.org>
+Manikanta Pubbisetty <quic_mpubbise@quicinc.com> <mpubbise@codeaurora.org>
Manivannan Sadhasivam <mani@kernel.org> <manivannanece23@gmail.com>
Manivannan Sadhasivam <mani@kernel.org> <manivannan.sadhasivam@linaro.org>
+Manoj Basapathi <quic_manojbm@quicinc.com> <manojbm@codeaurora.org>
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
Marek Behún <kabel@kernel.org> <marek.behun@nic.cz>
Marek Behún <kabel@kernel.org> Marek Behun <marek.behun@nic.cz>
Mark Brown <broonie@sirena.org.uk>
Mark Starovoytov <mstarovo@pm.me> <mstarovoitov@marvell.com>
+Markus Schneider-Pargmann <msp@baylibre.com> <mpa@pengutronix.de>
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@puri.sm>
@@ -319,6 +380,7 @@
Matt Ranostay <mranostay@gmail.com> Matthew Ranostay <mranostay@embeddedalley.com>
Matt Ranostay <mranostay@gmail.com> <matt.ranostay@intel.com>
Matt Redfearn <matt.redfearn@mips.com> <matt.redfearn@imgtec.com>
+Maulik Shah <quic_mkshah@quicinc.com> <mkshah@codeaurora.org>
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@infradead.org>
@@ -328,9 +390,13 @@
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
Maxim Mikityanskiy <maxtram95@gmail.com> <maximmi@mellanox.com>
Maxim Mikityanskiy <maxtram95@gmail.com> <maximmi@nvidia.com>
+Maxime Ripard <mripard@kernel.org> <maxime@cerno.tech>
Maxime Ripard <mripard@kernel.org> <maxime.ripard@bootlin.com>
Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
+Maya Erez <quic_merez@quicinc.com> <merez@codeaurora.org>
Mayuresh Janorkar <mayur@ti.com>
+Md Sadre Alam <quic_mdalam@quicinc.com> <mdalam@codeaurora.org>
+Miaoqing Pan <quic_miaoqing@quicinc.com> <miaoqing@codeaurora.org>
Michael Buesch <m@bues.ch>
Michal Simek <michal.simek@amd.com> <michal.simek@xilinx.com>
Michel Dänzer <michel@tungstengraphics.com>
@@ -341,6 +407,7 @@
Mike Rapoport <rppt@kernel.org> <mike@compulab.co.il>
Mike Rapoport <rppt@kernel.org> <mike.rapoport@gmail.com>
Mike Rapoport <rppt@kernel.org> <rppt@linux.ibm.com>
+Mike Tipton <quic_mdtipton@quicinc.com> <mdtipton@codeaurora.org>
Miodrag Dinic <miodrag.dinic@mips.com> <miodrag.dinic@imgtec.com>
Miquel Raynal <miquel.raynal@bootlin.com> <miquel.raynal@free-electrons.com>
Mitesh shah <mshah@teja.com>
@@ -349,9 +416,13 @@
Morten Welinder <welinder@anemone.rentec.com>
Morten Welinder <welinder@darter.rentec.com>
Morten Welinder <welinder@troll.com>
+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>
Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy.com>
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
+Neeraj Upadhyay <quic_neeraju@quicinc.com> <neeraju@codeaurora.org>
Neil Armstrong <neil.armstrong@linaro.org> <narmstrong@baylibre.com>
Nguyen Anh Quynh <aquynh@gmail.com>
Nicholas Piggin <npiggin@gmail.com> <npiggen@suse.de>
@@ -370,6 +441,7 @@
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@cumulusnetworks.com>
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@nvidia.com>
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@isovalent.com>
+Odelu Kukatla <quic_okukatla@quicinc.com> <okukatla@codeaurora.org>
Oleksandr Natalenko <oleksandr@natalenko.name> <oleksandr@redhat.com>
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
@@ -377,6 +449,7 @@
Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
Oliver Upton <oliver.upton@linux.dev> <oupton@google.com>
+Oza Pawandeep <quic_poza@quicinc.com> <poza@codeaurora.org>
Pali Rohár <pali@kernel.org> <pali.rohar@gmail.com>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Patrick Mochel <mochel@digitalimplant.org>
@@ -388,11 +461,14 @@
Paul E. McKenney <paulmck@kernel.org> <paulmck@us.ibm.com>
Paul Mackerras <paulus@ozlabs.org> <paulus@samba.org>
Paul Mackerras <paulus@ozlabs.org> <paulus@au1.ibm.com>
+Pavankumar Kondeti <quic_pkondeti@quicinc.com> <pkondeti@codeaurora.org>
Peter A Jonsson <pj@ludd.ltu.se>
Peter Oruba <peter.oruba@amd.com>
Peter Oruba <peter@oruba.de>
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
Praveen BP <praveenbp@ti.com>
+Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com> <pradeepc@codeaurora.org>
+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>
@@ -401,10 +477,16 @@
Rafael J. Wysocki <rjw@rjwysocki.net> <rjw@sisk.pl>
Rajeev Nandan <quic_rajeevny@quicinc.com> <rajeevny@codeaurora.org>
Rajendra Nayak <quic_rjendra@quicinc.com> <rnayak@codeaurora.org>
+Rajeshwari Ravindra Kamble <quic_rkambl@quicinc.com> <rkambl@codeaurora.org>
+Raju P.L.S.S.S.N <quic_rplsssn@quicinc.com> <rplsssn@codeaurora.org>
Rajesh Shah <rajesh.shah@intel.com>
+Rakesh Pillai <quic_pillair@quicinc.com> <pillair@codeaurora.org>
Ralf Baechle <ralf@linux-mips.org>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
+Ram Chandra Jangir <quic_rjangir@quicinc.com> <rjangir@codeaurora.org>
Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
+Ravi Kumar Bokka <quic_rbokka@quicinc.com> <rbokka@codeaurora.org>
+Ravi Kumar Siddojigari <quic_rsiddoji@quicinc.com> <rsiddoji@codeaurora.org>
Rémi Denis-Courmont <rdenis@simphalempin.com>
Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com>
Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org>
@@ -413,6 +495,7 @@
Richard Leitner <richard.leitner@linux.dev> <me@g0hl1n.net>
Richard Leitner <richard.leitner@linux.dev> <richard.leitner@skidata.com>
Robert Foss <rfoss@kernel.org> <robert.foss@linaro.org>
+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>
@@ -430,22 +513,35 @@
Santosh Shilimkar <ssantosh@kernel.org>
Sarangdhar Joshi <spjoshi@codeaurora.org>
Sascha Hauer <s.hauer@pengutronix.de>
+Sahitya Tummala <quic_stummala@quicinc.com> <stummala@codeaurora.org>
+Sathishkumar Muruganandam <quic_murugana@quicinc.com> <murugana@codeaurora.org>
Satya Priya <quic_c_skakit@quicinc.com> <skakit@codeaurora.org>
S.Çağlar Onur <caglar@pardus.org.tr>
+Sayali Lokhande <quic_sayalil@quicinc.com> <sayalil@codeaurora.org>
Sean Christopherson <seanjc@google.com> <sean.j.christopherson@intel.com>
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
+Sean Tranchetti <quic_stranche@quicinc.com> <stranche@codeaurora.org>
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
Sedat Dilek <sedat.dilek@gmail.com> <sedat.dilek@credativ.de>
+Senthilkumar N L <quic_snlakshm@quicinc.com> <snlakshm@codeaurora.org>
Seth Forshee <sforshee@kernel.org> <seth.forshee@canonical.com>
Shannon Nelson <shannon.nelson@amd.com> <snelson@pensando.io>
+Shannon Nelson <shannon.nelson@amd.com> <shannon.nelson@intel.com>
+Shannon Nelson <shannon.nelson@amd.com> <shannon.nelson@oracle.com>
+Sharath Chandra Vurukala <quic_sharathv@quicinc.com> <sharathv@codeaurora.org>
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com>
Shuah Khan <shuah@kernel.org> <shuah.khan@hp.com>
Shuah Khan <shuah@kernel.org> <shuahkh@osg.samsung.com>
Shuah Khan <shuah@kernel.org> <shuah.kh@samsung.com>
+Sibi Sankar <quic_sibis@quicinc.com> <sibis@codeaurora.org>
+Sid Manning <quic_sidneym@quicinc.com> <sidneym@codeaurora.org>
Simon Arlott <simon@octiron.net> <simon@fire.lp0.eu>
Simon Kelley <simon@thekelleys.org.uk>
+Sricharan Ramabadhran <quic_srichara@quicinc.com> <sricharan@codeaurora.org>
+Srinivas Ramana <quic_sramana@quicinc.com> <sramana@codeaurora.org>
+Sriram R <quic_srirrama@quicinc.com> <srirrama@codeaurora.org>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
Stephen Hemminger <stephen@networkplumber.org> <shemminger@linux-foundation.org>
Stephen Hemminger <stephen@networkplumber.org> <shemminger@osdl.org>
@@ -453,22 +549,30 @@
Stephen Hemminger <stephen@networkplumber.org> <sthemmin@vyatta.com>
Steve Wise <larrystevenwise@gmail.com> <swise@chelsio.com>
Steve Wise <larrystevenwise@gmail.com> <swise@opengridcomputing.com>
-Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
+Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com> <subashab@codeaurora.org>
+Subbaraman Narayanamurthy <quic_subbaram@quicinc.com> <subbaram@codeaurora.org>
Subhash Jadavani <subhashj@codeaurora.org>
+Sudarshan Rajagopalan <quic_sudaraja@quicinc.com> <sudaraja@codeaurora.org>
Sudeep Holla <sudeep.holla@arm.com> Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Sumit Semwal <sumit.semwal@ti.com>
+Surabhi Vishnoi <quic_svishnoi@quicinc.com> <svishnoi@codeaurora.org>
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
+Tamizh Chelvam Raja <quic_tamizhr@quicinc.com> <tamizhr@codeaurora.org>
+Taniya Das <quic_tdas@quicinc.com> <tdas@codeaurora.org>
Tejun Heo <htejun@gmail.com>
Thomas Graf <tgraf@suug.ch>
Thomas Körper <socketcan@esd.eu> <thomas.koerper@esd.eu>
Thomas Pedersen <twp@codeaurora.org>
Tiezhu Yang <yangtiezhu@loongson.cn> <kernelpatch@126.com>
+Tingwei Zhang <quic_tingwei@quicinc.com> <tingwei@codeaurora.org>
+Tirupathi Reddy <quic_tirupath@quicinc.com> <tirupath@codeaurora.org>
Tobias Klauser <tklauser@distanz.ch> <tobias.klauser@gmail.com>
Tobias Klauser <tklauser@distanz.ch> <klto@zhaw.ch>
Tobias Klauser <tklauser@distanz.ch> <tklauser@nuerscht.ch>
Tobias Klauser <tklauser@distanz.ch> <tklauser@xenon.tklauser.home>
Todor Tomov <todor.too@gmail.com> <todor.tomov@linaro.org>
Tony Luck <tony.luck@intel.com>
+Trilok Soni <quic_tsoni@quicinc.com> <tsoni@codeaurora.org>
TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>
TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
@@ -481,11 +585,17 @@
Uwe Kleine-König <ukl@pengutronix.de>
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
+Vara Reddy <quic_varar@quicinc.com> <varar@codeaurora.org>
+Varadarajan Narayanan <quic_varada@quicinc.com> <varada@codeaurora.org>
+Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com> <vthiagar@codeaurora.org>
Vasily Averin <vasily.averin@linux.dev> <vvs@virtuozzo.com>
Vasily Averin <vasily.averin@linux.dev> <vvs@openvz.org>
Vasily Averin <vasily.averin@linux.dev> <vvs@parallels.com>
Vasily Averin <vasily.averin@linux.dev> <vvs@sw.ru>
Valentin Schneider <vschneid@redhat.com> <valentin.schneider@arm.com>
+Veera Sundaram Sankaran <quic_veeras@quicinc.com> <veeras@codeaurora.org>
+Veerabhadrarao Badiganti <quic_vbadigan@quicinc.com> <vbadigan@codeaurora.org>
+Venkateswara Naralasetty <quic_vnaralas@quicinc.com> <vnaralas@codeaurora.org>
Vikash Garodia <quic_vgarodia@quicinc.com> <vgarodia@codeaurora.org>
Vinod Koul <vkoul@kernel.org> <vinod.koul@intel.com>
Vinod Koul <vkoul@kernel.org> <vinod.koul@linux.intel.com>
@@ -495,11 +605,14 @@
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>
+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>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
WeiXiong Liao <gmpy.liaowx@gmail.com> <liaoweixiong@allwinnertech.com>
+Wen Gong <quic_wgong@quicinc.com> <wgong@codeaurora.org>
+Wesley Cheng <quic_wcheng@quicinc.com> <wcheng@codeaurora.org>
Will Deacon <will@kernel.org> <will.deacon@arm.com>
Wolfram Sang <wsa@kernel.org> <w.sang@pengutronix.de>
Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>
diff --git a/CREDITS b/CREDITS
index de7e4db..8b48820 100644
--- a/CREDITS
+++ b/CREDITS
@@ -383,6 +383,12 @@
W: http://tomas.nocrew.org/
D: dsp56k device driver
+N: Srivatsa S. Bhat
+E: srivatsa@csail.mit.edu
+D: Maintainer of Generic Paravirt-Ops subsystem
+D: Maintainer of VMware hypervisor interface
+D: Maintainer of VMware virtual PTP clock driver (ptp_vmw)
+
N: Ross Biro
E: ross.biro@gmail.com
D: Original author of the Linux networking code
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/obsolete/o2cb
index fe7e45e..8f39b59 100644
--- a/Documentation/ABI/obsolete/o2cb
+++ b/Documentation/ABI/obsolete/o2cb
@@ -1,11 +1,11 @@
What: /sys/o2cb
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Was renamed to /sys/fs/u2cb/
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
diff --git a/Documentation/ABI/removed/o2cb b/Documentation/ABI/removed/o2cb
index 20c91ad..61cff238 100644
--- a/Documentation/ABI/removed/o2cb
+++ b/Documentation/ABI/removed/o2cb
@@ -1,10 +1,10 @@
What: /sys/o2cb symlink
Date: May 2011
KernelVersion: 3.0
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is
removed when new versions of ocfs2-tools which know to look
in /sys/fs/o2cb are sufficiently prevalent. Don't code new
software to look here, it should try /sys/fs/o2cb instead.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
diff --git a/Documentation/ABI/stable/o2cb b/Documentation/ABI/stable/o2cb
index b62a967..3a83b5c 100644
--- a/Documentation/ABI/stable/o2cb
+++ b/Documentation/ABI/stable/o2cb
@@ -1,10 +1,10 @@
What: /sys/fs/o2cb/
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
diff --git a/Documentation/ABI/stable/sysfs-platform-wmi-bmof b/Documentation/ABI/stable/sysfs-platform-wmi-bmof
new file mode 100644
index 0000000..a786504
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-platform-wmi-bmof
@@ -0,0 +1,7 @@
+What: /sys/bus/wmi/devices/05901221-D566-11D1-B2F0-00A0C9062910[-X]/bmof
+Date: Jun 2017
+KernelVersion: 4.13
+Description:
+ Binary MOF metadata used to decribe the details of available ACPI WMI interfaces.
+
+ See Documentation/wmi/devices/wmi-bmof.rst for details.
diff --git a/Documentation/ABI/testing/debugfs-dell-wmi-ddv b/Documentation/ABI/testing/debugfs-dell-wmi-ddv
index fbcc5d6..81cfc78 100644
--- a/Documentation/ABI/testing/debugfs-dell-wmi-ddv
+++ b/Documentation/ABI/testing/debugfs-dell-wmi-ddv
@@ -3,19 +3,32 @@
KernelVersion: 6.1
Contact: Armin Wolf <W_Armin@gmx.de>
Description:
- This file contains the contents of the fan sensor information buffer,
- which contains fan sensor entries and a terminating character (0xFF).
+ This file contains the contents of the fan sensor information
+ buffer, which contains fan sensor entries and a terminating
+ character (0xFF).
- Each fan sensor entry consists of three bytes with an unknown meaning,
- interested people may use this file for reverse-engineering.
+ Each fan sensor entry contains:
+
+ - fan type (single byte)
+ - fan speed in RPM (two bytes, little endian)
+
+ See Documentation/wmi/devices/dell-wmi-ddv.rst for details.
What: /sys/kernel/debug/dell-wmi-ddv-<wmi_device_name>/thermal_sensor_information
Date: September 2022
KernelVersion: 6.1
Contact: Armin Wolf <W_Armin@gmx.de>
Description:
- This file contains the contents of the thermal sensor information buffer,
- which contains thermal sensor entries and a terminating character (0xFF).
+ This file contains the contents of the thermal sensor information
+ buffer, which contains thermal sensor entries and a terminating
+ character (0xFF).
- Each thermal sensor entry consists of five bytes with an unknown meaning,
- interested people may use this file for reverse-engineering.
+ Each thermal sensor entry contains:
+
+ - thermal type (single byte)
+ - current temperature (single byte)
+ - min. temperature (single byte)
+ - max. temperature (single byte)
+ - unknown field (single byte)
+
+ See Documentation/wmi/devices/dell-wmi-ddv.rst for details.
diff --git a/Documentation/ABI/testing/sysfs-block-device b/Documentation/ABI/testing/sysfs-block-device
index 7ac7b19..2d543cf 100644
--- a/Documentation/ABI/testing/sysfs-block-device
+++ b/Documentation/ABI/testing/sysfs-block-device
@@ -95,3 +95,25 @@
This file does not exist if the HBA driver does not implement
support for the SATA NCQ priority feature, regardless of the
device support for this feature.
+
+
+What: /sys/block/*/device/cdl_supported
+Date: May, 2023
+KernelVersion: v6.5
+Contact: linux-scsi@vger.kernel.org
+Description:
+ (RO) Indicates if the device supports the command duration
+ limits feature found in some ATA and SCSI devices.
+
+
+What: /sys/block/*/device/cdl_enable
+Date: May, 2023
+KernelVersion: v6.5
+Contact: linux-scsi@vger.kernel.org
+Description:
+ (RW) For a device supporting the command duration limits
+ feature, write to the file to turn on or off the feature.
+ By default this feature is turned off.
+ Writing "1" to this file enables the use of command duration
+ limits for read and write commands in the kernel and turns on
+ the feature on the device. Writing "0" disables the feature.
diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter
index 1417c42..dc3b3a5 100644
--- a/Documentation/ABI/testing/sysfs-bus-counter
+++ b/Documentation/ABI/testing/sysfs-bus-counter
@@ -90,6 +90,60 @@
counter does not freeze at the boundary points, but
counts continuously throughout.
+ interrupt on terminal count:
+ The output signal is initially low, and will remain low
+ until the counter reaches zero. The output signal then
+ goes high and remains high until a new preset value is
+ set.
+
+ hardware retriggerable one-shot:
+ The output signal is initially high. The output signal
+ will go low by a trigger input signal, and will remain
+ low until the counter reaches zero. The output will then
+ go high and remain high until the next trigger. A
+ trigger results in loading the counter to the preset
+ value and setting the output signal low, thus starting
+ the one-shot pulse.
+
+ rate generator:
+ The output signal is initially high. When the counter
+ has decremented to 1, the output signal goes low for one
+ clock pulse. The output signal then goes high again, the
+ counter is reloaded to the preset value, and the process
+ repeats in a periodic manner as such.
+
+ square wave mode:
+ The output signal is initially high.
+
+ If the initial count is even, the counter is decremented
+ by two on succeeding clock pulses. When the count
+ expires, the output signal changes value and the
+ counter is reloaded to the preset value. The process
+ repeats in periodic manner as such.
+
+ If the initial count is odd, the initial count minus one
+ (an even number) is loaded and then is decremented by
+ two on succeeding clock pulses. One clock pulse after
+ the count expires, the output signal goes low and the
+ counter is reloaded to the preset value minus one.
+ Succeeding clock pulses decrement the count by two. When
+ the count expires, the output goes high again and the
+ counter is reloaded to the preset value minus one. The
+ process repeats in a periodic manner as such.
+
+ software triggered strobe:
+ The output signal is initially high. When the count
+ expires, the output will go low for one clock pulse and
+ then go high again. The counting sequence is "triggered"
+ by setting the preset value.
+
+ hardware triggered strobe:
+ The output signal is initially high. Counting is started
+ by a trigger input signal. When the count expires, the
+ output signal will go low for one clock pulse and then
+ go high again. A trigger results in loading the counter
+ to the preset value.
+
What: /sys/bus/counter/devices/counterX/countY/count_mode_available
What: /sys/bus/counter/devices/counterX/countY/error_noise_available
What: /sys/bus/counter/devices/counterX/countY/function_available
diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl
index 48ac0d9..087f762 100644
--- a/Documentation/ABI/testing/sysfs-bus-cxl
+++ b/Documentation/ABI/testing/sysfs-bus-cxl
@@ -58,6 +58,65 @@
affinity for this device.
+What: /sys/bus/cxl/devices/memX/security/state
+Date: June, 2023
+KernelVersion: v6.5
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) Reading this file will display the CXL security state for
+ that device. Such states can be: 'disabled', 'sanitize', when
+ a sanitization is currently underway; or those available only
+ for persistent memory: 'locked', 'unlocked' or 'frozen'. This
+ sysfs entry is select/poll capable from userspace to notify
+ upon completion of a sanitize operation.
+
+
+What: /sys/bus/cxl/devices/memX/security/sanitize
+Date: June, 2023
+KernelVersion: v6.5
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) Write a boolean 'true' string value to this attribute to
+ sanitize the device to securely re-purpose or decommission it.
+ This is done by ensuring that all user data and meta-data,
+ whether it resides in persistent capacity, volatile capacity,
+ or the LSA, is made permanently unavailable by whatever means
+ is appropriate for the media type. This functionality requires
+ the device to be disabled, that is, not actively decoding any
+ HPA ranges. This permits avoiding explicit global CPU cache
+ management, relying instead for it to be done when a region
+ transitions between software programmed and hardware committed
+ states. If this file is not present, then there is no hardware
+ support for the operation.
+
+
+What /sys/bus/cxl/devices/memX/security/erase
+Date: June, 2023
+KernelVersion: v6.5
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) Write a boolean 'true' string value to this attribute to
+ secure erase user data by changing the media encryption keys for
+ all user data areas of the device. This functionality requires
+ the device to be disabled, that is, not actively decoding any
+ HPA ranges. This permits avoiding explicit global CPU cache
+ management, relying instead for it to be done when a region
+ transitions between software programmed and hardware committed
+ states. If this file is not present, then there is no hardware
+ support for the operation.
+
+
+What: /sys/bus/cxl/devices/memX/firmware/
+Date: April, 2023
+KernelVersion: v6.5
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RW) Firmware uploader mechanism. The different files under
+ this directory can be used to upload and activate new
+ firmware for CXL devices. The interfaces under this are
+ documented in sysfs-class-firmware.
+
+
What: /sys/bus/cxl/devices/*/devtype
Date: June, 2021
KernelVersion: v5.14
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index cb172db..be66325 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -292,6 +292,16 @@
which is marked with early_stop has failed to initialize, it will ignore
all future connections until this attribute is clear.
+What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/state
+Date: June 2023
+Contact: Roy Luo <royluo@google.com>
+Description:
+ Indicates current state of the USB device attached to the port.
+ Valid states are: 'not-attached', 'attached', 'powered',
+ 'reconnecting', 'unauthenticated', 'default', 'addressed',
+ 'configured', and 'suspended'. This file supports poll() to
+ monitor the state change from user space.
+
What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
Date: May 2013
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes
index 4cdba34..1b3ecae 100644
--- a/Documentation/ABI/testing/sysfs-class-firmware-attributes
+++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes
@@ -243,8 +243,8 @@
index:
Used with HDD and NVME authentication to set the drive index
- that is being referenced (e.g hdd0, hdd1 etc)
- This attribute defaults to device 0.
+ that is being referenced (e.g hdd1, hdd2 etc)
+ This attribute defaults to device 1.
certificate, signature, save_signature:
These attributes are used for certificate based authentication. This is
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-aw200xx b/Documentation/ABI/testing/sysfs-class-led-driver-aw200xx
new file mode 100644
index 0000000..6d4449c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-aw200xx
@@ -0,0 +1,5 @@
+What: /sys/class/leds/<led>/dim
+Date: May 2023
+Description: 64-level DIM current. If you write a negative value or
+ "auto", the dim will be calculated according to the
+ brightness.
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
index 6465409..78b62a2 100644
--- a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
@@ -13,6 +13,11 @@
Specifies the duration of the LED blink in milliseconds.
Defaults to 50 ms.
+ With hw_control ON, the interval value MUST be set to the
+ default value and cannot be changed.
+ Trying to set any value in this specific mode will return
+ an EINVAL error.
+
What: /sys/class/leds/<led>/link
Date: Dec 2017
KernelVersion: 4.16
@@ -39,6 +44,9 @@
If set to 1, the LED will blink for the milliseconds specified
in interval to signal transmission.
+ With hw_control ON, the blink interval is controlled by hardware
+ and won't reflect the value set in interval.
+
What: /sys/class/leds/<led>/rx
Date: Dec 2017
KernelVersion: 4.16
@@ -50,3 +58,84 @@
If set to 1, the LED will blink for the milliseconds specified
in interval to signal reception.
+
+ With hw_control ON, the blink interval is controlled by hardware
+ and won't reflect the value set in interval.
+
+What: /sys/class/leds/<led>/hw_control
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Communicate whether the LED trigger modes are driven by hardware
+ or software fallback is used.
+
+ If 0, the LED is using software fallback to blink.
+
+ If 1, the LED is using hardware control to blink and signal the
+ requested modes.
+
+What: /sys/class/leds/<led>/link_10
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link speed state of 10Mbps of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link state
+ speed of 10MBps of the named network device.
+ Setting this value also immediately changes the LED state.
+
+What: /sys/class/leds/<led>/link_100
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link speed state of 100Mbps of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link state
+ speed of 100Mbps of the named network device.
+ Setting this value also immediately changes the LED state.
+
+What: /sys/class/leds/<led>/link_1000
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link speed state of 1000Mbps of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link state
+ speed of 1000Mbps of the named network device.
+ Setting this value also immediately changes the LED state.
+
+What: /sys/class/leds/<led>/half_duplex
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link half duplex state of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link half
+ duplex state of the named network device.
+ Setting this value also immediately changes the LED state.
+
+What: /sys/class/leds/<led>/full_duplex
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link full duplex state of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link full
+ duplex state of the named network device.
+ Setting this value also immediately changes the LED state.
diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi b/Documentation/ABI/testing/sysfs-class-net-qmi
index 47e6b97..b028f5b 100644
--- a/Documentation/ABI/testing/sysfs-class-net-qmi
+++ b/Documentation/ABI/testing/sysfs-class-net-qmi
@@ -62,7 +62,7 @@
What: /sys/class/net/<iface>/qmi/pass_through
Date: January 2021
KernelVersion: 5.12
-Contact: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
+Contact: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com>
Description:
Boolean. Default: 'N'
diff --git a/Documentation/ABI/testing/sysfs-devices-hisi_ptt b/Documentation/ABI/testing/sysfs-devices-hisi_ptt
index 82de6d7..d7e206b 100644
--- a/Documentation/ABI/testing/sysfs-devices-hisi_ptt
+++ b/Documentation/ABI/testing/sysfs-devices-hisi_ptt
@@ -59,3 +59,55 @@
The available tune data is [0, 1, 2]. Writing a negative value
will return an error, and out of range values will be converted
to 2. The value indicates a probable level of the event.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/root_port_filters
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: This directory contains the files providing the PCIe Root Port filters
+ information used for PTT trace. Each file is named after the supported
+ Root Port device name <domain>:<bus>:<device>.<function>.
+
+ See the description of the "filter" in Documentation/trace/hisi-ptt.rst
+ for more information.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/root_port_filters/multiselect
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (Read) Indicates if this kind of filter can be selected at the same
+ time as others filters, or must be used on it's own. 1 indicates
+ the former case and 0 indicates the latter.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/root_port_filters/<bdf>
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (Read) Indicates the filter value of this Root Port filter, which
+ can be used to control the TLP headers to trace by the PTT trace.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/requester_filters
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: This directory contains the files providing the PCIe Requester filters
+ information used for PTT trace. Each file is named after the supported
+ Endpoint device name <domain>:<bus>:<device>.<function>.
+
+ See the description of the "filter" in Documentation/trace/hisi-ptt.rst
+ for more information.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/requester_filters/multiselect
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (Read) Indicates if this kind of filter can be selected at the same
+ time as others filters, or must be used on it's own. 1 indicates
+ the former case and 0 indicates the latter.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/requester_filters/<bdf>
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (Read) Indicates the filter value of this Requester filter, which
+ can be used to control the TLP headers to trace by the PTT trace.
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index f54867c..77942ee 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -513,17 +513,18 @@
cpu_capacity: capacity of cpuX.
What: /sys/devices/system/cpu/vulnerabilities
- /sys/devices/system/cpu/vulnerabilities/meltdown
- /sys/devices/system/cpu/vulnerabilities/spectre_v1
- /sys/devices/system/cpu/vulnerabilities/spectre_v2
- /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
+ /sys/devices/system/cpu/vulnerabilities/gather_data_sampling
+ /sys/devices/system/cpu/vulnerabilities/itlb_multihit
/sys/devices/system/cpu/vulnerabilities/l1tf
/sys/devices/system/cpu/vulnerabilities/mds
- /sys/devices/system/cpu/vulnerabilities/srbds
- /sys/devices/system/cpu/vulnerabilities/tsx_async_abort
- /sys/devices/system/cpu/vulnerabilities/itlb_multihit
+ /sys/devices/system/cpu/vulnerabilities/meltdown
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
/sys/devices/system/cpu/vulnerabilities/retbleed
+ /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
+ /sys/devices/system/cpu/vulnerabilities/spectre_v1
+ /sys/devices/system/cpu/vulnerabilities/spectre_v2
+ /sys/devices/system/cpu/vulnerabilities/srbds
+ /sys/devices/system/cpu/vulnerabilities/tsx_async_abort
Date: January 2018
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Information about CPU vulnerabilities
@@ -670,7 +671,7 @@
"async" Prefer asynchronous mode
================ ==============================================
- See also: Documentation/arm64/memory-tagging-extension.rst
+ See also: Documentation/arch/arm64/memory-tagging-extension.rst
What: /sys/devices/system/cpu/nohz_full
Date: Apr 2015
diff --git a/Documentation/ABI/testing/sysfs-driver-eud b/Documentation/ABI/testing/sysfs-driver-eud
index 83f3872..2bab0db 100644
--- a/Documentation/ABI/testing/sysfs-driver-eud
+++ b/Documentation/ABI/testing/sysfs-driver-eud
@@ -1,4 +1,4 @@
-What: /sys/bus/platform/drivers/eud/.../enable
+What: /sys/bus/platform/drivers/qcom_eud/.../enable
Date: February 2022
Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
Description:
diff --git a/Documentation/ABI/testing/sysfs-driver-qat b/Documentation/ABI/testing/sysfs-driver-qat
index 087842b..ef6d6c5 100644
--- a/Documentation/ABI/testing/sysfs-driver-qat
+++ b/Documentation/ABI/testing/sysfs-driver-qat
@@ -27,7 +27,18 @@
* sym;asym: the device is configured for running crypto
services
+ * asym;sym: identical to sym;asym
* dc: the device is configured for running compression services
+ * sym: the device is configured for running symmetric crypto
+ services
+ * asym: the device is configured for running asymmetric crypto
+ services
+ * asym;dc: the device is configured for running asymmetric
+ crypto services and compression services
+ * dc;asym: identical to asym;dc
+ * sym;dc: the device is configured for running symmetric crypto
+ services and compression services
+ * dc;sym: identical to sym;dc
It is possible to set the configuration only if the device
is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
@@ -47,3 +58,38 @@
dc
This attribute is only available for qat_4xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
+Date: June 2023
+KernelVersion: 6.5
+Contact: qat-linux@intel.com
+Description: (RW) This configuration option provides a way to force the device into remaining in
+ the MAX power state.
+ If idle support is enabled the device will transition to the `MIN` power state when
+ idle, otherwise will stay in the MAX power state.
+ Write to the file to enable or disable idle support.
+
+ The values are:
+
+ * 0: idle support is disabled
+ * 1: idle support is enabled
+
+ Default value is 1.
+
+ It is possible to set the pm_idle_enabled value only if the device
+ is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
+
+ The following example shows how to change the pm_idle_enabled of
+ a device::
+
+ # cat /sys/bus/pci/devices/<BDF>/qat/state
+ up
+ # cat /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
+ 1
+ # echo down > /sys/bus/pci/devices/<BDF>/qat/state
+ # echo 0 > /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
+ # echo up > /sys/bus/pci/devices/<BDF>/qat/state
+ # cat /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
+ 0
+
+ This attribute is only available for qat_4xxx devices.
diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs
index 228aa43..e487f96 100644
--- a/Documentation/ABI/testing/sysfs-driver-ufs
+++ b/Documentation/ABI/testing/sysfs-driver-ufs
@@ -994,7 +994,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/rpm_lvl
What: /sys/bus/platform/devices/*.ufs/rpm_lvl
Date: September 2014
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry could be used to set or show the UFS device
runtime power management level. The current driver
implementation supports 7 levels with next target states:
@@ -1021,7 +1021,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state
What: /sys/bus/platform/devices/*.ufs/rpm_target_dev_state
Date: February 2018
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry shows the target power mode of an UFS device
for the chosen runtime power management level.
@@ -1030,7 +1030,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_link_state
What: /sys/bus/platform/devices/*.ufs/rpm_target_link_state
Date: February 2018
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry shows the target state of an UFS UIC link
for the chosen runtime power management level.
@@ -1039,7 +1039,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/spm_lvl
What: /sys/bus/platform/devices/*.ufs/spm_lvl
Date: September 2014
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry could be used to set or show the UFS device
system power management level. The current driver
implementation supports 7 levels with next target states:
@@ -1066,7 +1066,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state
What: /sys/bus/platform/devices/*.ufs/spm_target_dev_state
Date: February 2018
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry shows the target power mode of an UFS device
for the chosen system power management level.
@@ -1075,7 +1075,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/spm_target_link_state
What: /sys/bus/platform/devices/*.ufs/spm_target_link_state
Date: February 2018
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry shows the target state of an UFS UIC link
for the chosen system power management level.
@@ -1084,7 +1084,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_enable
What: /sys/bus/platform/devices/*.ufs/monitor/monitor_enable
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the status of performance monitor enablement
and it can be used to start/stop the monitor. When the monitor
is stopped, the performance data collected is also cleared.
@@ -1092,7 +1092,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_chunk_size
What: /sys/bus/platform/devices/*.ufs/monitor/monitor_chunk_size
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file tells the monitor to focus on requests transferring
data of specific chunk size (in Bytes). 0 means any chunk size.
It can only be changed when monitor is disabled.
@@ -1100,7 +1100,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_sectors
What: /sys/bus/platform/devices/*.ufs/monitor/read_total_sectors
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how many sectors (in 512 Bytes) have been
sent from device to host after monitor gets started.
@@ -1109,7 +1109,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_busy
What: /sys/bus/platform/devices/*.ufs/monitor/read_total_busy
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how long (in micro seconds) has been spent
sending data from device to host after monitor gets started.
@@ -1118,7 +1118,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_nr_requests
What: /sys/bus/platform/devices/*.ufs/monitor/read_nr_requests
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how many read requests have been sent after
monitor gets started.
@@ -1127,7 +1127,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_max
What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_max
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the maximum latency (in micro seconds) of
read requests after monitor gets started.
@@ -1136,7 +1136,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_min
What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_min
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the minimum latency (in micro seconds) of
read requests after monitor gets started.
@@ -1145,7 +1145,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_avg
What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_avg
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the average latency (in micro seconds) of
read requests after monitor gets started.
@@ -1154,7 +1154,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_sum
What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_sum
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the total latency (in micro seconds) of
read requests sent after monitor gets started.
@@ -1163,7 +1163,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_sectors
What: /sys/bus/platform/devices/*.ufs/monitor/write_total_sectors
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how many sectors (in 512 Bytes) have been sent
from host to device after monitor gets started.
@@ -1172,7 +1172,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_busy
What: /sys/bus/platform/devices/*.ufs/monitor/write_total_busy
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how long (in micro seconds) has been spent
sending data from host to device after monitor gets started.
@@ -1181,7 +1181,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_nr_requests
What: /sys/bus/platform/devices/*.ufs/monitor/write_nr_requests
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how many write requests have been sent after
monitor gets started.
@@ -1190,7 +1190,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_max
What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_max
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the maximum latency (in micro seconds) of write
requests after monitor gets started.
@@ -1199,7 +1199,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_min
What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_min
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the minimum latency (in micro seconds) of write
requests after monitor gets started.
@@ -1208,7 +1208,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_avg
What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_avg
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the average latency (in micro seconds) of write
requests after monitor gets started.
@@ -1217,7 +1217,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_sum
What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_sum
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the total latency (in micro seconds) of write
requests after monitor gets started.
@@ -1226,7 +1226,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en
What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_presv_us_en
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows if preserve user-space was configured
The file is read only.
@@ -1234,7 +1234,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_shared_alloc_units
What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_shared_alloc_units
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the shared allocated units of WB buffer
The file is read only.
@@ -1242,7 +1242,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_type
What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_type
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the configured WB type.
0x1 for shared buffer mode. 0x0 for dedicated buffer mode.
@@ -1251,7 +1251,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_buff_cap_adj
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_buff_cap_adj
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the total user-space decrease in shared
buffer mode.
The value of this parameter is 3 for TLC NAND when SLC mode
@@ -1262,7 +1262,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_alloc_units
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_max_alloc_units
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the Maximum total WriteBooster Buffer size
which is supported by the entire device.
@@ -1271,7 +1271,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_wb_luns
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_max_wb_luns
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the maximum number of luns that can support
WriteBooster.
@@ -1280,7 +1280,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_red_type
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_sup_red_type
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: The supportability of user space reduction mode
and preserve user space mode.
00h: WriteBooster Buffer can be configured only in
@@ -1295,7 +1295,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_wb_type
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_sup_wb_type
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: The supportability of WriteBooster Buffer type.
=== ==========================================================
@@ -1310,7 +1310,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_enable
What: /sys/bus/platform/devices/*.ufs/flags/wb_enable
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the status of WriteBooster.
== ============================
@@ -1323,7 +1323,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_en
What: /sys/bus/platform/devices/*.ufs/flags/wb_flush_en
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows if flush is enabled.
== =================================
@@ -1336,7 +1336,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_during_h8
What: /sys/bus/platform/devices/*.ufs/flags/wb_flush_during_h8
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: Flush WriteBooster Buffer during hibernate state.
== =================================================
@@ -1351,7 +1351,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_avail_buf
What: /sys/bus/platform/devices/*.ufs/attributes/wb_avail_buf
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the amount of unused WriteBooster buffer
available.
@@ -1360,7 +1360,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_cur_buf
What: /sys/bus/platform/devices/*.ufs/attributes/wb_cur_buf
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the amount of unused current buffer.
The file is read only.
@@ -1368,7 +1368,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_flush_status
What: /sys/bus/platform/devices/*.ufs/attributes/wb_flush_status
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the flush operation status.
@@ -1385,7 +1385,7 @@
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_life_time_est
What: /sys/bus/platform/devices/*.ufs/attributes/wb_life_time_est
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows an indication of the WriteBooster Buffer
lifetime based on the amount of performed program/erase cycles
@@ -1399,7 +1399,7 @@
What: /sys/class/scsi_device/*/device/unit_descriptor/wb_buf_alloc_units
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the configured size of WriteBooster buffer.
0400h corresponds to 4GB.
@@ -1426,6 +1426,17 @@
If flushing is enabled, the device executes the flush
operation when the command queue is empty.
+What: /sys/bus/platform/drivers/ufshcd/*/wb_flush_threshold
+What: /sys/bus/platform/devices/*.ufs/wb_flush_threshold
+Date: June 2023
+Contact: Lu Hongfei <luhongfei@vivo.com>
+Description:
+ wb_flush_threshold represents the threshold for flushing WriteBooster buffer,
+ whose value expressed in unit of 10% granularity, such as '1' representing 10%,
+ '2' representing 20%, and so on.
+ If avail_wb_buff < wb_flush_threshold, it indicates that WriteBooster buffer needs to
+ be flushed, otherwise it is not necessary.
+
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version
What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_version
Date: June 2021
diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module
index 0888636..62addab 100644
--- a/Documentation/ABI/testing/sysfs-module
+++ b/Documentation/ABI/testing/sysfs-module
@@ -60,3 +60,14 @@
C staging driver module
E unsigned module
== =====================
+
+What: /sys/module/grant_table/parameters/free_per_iteration
+Date: July 2023
+KernelVersion: 6.5 but backported to all supported stable branches
+Contact: Xen developer discussion <xen-devel@lists.xenproject.org>
+Description: Read and write number of grant entries to attempt to free per iteration.
+
+ Note: Future versions of Xen and Linux may provide a better
+ interface for controlling the rate of deferred grant reclaim
+ or may not need it at all.
+Users: Qubes OS (https://www.qubes-os.org)
diff --git a/Documentation/ABI/testing/sysfs-ocfs2 b/Documentation/ABI/testing/sysfs-ocfs2
index b7cc516..494d7c1 100644
--- a/Documentation/ABI/testing/sysfs-ocfs2
+++ b/Documentation/ABI/testing/sysfs-ocfs2
@@ -1,13 +1,13 @@
What: /sys/fs/ocfs2/
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2 directory contains knobs used by the
ocfs2-tools to interact with the filesystem.
What: /sys/fs/ocfs2/max_locking_protocol
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/max_locking_protocol file displays version
of ocfs2 locking supported by the filesystem. This version
@@ -28,7 +28,7 @@
What: /sys/fs/ocfs2/loaded_cluster_plugins
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/loaded_cluster_plugins file describes
the available plugins to support ocfs2 cluster operation.
@@ -48,7 +48,7 @@
What: /sys/fs/ocfs2/active_cluster_plugin
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/active_cluster_plugin displays which
cluster plugin is currently in use by the filesystem.
@@ -65,7 +65,7 @@
What: /sys/fs/ocfs2/cluster_stack
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/cluster_stack file contains the name
of current ocfs2 cluster stack. This value is set by
@@ -86,4 +86,4 @@
stack return an error.
Users:
- ocfs2-tools <ocfs2-tools-devel@oss.oracle.com>
+ ocfs2-tools <ocfs2-tools-devel@lists.linux.dev>
diff --git a/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv b/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv
index 1d97ad6..a9d39d9 100644
--- a/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv
+++ b/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv
@@ -3,5 +3,7 @@
KernelVersion: 6.1
Contact: Armin Wolf <W_Armin@gmx.de>
Description:
- Reports the Dell ePPID (electronic Dell Piece Part Identification)
+ Reports the Dell ePPID (electronic Piece Part Identification)
of the ACPI battery.
+
+ See Documentation/wmi/devices/dell-wmi-ddv.rst for details.
diff --git a/Documentation/ABI/testing/sysfs-platform-hidma b/Documentation/ABI/testing/sysfs-platform-hidma
index fca40a5..a80aeda 100644
--- a/Documentation/ABI/testing/sysfs-platform-hidma
+++ b/Documentation/ABI/testing/sysfs-platform-hidma
@@ -2,7 +2,7 @@
/sys/devices/platform/QCOM8061:*/chid
Date: Dec 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains the ID of the channel within the HIDMA instance.
It is used to associate a given HIDMA channel with the
diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
index 3b6c5c9..0373745 100644
--- a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
+++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
@@ -2,7 +2,7 @@
/sys/devices/platform/QCOM8060:*/chanops/chan*/priority
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains either 0 or 1 and indicates if the DMA channel is a
low priority (0) or high priority (1) channel.
@@ -11,7 +11,7 @@
/sys/devices/platform/QCOM8060:*/chanops/chan*/weight
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains 0..15 and indicates the weight of the channel among
equal priority channels during round robin scheduling.
@@ -20,7 +20,7 @@
/sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains the platform specific cycle value to wait after a
reset command is issued. If the value is chosen too short,
@@ -32,7 +32,7 @@
/sys/devices/platform/QCOM8060:*/dma_channels
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains the number of dma channels supported by one instance
of HIDMA hardware. The value may change from chip to chip.
@@ -41,7 +41,7 @@
/sys/devices/platform/QCOM8060:*/hw_version_major
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Version number major for the hardware.
@@ -49,7 +49,7 @@
/sys/devices/platform/QCOM8060:*/hw_version_minor
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Version number minor for the hardware.
@@ -57,7 +57,7 @@
/sys/devices/platform/QCOM8060:*/max_rd_xactions
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains a value between 0 and 31. Maximum number of
read transactions that can be issued back to back.
@@ -69,7 +69,7 @@
/sys/devices/platform/QCOM8060:*/max_read_request
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Size of each read request. The value needs to be a power
of two and can be between 128 and 1024.
@@ -78,7 +78,7 @@
/sys/devices/platform/QCOM8060:*/max_wr_xactions
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains a value between 0 and 31. Maximum number of
write transactions that can be issued back to back.
@@ -91,7 +91,7 @@
/sys/devices/platform/QCOM8060:*/max_write_request
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Size of each write request. The value needs to be a power
of two and can be between 128 and 1024.
diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
index 9b99a81b..4c5c02d 100644
--- a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
+++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
@@ -75,3 +75,12 @@
Contact: "Liming Sun <limings@nvidia.com>"
Description:
The file used to access the BlueField boot fifo.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/rsh_log
+Date: May 2023
+KernelVersion: 6.4
+Contact: "Liming Sun <limings@nvidia.com>"
+Description:
+ The file used to write BlueField boot log with the format
+ "[INFO|WARN|ERR|ASSERT ]<msg>". Log level 'INFO' is used by
+ default if not specified.
diff --git a/Documentation/PCI/endpoint/pci-ntb-howto.rst b/Documentation/PCI/endpoint/pci-ntb-howto.rst
index 1884bf2..4261e71 100644
--- a/Documentation/PCI/endpoint/pci-ntb-howto.rst
+++ b/Documentation/PCI/endpoint/pci-ntb-howto.rst
@@ -88,13 +88,10 @@
# echo 0x104c > functions/pci_epf_ntb/func1/vendorid
# echo 0xb00d > functions/pci_epf_ntb/func1/deviceid
-In order to configure NTB specific attributes, a new sub-directory to func1
-should be created::
-
- # mkdir functions/pci_epf_ntb/func1/pci_epf_ntb.0/
-
-The NTB function driver will populate this directory with various attributes
-that can be configured by the user::
+The PCI endpoint framework also automatically creates a sub-directory in the
+function attribute directory. This sub-directory has the same name as the name
+of the function device and is populated with the following NTB specific
+attributes that can be configured by the user::
# ls functions/pci_epf_ntb/func1/pci_epf_ntb.0/
db_count mw1 mw2 mw3 mw4 num_mws
diff --git a/Documentation/PCI/endpoint/pci-vntb-howto.rst b/Documentation/PCI/endpoint/pci-vntb-howto.rst
index 4ab8e4a..70d3bc9 100644
--- a/Documentation/PCI/endpoint/pci-vntb-howto.rst
+++ b/Documentation/PCI/endpoint/pci-vntb-howto.rst
@@ -84,13 +84,10 @@
# echo 0x1957 > functions/pci_epf_vntb/func1/vendorid
# echo 0x0809 > functions/pci_epf_vntb/func1/deviceid
-In order to configure NTB specific attributes, a new sub-directory to func1
-should be created::
-
- # mkdir functions/pci_epf_vntb/func1/pci_epf_vntb.0/
-
-The NTB function driver will populate this directory with various attributes
-that can be configured by the user::
+The PCI endpoint framework also automatically creates a sub-directory in the
+function attribute directory. This sub-directory has the same name as the name
+of the function device and is populated with the following NTB specific
+attributes that can be configured by the user::
# ls functions/pci_epf_vntb/func1/pci_epf_vntb.0/
db_count mw1 mw2 mw3 mw4 num_mws
@@ -103,7 +100,7 @@
# echo 1 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/num_mws
# echo 0x100000 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/mw1
-A sample configuration for virtual NTB driver for virutal PCI bus::
+A sample configuration for virtual NTB driver for virtual PCI bus::
# echo 0x1957 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_vid
# echo 0x080A > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_pid
diff --git a/Documentation/PCI/msi-howto.rst b/Documentation/PCI/msi-howto.rst
index 8ae461e..c9400f0 100644
--- a/Documentation/PCI/msi-howto.rst
+++ b/Documentation/PCI/msi-howto.rst
@@ -290,7 +290,7 @@
List of device drivers MSI(-X) APIs
===================================
-The PCI/MSI subystem has a dedicated C file for its exported device driver
+The PCI/MSI subsystem has a dedicated C file for its exported device driver
APIs — `drivers/pci/msi/api.c`. The following functions are exported:
.. kernel-doc:: drivers/pci/msi/api.c
diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
index 9981d33..c237596 100644
--- a/Documentation/PCI/pci-error-recovery.rst
+++ b/Documentation/PCI/pci-error-recovery.rst
@@ -364,7 +364,7 @@
caused by over-heating, some by a poorly seated card. Many
PCI error events are caused by software bugs, e.g. DMA's to
wild addresses or bogus split transactions due to programming
-errors. See the discussion in powerpc/eeh-pci-error-recovery.txt
+errors. See the discussion in Documentation/powerpc/eeh-pci-error-recovery.rst
for additional detail on real-life experience of the causes of
software errors.
diff --git a/Documentation/PCI/pcieaer-howto.rst b/Documentation/PCI/pcieaer-howto.rst
index 0b36b9eb..e00d639 100644
--- a/Documentation/PCI/pcieaer-howto.rst
+++ b/Documentation/PCI/pcieaer-howto.rst
@@ -16,62 +16,61 @@
About this guide
----------------
-This guide describes the basics of the PCI Express Advanced Error
+This guide describes the basics of the PCI Express (PCIe) Advanced Error
Reporting (AER) driver and provides information on how to use it, as
-well as how to enable the drivers of endpoint devices to conform with
-PCI Express AER driver.
+well as how to enable the drivers of Endpoint devices to conform with
+the PCIe AER driver.
-What is the PCI Express AER Driver?
------------------------------------
+What is the PCIe AER Driver?
+----------------------------
-PCI Express error signaling can occur on the PCI Express link itself
-or on behalf of transactions initiated on the link. PCI Express
+PCIe error signaling can occur on the PCIe link itself
+or on behalf of transactions initiated on the link. PCIe
defines two error reporting paradigms: the baseline capability and
the Advanced Error Reporting capability. The baseline capability is
-required of all PCI Express components providing a minimum defined
+required of all PCIe components providing a minimum defined
set of error reporting requirements. Advanced Error Reporting
-capability is implemented with a PCI Express advanced error reporting
+capability is implemented with a PCIe Advanced Error Reporting
extended capability structure providing more robust error reporting.
-The PCI Express AER driver provides the infrastructure to support PCI
-Express Advanced Error Reporting capability. The PCI Express AER
-driver provides three basic functions:
+The PCIe AER driver provides the infrastructure to support PCIe Advanced
+Error Reporting capability. The PCIe AER driver provides three basic
+functions:
- Gathers the comprehensive error information if errors occurred.
- Reports error to the users.
- Performs error recovery actions.
-AER driver only attaches root ports which support PCI-Express AER
-capability.
+The AER driver only attaches to Root Ports and RCECs that support the PCIe
+AER capability.
User Guide
==========
-Include the PCI Express AER Root Driver into the Linux Kernel
--------------------------------------------------------------
+Include the PCIe AER Root Driver into the Linux Kernel
+------------------------------------------------------
-The PCI Express AER Root driver is a Root Port service driver attached
-to the PCI Express Port Bus driver. If a user wants to use it, the driver
-has to be compiled. Option CONFIG_PCIEAER supports this capability. It
-depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and
-CONFIG_PCIEAER = y.
+The PCIe AER driver is a Root Port service driver attached
+via the PCIe Port Bus driver. If a user wants to use it, the driver
+must be compiled. It is enabled with CONFIG_PCIEAER, which
+depends on CONFIG_PCIEPORTBUS.
-Load PCI Express AER Root Driver
---------------------------------
+Load PCIe AER Root Driver
+-------------------------
Some systems have AER support in firmware. Enabling Linux AER support at
-the same time the firmware handles AER may result in unpredictable
+the same time the firmware handles AER would result in unpredictable
behavior. Therefore, Linux does not handle AER events unless the firmware
-grants AER control to the OS via the ACPI _OSC method. See the PCI FW 3.0
+grants AER control to the OS via the ACPI _OSC method. See the PCI Firmware
Specification for details regarding _OSC usage.
AER error output
----------------
When a PCIe AER error is captured, an error message will be output to
-console. If it's a correctable error, it is output as a warning.
+console. If it's a correctable error, it is output as an info message.
Otherwise, it is printed as an error. So users could choose different
log level to filter out correctable error messages.
@@ -82,9 +81,9 @@
0000:50:00.0: [20] Unsupported Request (First)
0000:50:00.0: TLP Header: 04000001 00200a03 05010000 00050100
-In the example, 'Requester ID' means the ID of the device who sends
-the error message to root port. Pls. refer to pci express specs for
-other fields.
+In the example, 'Requester ID' means the ID of the device that sent
+the error message to the Root Port. Please refer to PCIe specs for other
+fields.
AER Statistics / Counters
-------------------------
@@ -96,65 +95,56 @@
Developer Guide
===============
-To enable AER aware support requires a software driver to configure
-the AER capability structure within its device and to provide callbacks.
+To enable error recovery, a software driver must provide callbacks.
-To support AER better, developers need understand how AER does work
-firstly.
+To support AER better, developers need to understand how AER works.
-PCI Express errors are classified into two types: correctable errors
-and uncorrectable errors. This classification is based on the impacts
+PCIe errors are classified into two types: correctable errors
+and uncorrectable errors. This classification is based on the impact
of those errors, which may result in degraded performance or function
failure.
Correctable errors pose no impacts on the functionality of the
-interface. The PCI Express protocol can recover without any software
+interface. The PCIe protocol can recover without any software
intervention or any loss of data. These errors are detected and
-corrected by hardware. Unlike correctable errors, uncorrectable
+corrected by hardware.
+
+Unlike correctable errors, uncorrectable
errors impact functionality of the interface. Uncorrectable errors
-can cause a particular transaction or a particular PCI Express link
+can cause a particular transaction or a particular PCIe link
to be unreliable. Depending on those error conditions, uncorrectable
errors are further classified into non-fatal errors and fatal errors.
Non-fatal errors cause the particular transaction to be unreliable,
-but the PCI Express link itself is fully functional. Fatal errors, on
+but the PCIe link itself is fully functional. Fatal errors, on
the other hand, cause the link to be unreliable.
-When AER is enabled, a PCI Express device will automatically send an
-error message to the PCIe root port above it when the device captures
+When PCIe error reporting is enabled, a device will automatically send an
+error message to the Root Port above it when it captures
an error. The Root Port, upon receiving an error reporting message,
-internally processes and logs the error message in its PCI Express
-capability structure. Error information being logged includes storing
+internally processes and logs the error message in its AER
+Capability structure. Error information being logged includes storing
the error reporting agent's requestor ID into the Error Source
Identification Registers and setting the error bits of the Root Error
-Status Register accordingly. If AER error reporting is enabled in Root
-Error Command Register, the Root Port generates an interrupt if an
+Status Register accordingly. If AER error reporting is enabled in the Root
+Error Command Register, the Root Port generates an interrupt when an
error is detected.
-Note that the errors as described above are related to the PCI Express
+Note that the errors as described above are related to the PCIe
hierarchy and links. These errors do not include any device specific
errors because device specific errors will still get sent directly to
the device driver.
-Configure the AER capability structure
---------------------------------------
-
-AER aware drivers of PCI Express component need change the device
-control registers to enable AER. They also could change AER registers,
-including mask and severity registers. Helper function
-pci_enable_pcie_error_reporting could be used to enable AER. See
-section 3.3.
-
Provide callbacks
-----------------
-callback reset_link to reset pci express link
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+callback reset_link to reset PCIe link
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This callback is used to reset the pci express physical link when a
-fatal error happens. The root port aer service driver provides a
-default reset_link function, but different upstream ports might
-have different specifications to reset pci express link, so all
-upstream ports should provide their own reset_link functions.
+This callback is used to reset the PCIe physical link when a
+fatal error happens. The Root Port AER service driver provides a
+default reset_link function, but different Upstream Ports might
+have different specifications to reset the PCIe link, so
+Upstream Port drivers may provide their own reset_link functions.
Section 3.2.2.2 provides more detailed info on when to call
reset_link.
@@ -162,24 +152,24 @@
PCI error-recovery callbacks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The PCI Express AER Root driver uses error callbacks to coordinate
+The PCIe AER Root driver uses error callbacks to coordinate
with downstream device drivers associated with a hierarchy in question
when performing error recovery actions.
Data struct pci_driver has a pointer, err_handler, to point to
pci_error_handlers who consists of a couple of callback function
-pointers. AER driver follows the rules defined in
-pci-error-recovery.txt except pci express specific parts (e.g.
-reset_link). Pls. refer to pci-error-recovery.txt for detailed
+pointers. The AER driver follows the rules defined in
+pci-error-recovery.rst except PCIe-specific parts (e.g.
+reset_link). Please refer to pci-error-recovery.rst for detailed
definitions of the callbacks.
-Below sections specify when to call the error callback functions.
+The sections below specify when to call the error callback functions.
Correctable errors
~~~~~~~~~~~~~~~~~~
Correctable errors pose no impacts on the functionality of
-the interface. The PCI Express protocol can recover without any
+the interface. The PCIe protocol can recover without any
software intervention or any loss of data. These errors do not
require any recovery actions. The AER driver clears the device's
correctable error status register accordingly and logs these errors.
@@ -190,12 +180,12 @@
If an error message indicates a non-fatal error, performing link reset
at upstream is not required. The AER driver calls error_detected(dev,
pci_channel_io_normal) to all drivers associated within a hierarchy in
-question. for example::
+question. For example::
- EndPoint<==>DownstreamPort B<==>UpstreamPort A<==>RootPort
+ Endpoint <==> Downstream Port B <==> Upstream Port A <==> Root Port
-If Upstream port A captures an AER error, the hierarchy consists of
-Downstream port B and EndPoint.
+If Upstream Port A captures an AER error, the hierarchy consists of
+Downstream Port B and Endpoint.
A driver may return PCI_ERS_RESULT_CAN_RECOVER,
PCI_ERS_RESULT_DISCONNECT, or PCI_ERS_RESULT_NEED_RESET, depending on
@@ -212,36 +202,11 @@
and reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
to mmio_enabled.
-helper functions
-----------------
-::
-
- int pci_enable_pcie_error_reporting(struct pci_dev *dev);
-
-pci_enable_pcie_error_reporting enables the device to send error
-messages to root port when an error is detected. Note that devices
-don't enable the error reporting by default, so device drivers need
-call this function to enable it.
-
-::
-
- int pci_disable_pcie_error_reporting(struct pci_dev *dev);
-
-pci_disable_pcie_error_reporting disables the device to send error
-messages to root port when an error is detected.
-
-::
-
- int pci_aer_clear_nonfatal_status(struct pci_dev *dev);`
-
-pci_aer_clear_nonfatal_status clears non-fatal errors in the uncorrectable
-error status register.
-
Frequent Asked Questions
------------------------
Q:
- What happens if a PCI Express device driver does not provide an
+ What happens if a PCIe device driver does not provide an
error recovery handler (pci_driver->err_handler is equal to NULL)?
A:
@@ -257,24 +222,6 @@
Fatal error recovery will fail if the errors are reported by the
upstream ports who are attached by the service driver.
-Q:
- How does this infrastructure deal with driver that is not PCI
- Express aware?
-
-A:
- This infrastructure calls the error callback functions of the
- driver when an error happens. But if the driver is not aware of
- PCI Express, the device might not report its own errors to root
- port.
-
-Q:
- What modifications will that driver need to make it compatible
- with the PCI Express AER Root driver?
-
-A:
- It could call the helper functions to enable AER in devices and
- cleanup uncorrectable status register. Pls. refer to section 3.3.
-
Software error injection
========================
@@ -296,5 +243,5 @@
https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
-More information about aer-inject can be found in the document comes
-with its source code.
+More information about aer-inject can be found in the document in
+its source code.
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index 49387d8..f3b6052 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -2071,41 +2071,7 @@
Because RCU avoids interrupting idle CPUs, it is illegal to execute an
RCU read-side critical section on an idle CPU. (Kernels built with
-``CONFIG_PROVE_RCU=y`` will splat if you try it.) The RCU_NONIDLE()
-macro and ``_rcuidle`` event tracing is provided to work around this
-restriction. In addition, rcu_is_watching() may be used to test
-whether or not it is currently legal to run RCU read-side critical
-sections on this CPU. I learned of the need for diagnostics on the one
-hand and RCU_NONIDLE() on the other while inspecting idle-loop code.
-Steven Rostedt supplied ``_rcuidle`` event tracing, which is used quite
-heavily in the idle loop. However, there are some restrictions on the
-code placed within RCU_NONIDLE():
-
-#. Blocking is prohibited. In practice, this is not a serious
- restriction given that idle tasks are prohibited from blocking to
- begin with.
-#. Although nesting RCU_NONIDLE() is permitted, they cannot nest
- indefinitely deeply. However, given that they can be nested on the
- order of a million deep, even on 32-bit systems, this should not be a
- serious restriction. This nesting limit would probably be reached
- long after the compiler OOMed or the stack overflowed.
-#. Any code path that enters RCU_NONIDLE() must sequence out of that
- same RCU_NONIDLE(). For example, the following is grossly
- illegal:
-
- ::
-
- 1 RCU_NONIDLE({
- 2 do_something();
- 3 goto bad_idea; /* BUG!!! */
- 4 do_something_else();});
- 5 bad_idea:
-
-
- It is just as illegal to transfer control into the middle of
- RCU_NONIDLE()'s argument. Yes, in theory, you could transfer in
- as long as you also transferred out, but in practice you could also
- expect to get sharply worded review comments.
+``CONFIG_PROVE_RCU=y`` will splat if you try it.)
It is similarly socially unacceptable to interrupt an ``nohz_full`` CPU
running in userspace. RCU must therefore track ``nohz_full`` userspace
diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst
index 8eddef2..e488c8e 100644
--- a/Documentation/RCU/whatisRCU.rst
+++ b/Documentation/RCU/whatisRCU.rst
@@ -1117,7 +1117,6 @@
RCU_LOCKDEP_WARN
rcu_sleep_check
- RCU_NONIDLE
All: Unchecked RCU-protected pointer access::
diff --git a/Documentation/admin-guide/acpi/ssdt-overlays.rst b/Documentation/admin-guide/acpi/ssdt-overlays.rst
index b5fbf54..5ea9f4a3 100644
--- a/Documentation/admin-guide/acpi/ssdt-overlays.rst
+++ b/Documentation/admin-guide/acpi/ssdt-overlays.rst
@@ -103,7 +103,7 @@
is also work underway to implement EFI support for loading user defined SSDTs
and using this method will make it easier to convert to the EFI loading
mechanism when that will arrive. To enable it, the
-CONFIG_EFI_CUSTOM_SSDT_OVERLAYS shoyld be chosen to y.
+CONFIG_EFI_CUSTOM_SSDT_OVERLAYS should be chosen to y.
In order to load SSDTs from an EFI variable the ``"efivar_ssdt=..."`` kernel
command line parameter can be used (the name has a limitation of 16 characters).
diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst
index bb5032a..6fdb495 100644
--- a/Documentation/admin-guide/bcache.rst
+++ b/Documentation/admin-guide/bcache.rst
@@ -508,9 +508,6 @@
cache miss, but raced with a write and data was already present (usually 0
since the synchronization for cache misses was rewritten)
-cache_readaheads
- Count of times readahead occurred.
-
Sysfs - cache set
~~~~~~~~~~~~~~~~~
diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst
index 47d1d7d..fabaad3 100644
--- a/Documentation/admin-guide/cgroup-v1/memory.rst
+++ b/Documentation/admin-guide/cgroup-v1/memory.rst
@@ -297,7 +297,7 @@
Page lock (PG_locked bit of page->flags)
mm->page_table_lock or split pte_lock
- lock_page_memcg (memcg->move_lock)
+ folio_memcg_lock (memcg->move_lock)
mapping->i_pages lock
lruvec->lru_lock.
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index e592a93..4ef8901 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1580,6 +1580,13 @@
Healthy workloads are not expected to reach this limit.
+ memory.swap.peak
+ A read-only single value file which exists on non-root
+ cgroups.
+
+ The max swap usage recorded for the cgroup and its
+ descendants since the creation of the cgroup.
+
memory.swap.max
A read-write single value file which exists on non-root
cgroups. The default is "max".
@@ -2022,31 +2029,33 @@
no-change
Do not modify the I/O priority class.
- none-to-rt
- For requests that do not have an I/O priority class (NONE),
- change the I/O priority class into RT. Do not modify
- the I/O priority class of other requests.
+ promote-to-rt
+ For requests that have a non-RT I/O priority class, change it into RT.
+ Also change the priority level of these requests to 4. Do not modify
+ the I/O priority of requests that have priority class RT.
restrict-to-be
For requests that do not have an I/O priority class or that have I/O
- priority class RT, change it into BE. Do not modify the I/O priority
- class of requests that have priority class IDLE.
+ priority class RT, change it into BE. Also change the priority level
+ of these requests to 0. Do not modify the I/O priority class of
+ requests that have priority class IDLE.
idle
Change the I/O priority class of all requests into IDLE, the lowest
I/O priority class.
+ none-to-rt
+ Deprecated. Just an alias for promote-to-rt.
+
The following numerical values are associated with the I/O priority policies:
-+-------------+---+
-| no-change | 0 |
-+-------------+---+
-| none-to-rt | 1 |
-+-------------+---+
-| rt-to-be | 2 |
-+-------------+---+
-| all-to-idle | 3 |
-+-------------+---+
++----------------+---+
+| no-change | 0 |
++----------------+---+
+| rt-to-be | 2 |
++----------------+---+
+| all-to-idle | 3 |
++----------------+---+
The numerical value that corresponds to each I/O priority class is as follows:
@@ -2062,9 +2071,13 @@
The algorithm to set the I/O priority class for a request is as follows:
-- Translate the I/O priority class policy into a number.
-- Change the request I/O priority class into the maximum of the I/O priority
- class policy number and the numerical I/O priority class.
+- If I/O priority class policy is promote-to-rt, change the request I/O
+ priority class to IOPRIO_CLASS_RT and change the request I/O priority
+ level to 4.
+- If I/O priorityt class is not promote-to-rt, translate the I/O priority
+ class policy into a number, then change the request I/O priority class
+ into the maximum of the I/O priority class policy number and the numerical
+ I/O priority class.
PID
---
@@ -2437,7 +2450,7 @@
res_b 10
misc.current
- A read-only flat-keyed file shown in the non-root cgroups. It shows
+ A read-only flat-keyed file shown in the all cgroups. It shows
the current usage of the resources in the cgroup and its children.::
$ cat misc.current
diff --git a/Documentation/admin-guide/device-mapper/dm-flakey.rst b/Documentation/admin-guide/device-mapper/dm-flakey.rst
index f7104c0..f967c5f 100644
--- a/Documentation/admin-guide/device-mapper/dm-flakey.rst
+++ b/Documentation/admin-guide/device-mapper/dm-flakey.rst
@@ -67,6 +67,16 @@
Perform the replacement only if bio->bi_opf has all the
selected flags set.
+ random_read_corrupt <probability>
+ During <down interval>, replace random byte in a read bio
+ with a random value. probability is an integer between
+ 0 and 1000000000 meaning 0% to 100% probability of corruption.
+
+ random_write_corrupt <probability>
+ During <down interval>, replace random byte in a write bio
+ with a random value. probability is an integer between
+ 0 and 1000000000 meaning 0% to 100% probability of corruption.
+
Examples:
Replaces the 32nd byte of READ bios with the value 1::
diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst b/Documentation/admin-guide/device-mapper/dm-integrity.rst
index 8db172e..d8a5f14 100644
--- a/Documentation/admin-guide/device-mapper/dm-integrity.rst
+++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst
@@ -25,7 +25,7 @@
mode, the dm-integrity target can be used to detect silent data
corruption on the disk or in the I/O path.
-There's an alternate mode of operation where dm-integrity uses bitmap
+There's an alternate mode of operation where dm-integrity uses a bitmap
instead of a journal. If a bit in the bitmap is 1, the corresponding
region's data and integrity tags are not synchronized - if the machine
crashes, the unsynchronized regions will be recalculated. The bitmap mode
@@ -38,6 +38,15 @@
zeroes. If the superblock is neither valid nor zeroed, the dm-integrity
target can't be loaded.
+Accesses to the on-disk metadata area containing checksums (aka tags) are
+buffered using dm-bufio. When an access to any given metadata area
+occurs, each unique metadata area gets its own buffer(s). The buffer size
+is capped at the size of the metadata area, but may be smaller, thereby
+requiring multiple buffers to represent the full metadata area. A smaller
+buffer size will produce a smaller resulting read/write operation to the
+metadata area for small reads/writes. The metadata is still read even in
+a full write to the data covered by a single buffer.
+
To use the target for the first time:
1. overwrite the superblock with zeroes
@@ -93,7 +102,7 @@
device. If the device is already formatted, the value from the
superblock is used.
-interleave_sectors:number
+interleave_sectors:number (default 32768)
The number of interleaved sectors. This values is rounded down to
a power of two. If the device is already formatted, the value from
the superblock is used.
@@ -102,20 +111,16 @@
Don't interleave the data and metadata on the device. Use a
separate device for metadata.
-buffer_sectors:number
- The number of sectors in one buffer. The value is rounded down to
- a power of two.
+buffer_sectors:number (default 128)
+ The number of sectors in one metadata buffer. The value is rounded
+ down to a power of two.
- The tag area is accessed using buffers, the buffer size is
- configurable. The large buffer size means that the I/O size will
- be larger, but there could be less I/Os issued.
-
-journal_watermark:number
+journal_watermark:number (default 50)
The journal watermark in percents. When the size of the journal
exceeds this watermark, the thread that flushes the journal will
be started.
-commit_time:number
+commit_time:number (default 10000)
Commit time in milliseconds. When this time passes, the journal is
written. The journal is also written immediately if the FLUSH
request is received.
@@ -163,11 +168,10 @@
the journal. Thus, modified sector number would be detected at
this stage.
-block_size:number
- The size of a data block in bytes. The larger the block size the
+block_size:number (default 512)
+ The size of a data block in bytes. The larger the block size the
less overhead there is for per-block integrity metadata.
- Supported values are 512, 1024, 2048 and 4096 bytes. If not
- specified the default block size is 512 bytes.
+ Supported values are 512, 1024, 2048 and 4096 bytes.
sectors_per_bit:number
In the bitmap mode, this parameter specifies the number of
@@ -209,6 +213,12 @@
should not be changed when reloading the target because the layout of disk
data depend on them and the reloaded target would be non-functional.
+For example, on a device using the default interleave_sectors of 32768, a
+block_size of 512, and an internal_hash of crc32c with a tag size of 4
+bytes, it will take 128 KiB of tags to track a full data area, requiring
+256 sectors of metadata per data area. With the default buffer_sectors of
+128, that means there will be 2 buffers per metadata area, or 2 buffers
+per 16 MiB of data.
Status line:
@@ -286,7 +296,8 @@
Each run contains:
* tag area - it contains integrity tags. There is one tag for each
- sector in the data area
+ sector in the data area. The size of this area is always 4KiB or
+ greater.
* data area - it contains data sectors. The number of data sectors
in one run must be a power of two. log2 of this value is stored
in the superblock.
diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt
index 06c525e..b1b57f6 100644
--- a/Documentation/admin-guide/devices.txt
+++ b/Documentation/admin-guide/devices.txt
@@ -2691,7 +2691,7 @@
45 = /dev/ttyMM1 Marvell MPSC - port 1 (obsolete unused)
46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 3
50 = /dev/ttyIOC0 Altix serial card
...
81 = /dev/ttyIOC31 Altix serial card
diff --git a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
new file mode 100644
index 0000000..264bfa9
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+GDS - Gather Data Sampling
+==========================
+
+Gather Data Sampling is a hardware vulnerability which allows unprivileged
+speculative access to data which was previously stored in vector registers.
+
+Problem
+-------
+When a gather instruction performs loads from memory, different data elements
+are merged into the destination vector register. However, when a gather
+instruction that is transiently executed encounters a fault, stale data from
+architectural or internal vector registers may get transiently forwarded to the
+destination vector register instead. This will allow a malicious attacker to
+infer stale data using typical side channel techniques like cache timing
+attacks. GDS is a purely sampling-based attack.
+
+The attacker uses gather instructions to infer the stale vector register data.
+The victim does not need to do anything special other than use the vector
+registers. The victim does not need to use gather instructions to be
+vulnerable.
+
+Because the buffers are shared between Hyper-Threads cross Hyper-Thread attacks
+are possible.
+
+Attack scenarios
+----------------
+Without mitigation, GDS can infer stale data across virtually all
+permission boundaries:
+
+ Non-enclaves can infer SGX enclave data
+ Userspace can infer kernel data
+ Guests can infer data from hosts
+ Guest can infer guest from other guests
+ Users can infer data from other users
+
+Because of this, it is important to ensure that the mitigation stays enabled in
+lower-privilege contexts like guests and when running outside SGX enclaves.
+
+The hardware enforces the mitigation for SGX. Likewise, VMMs should ensure
+that guests are not allowed to disable the GDS mitigation. If a host erred and
+allowed this, a guest could theoretically disable GDS mitigation, mount an
+attack, and re-enable it.
+
+Mitigation mechanism
+--------------------
+This issue is mitigated in microcode. The microcode defines the following new
+bits:
+
+ ================================ === ============================
+ IA32_ARCH_CAPABILITIES[GDS_CTRL] R/O Enumerates GDS vulnerability
+ and mitigation support.
+ IA32_ARCH_CAPABILITIES[GDS_NO] R/O Processor is not vulnerable.
+ IA32_MCU_OPT_CTRL[GDS_MITG_DIS] R/W Disables the mitigation
+ 0 by default.
+ IA32_MCU_OPT_CTRL[GDS_MITG_LOCK] R/W Locks GDS_MITG_DIS=0. Writes
+ to GDS_MITG_DIS are ignored
+ Can't be cleared once set.
+ ================================ === ============================
+
+GDS can also be mitigated on systems that don't have updated microcode by
+disabling AVX. This can be done by setting gather_data_sampling="force" or
+"clearcpuid=avx" on the kernel command-line.
+
+If used, these options will disable AVX use by turning off XSAVE YMM support.
+However, the processor will still enumerate AVX support. Userspace that
+does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
+support will break.
+
+Mitigation control on the kernel command line
+---------------------------------------------
+The mitigation can be disabled by setting "gather_data_sampling=off" or
+"mitigations=off" on the kernel command line. Not specifying either will default
+to the mitigation being enabled. Specifying "gather_data_sampling=force" will
+use the microcode mitigation when available or disable AVX on affected systems
+where the microcode hasn't been updated to include the mitigation.
+
+GDS System Information
+------------------------
+The kernel provides vulnerability status information through sysfs. For
+GDS this can be accessed by the following sysfs file:
+
+/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
+
+The possible values contained in this file are:
+
+ ============================== =============================================
+ Not affected Processor not vulnerable.
+ Vulnerable Processor vulnerable and mitigation disabled.
+ Vulnerable: No microcode Processor vulnerable and microcode is missing
+ mitigation.
+ Mitigation: AVX disabled,
+ no microcode Processor is vulnerable and microcode is missing
+ mitigation. AVX disabled as mitigation.
+ Mitigation: Microcode Processor is vulnerable and mitigation is in
+ effect.
+ Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
+ effect and cannot be disabled.
+ Unknown: Dependent on
+ hypervisor status Running on a virtual guest processor that is
+ affected but with no way to know if host
+ processor is mitigated or vulnerable.
+ ============================== =============================================
+
+GDS Default mitigation
+----------------------
+The updated microcode will enable the mitigation by default. The kernel's
+default action is to leave the mitigation enabled.
diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst
index e061476..de99caa 100644
--- a/Documentation/admin-guide/hw-vuln/index.rst
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@ -13,9 +13,11 @@
l1tf
mds
tsx_async_abort
- multihit.rst
- special-register-buffer-data-sampling.rst
- core-scheduling.rst
- l1d_flush.rst
- processor_mmio_stale_data.rst
- cross-thread-rsb.rst
+ multihit
+ special-register-buffer-data-sampling
+ core-scheduling
+ l1d_flush
+ processor_mmio_stale_data
+ cross-thread-rsb
+ srso
+ gather_data_sampling
diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst
index 4d186f59..32a8893 100644
--- a/Documentation/admin-guide/hw-vuln/spectre.rst
+++ b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -484,11 +484,14 @@
Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at
boot, by setting the IBRS bit, and they're automatically protected against
- Spectre v2 variant attacks, including cross-thread branch target injections
- on SMT systems (STIBP). In other words, eIBRS enables STIBP too.
+ Spectre v2 variant attacks.
- Legacy IBRS systems clear the IBRS bit on exit to userspace and
- therefore explicitly enable STIBP for that
+ On Intel's enhanced IBRS systems, this includes cross-thread branch target
+ injections on SMT systems (STIBP). In other words, Intel eIBRS enables
+ STIBP, too.
+
+ AMD Automatic IBRS does not protect userspace, and Legacy IBRS systems clear
+ the IBRS bit on exit to userspace, therefore both explicitly enable STIBP.
The retpoline mitigation is turned on by default on vulnerable
CPUs. It can be forced on or off by the administrator
diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst
new file mode 100644
index 0000000..af59a93
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/srso.rst
@@ -0,0 +1,150 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Speculative Return Stack Overflow (SRSO)
+========================================
+
+This is a mitigation for the speculative return stack overflow (SRSO)
+vulnerability found on AMD processors. The mechanism is by now the well
+known scenario of poisoning CPU functional units - the Branch Target
+Buffer (BTB) and Return Address Predictor (RAP) in this case - and then
+tricking the elevated privilege domain (the kernel) into leaking
+sensitive data.
+
+AMD CPUs predict RET instructions using a Return Address Predictor (aka
+Return Address Stack/Return Stack Buffer). In some cases, a non-architectural
+CALL instruction (i.e., an instruction predicted to be a CALL but is
+not actually a CALL) can create an entry in the RAP which may be used
+to predict the target of a subsequent RET instruction.
+
+The specific circumstances that lead to this varies by microarchitecture
+but the concern is that an attacker can mis-train the CPU BTB to predict
+non-architectural CALL instructions in kernel space and use this to
+control the speculative target of a subsequent kernel RET, potentially
+leading to information disclosure via a speculative side-channel.
+
+The issue is tracked under CVE-2023-20569.
+
+Affected processors
+-------------------
+
+AMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older
+processors have not been investigated.
+
+System information and options
+------------------------------
+
+First of all, it is required that the latest microcode be loaded for
+mitigations to be effective.
+
+The sysfs file showing SRSO mitigation status is:
+
+ /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
+
+The possible values in this file are:
+
+ * 'Not affected':
+
+ The processor is not vulnerable
+
+ * 'Vulnerable: no microcode':
+
+ The processor is vulnerable, no microcode extending IBPB
+ functionality to address the vulnerability has been applied.
+
+ * 'Mitigation: microcode':
+
+ Extended IBPB functionality microcode patch has been applied. It does
+ not address User->Kernel and Guest->Host transitions protection but it
+ does address User->User and VM->VM attack vectors.
+
+ Note that User->User mitigation is controlled by how the IBPB aspect in
+ the Spectre v2 mitigation is selected:
+
+ * conditional IBPB:
+
+ where each process can select whether it needs an IBPB issued
+ around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`
+
+ * strict:
+
+ i.e., always on - by supplying spectre_v2_user=on on the kernel
+ command line
+
+ (spec_rstack_overflow=microcode)
+
+ * 'Mitigation: safe RET':
+
+ Software-only mitigation. It complements the extended IBPB microcode
+ patch functionality by addressing User->Kernel and Guest->Host
+ transitions protection.
+
+ Selected by default or by spec_rstack_overflow=safe-ret
+
+ * 'Mitigation: IBPB':
+
+ Similar protection as "safe RET" above but employs an IBPB barrier on
+ privilege domain crossings (User->Kernel, Guest->Host).
+
+ (spec_rstack_overflow=ibpb)
+
+ * 'Mitigation: IBPB on VMEXIT':
+
+ Mitigation addressing the cloud provider scenario - the Guest->Host
+ transitions only.
+
+ (spec_rstack_overflow=ibpb-vmexit)
+
+
+
+In order to exploit vulnerability, an attacker needs to:
+
+ - gain local access on the machine
+
+ - break kASLR
+
+ - find gadgets in the running kernel in order to use them in the exploit
+
+ - potentially create and pin an additional workload on the sibling
+ thread, depending on the microarchitecture (not necessary on fam 0x19)
+
+ - run the exploit
+
+Considering the performance implications of each mitigation type, the
+default one is 'Mitigation: safe RET' which should take care of most
+attack vectors, including the local User->Kernel one.
+
+As always, the user is advised to keep her/his system up-to-date by
+applying software updates regularly.
+
+The default setting will be reevaluated when needed and especially when
+new attack vectors appear.
+
+As one can surmise, 'Mitigation: safe RET' does come at the cost of some
+performance depending on the workload. If one trusts her/his userspace
+and does not want to suffer the performance impact, one can always
+disable the mitigation with spec_rstack_overflow=off.
+
+Similarly, 'Mitigation: IBPB' is another full mitigation type employing
+an indrect branch prediction barrier after having applied the required
+microcode patch for one's system. This mitigation comes also at
+a performance cost.
+
+Mitigation: safe RET
+--------------------
+
+The mitigation works by ensuring all RET instructions speculate to
+a controlled location, similar to how speculation is controlled in the
+retpoline sequence. To accomplish this, the __x86_return_thunk forces
+the CPU to mispredict every function return using a 'safe return'
+sequence.
+
+To ensure the safety of this mitigation, the kernel must ensure that the
+safe return sequence is itself free from attacker interference. In Zen3
+and Zen4, this is accomplished by creating a BTB alias between the
+untraining function srso_untrain_ret_alias() and the safe return
+function srso_safe_ret_alias() which results in evicting a potentially
+poisoned BTB entry and using that safe one for all function returns.
+
+In older Zen1 and Zen2, this is accomplished using a reinterpretation
+technique similar to Retbleed one: srso_untrain_ret() and
+srso_safe_ret().
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index c18d94f..f8ebb63 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -624,3 +624,9 @@
* VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
* VMEMMAP_START ~ VMEMMAP_END : vmemmap space, used for struct page array.
* KERNEL_LINK_ADDR : start address of Kernel link and BPF
+
+va_kernel_pa_offset
+-------------------
+
+Indicates the offset between the kernel virtual and physical mappings.
+Used to translate virtual to physical addresses.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 9e5bab2..722b6ec 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1,17 +1,17 @@
- acpi= [HW,ACPI,X86,ARM64]
+ acpi= [HW,ACPI,X86,ARM64,RISCV64]
Advanced Configuration and Power Interface
Format: { force | on | off | strict | noirq | rsdt |
copy_dsdt }
force -- enable ACPI if default was off
- on -- enable ACPI but allow fallback to DT [arm64]
+ on -- enable ACPI but allow fallback to DT [arm64,riscv64]
off -- disable ACPI if default was on
noirq -- do not use ACPI for IRQ routing
strict -- Be less tolerant of platforms that are not
strictly ACPI specification compliant.
rsdt -- prefer RSDT over (default) XSDT
copy_dsdt -- copy DSDT to memory
- For ARM64, ONLY "acpi=off", "acpi=on" or "acpi=force"
- are available
+ For ARM64 and RISCV64, ONLY "acpi=off", "acpi=on" or
+ "acpi=force" are available
See also Documentation/power/runtime_pm.rst, pci=noacpi
@@ -304,7 +304,7 @@
EL0 is indicated by /sys/devices/system/cpu/aarch32_el0
and hot-unplug operations may be restricted.
- See Documentation/arm64/asymmetric-32bit.rst for more
+ See Documentation/arch/arm64/asymmetric-32bit.rst for more
information.
amd_iommu= [HW,X86-64]
@@ -323,6 +323,7 @@
option with care.
pgtbl_v1 - Use v1 page table for DMA-API (Default).
pgtbl_v2 - Use v2 page table for DMA-API.
+ irtcachedis - Disable Interrupt Remapping Table (IRT) caching.
amd_iommu_dump= [HW,X86-64]
Enable AMD IOMMU driver option to dump the ACPI table
@@ -429,6 +430,9 @@
arm64.nosme [ARM64] Unconditionally disable Scalable Matrix
Extension support
+ arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory
+ Set instructions support
+
ataflop= [HW,M68k]
atarimouse= [HW,MOUSE] Atari Mouse
@@ -818,20 +822,6 @@
Format:
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
- cpu0_hotplug [X86] Turn on CPU0 hotplug feature when
- CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off.
- Some features depend on CPU0. Known dependencies are:
- 1. Resume from suspend/hibernate depends on CPU0.
- Suspend/hibernate will fail if CPU0 is offline and you
- need to online CPU0 before suspend/hibernate.
- 2. PIC interrupts also depend on CPU0. CPU0 can't be
- removed if a PIC interrupt is detected.
- It's said poweroff/reboot may depend on CPU0 on some
- machines although I haven't seen such issues so far
- after CPU0 is offline on a few tested machines.
- If the dependencies are under your control, you can
- turn on cpu0_hotplug.
-
cpuidle.off=1 [CPU_IDLE]
disable the cpuidle sub-system
@@ -852,6 +842,12 @@
on every CPU online, such as boot, and resume from suspend.
Default: 10000
+ cpuhp.parallel=
+ [SMP] Enable/disable parallel bringup of secondary CPUs
+ Format: <bool>
+ Default is enabled if CONFIG_HOTPLUG_PARALLEL=y. Otherwise
+ the parameter has no effect.
+
crash_kexec_post_notifiers
Run kdump after running panic-notifiers and dumping
kmsg. This only for the users who doubt kdump always
@@ -1627,6 +1623,26 @@
Format: off | on
default: on
+ gather_data_sampling=
+ [X86,INTEL] Control the Gather Data Sampling (GDS)
+ mitigation.
+
+ Gather Data Sampling is a hardware vulnerability which
+ allows unprivileged speculative access to data which was
+ previously stored in vector registers.
+
+ This issue is mitigated by default in updated microcode.
+ The mitigation may have a performance impact but can be
+ disabled. On systems without the microcode mitigation
+ disabling AVX serves as a mitigation.
+
+ force: Disable AVX to mitigate systems without
+ microcode mitigation. No effect if the microcode
+ mitigation is present. Known to cause crashes in
+ userspace with buggy AVX enumeration.
+
+ off: Disable GDS mitigation.
+
gcov_persist= [GCOV] When non-zero (default), profiling data for
kernel modules is saved and remains accessible via
debugfs, even when the module is unloaded/reloaded.
@@ -2117,6 +2133,16 @@
disable
Do not enable intel_pstate as the default
scaling driver for the supported processors
+ active
+ Use intel_pstate driver to bypass the scaling
+ governors layer of cpufreq and provides it own
+ algorithms for p-state selection. There are two
+ P-state selection algorithms provided by
+ intel_pstate in the active mode: powersave and
+ performance. The way they both operate depends
+ on whether or not the hardware managed P-states
+ (HWP) feature has been enabled in the processor
+ and possibly on the processor model.
passive
Use intel_pstate as a scaling driver, but configure it
to work with generic cpufreq governors (instead of
@@ -2551,12 +2577,13 @@
If the value is 0 (the default), KVM will pick a period based
on the ratio, such that a page is zapped after 1 hour on average.
- kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM.
- Default is 1 (enabled)
+ kvm-amd.nested= [KVM,AMD] Control nested virtualization feature in
+ KVM/SVM. Default is 1 (enabled).
- kvm-amd.npt= [KVM,AMD] Disable nested paging (virtualized MMU)
- for all guests.
- Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
+ kvm-amd.npt= [KVM,AMD] Control KVM's use of Nested Page Tables,
+ a.k.a. Two-Dimensional Page Tables. Default is 1
+ (enabled). Disable by KVM if hardware lacks support
+ for NPT.
kvm-arm.mode=
[KVM,ARM] Select one of KVM/arm64's modes of operation.
@@ -2602,30 +2629,33 @@
Format: <integer>
Default: 5
- kvm-intel.ept= [KVM,Intel] Disable extended page tables
- (virtualized MMU) support on capable Intel chips.
- Default is 1 (enabled)
+ kvm-intel.ept= [KVM,Intel] Control KVM's use of Extended Page Tables,
+ a.k.a. Two-Dimensional Page Tables. Default is 1
+ (enabled). Disable by KVM if hardware lacks support
+ for EPT.
kvm-intel.emulate_invalid_guest_state=
- [KVM,Intel] Disable emulation of invalid guest state.
- Ignored if kvm-intel.enable_unrestricted_guest=1, as
- guest state is never invalid for unrestricted guests.
- This param doesn't apply to nested guests (L2), as KVM
- never emulates invalid L2 guest state.
- Default is 1 (enabled)
+ [KVM,Intel] Control whether to emulate invalid guest
+ state. Ignored if kvm-intel.enable_unrestricted_guest=1,
+ as guest state is never invalid for unrestricted
+ guests. This param doesn't apply to nested guests (L2),
+ as KVM never emulates invalid L2 guest state.
+ Default is 1 (enabled).
kvm-intel.flexpriority=
- [KVM,Intel] Disable FlexPriority feature (TPR shadow).
- Default is 1 (enabled)
+ [KVM,Intel] Control KVM's use of FlexPriority feature
+ (TPR shadow). Default is 1 (enabled). Disalbe by KVM if
+ hardware lacks support for it.
kvm-intel.nested=
- [KVM,Intel] Enable VMX nesting (nVMX).
- Default is 0 (disabled)
+ [KVM,Intel] Control nested virtualization feature in
+ KVM/VMX. Default is 1 (enabled).
kvm-intel.unrestricted_guest=
- [KVM,Intel] Disable unrestricted guest feature
- (virtualized real and unpaged mode) on capable
- Intel chips. Default is 1 (enabled)
+ [KVM,Intel] Control KVM's use of unrestricted guest
+ feature (virtualized real and unpaged mode). Default
+ is 1 (enabled). Disable by KVM if EPT is disabled or
+ hardware lacks support for it.
kvm-intel.vmentry_l1d_flush=[KVM,Intel] Mitigation for L1 Terminal Fault
CVE-2018-3620.
@@ -2639,9 +2669,10 @@
Default is cond (do L1 cache flush in specific instances)
- kvm-intel.vpid= [KVM,Intel] Disable Virtual Processor Identification
- feature (tagged TLBs) on capable Intel chips.
- Default is 1 (enabled)
+ kvm-intel.vpid= [KVM,Intel] Control KVM's use of Virtual Processor
+ Identification feature (tagged TLBs). Default is 1
+ (enabled). Disable by KVM if hardware lacks support
+ for it.
l1d_flush= [X86,INTEL]
Control mitigation for L1D based snooping vulnerability.
@@ -3262,24 +3293,25 @@
Disable all optional CPU mitigations. This
improves system performance, but it may also
expose users to several CPU vulnerabilities.
- Equivalent to: nopti [X86,PPC]
- if nokaslr then kpti=0 [ARM64]
- nospectre_v1 [X86,PPC]
- nobp=0 [S390]
- nospectre_v2 [X86,PPC,S390,ARM64]
- spectre_v2_user=off [X86]
- spec_store_bypass_disable=off [X86,PPC]
- ssbd=force-off [ARM64]
- nospectre_bhb [ARM64]
+ Equivalent to: if nokaslr then kpti=0 [ARM64]
+ gather_data_sampling=off [X86]
+ kvm.nx_huge_pages=off [X86]
l1tf=off [X86]
mds=off [X86]
- tsx_async_abort=off [X86]
- kvm.nx_huge_pages=off [X86]
- srbds=off [X86,INTEL]
+ mmio_stale_data=off [X86]
no_entry_flush [PPC]
no_uaccess_flush [PPC]
- mmio_stale_data=off [X86]
+ nobp=0 [S390]
+ nopti [X86,PPC]
+ nospectre_bhb [ARM64]
+ nospectre_v1 [X86,PPC]
+ nospectre_v2 [X86,PPC,S390,ARM64]
retbleed=off [X86]
+ spec_store_bypass_disable=off [X86,PPC]
+ spectre_v2_user=off [X86]
+ srbds=off [X86,INTEL]
+ ssbd=force-off [ARM64]
+ tsx_async_abort=off [X86]
Exceptions:
This does not have any effect on
@@ -3423,6 +3455,10 @@
[HW] Make the MicroTouch USB driver use raw coordinates
('y', default) or cooked coordinates ('n')
+ mtrr=debug [X86]
+ Enable printing debug information related to MTRR
+ registers at boot time.
+
mtrr_chunk_size=nn[KMG] [X86]
used for mtrr cleanup. It is largest continuous chunk
that could hold holes aka. UC entries.
@@ -3702,8 +3738,8 @@
nohibernate [HIBERNATION] Disable hibernation and resume.
- nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait
- in do_idle() and not use the arch_cpu_idle()
+ nohlt [ARM,ARM64,MICROBLAZE,MIPS,SH] Forces the kernel to
+ busy wait in do_idle() and not use the arch_cpu_idle()
implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP
to be effective. This is useful on platforms where the
sleep(SH) or wfi(ARM,ARM64) instructions do not work
@@ -3838,7 +3874,7 @@
nosmp [SMP] Tells an SMP kernel to act as a UP kernel,
and disable the IO APIC. legacy for "maxcpus=0".
- nosmt [KNL,S390] Disable symmetric multithreading (SMT).
+ nosmt [KNL,MIPS,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
[KNL,X86] Disable symmetric multithreading (SMT).
@@ -4049,7 +4085,7 @@
extra details on the taint flags that users can pick
to compose the bitmask to assign to panic_on_taint.
- panic_on_warn panic() instead of WARN(). Useful to cause kdump
+ panic_on_warn=1 panic() instead of WARN(). Useful to cause kdump
on a WARN().
parkbd.port= [HW] Parallel port number the keyboard adapter is
@@ -4736,43 +4772,6 @@
the propagation of recent CPU-hotplug changes up
the rcu_node combining tree.
- rcutree.use_softirq= [KNL]
- If set to zero, move all RCU_SOFTIRQ processing to
- per-CPU rcuc kthreads. Defaults to a non-zero
- value, meaning that RCU_SOFTIRQ is used by default.
- Specify rcutree.use_softirq=0 to use rcuc kthreads.
-
- But note that CONFIG_PREEMPT_RT=y kernels disable
- this kernel boot parameter, forcibly setting it
- to zero.
-
- rcutree.rcu_fanout_exact= [KNL]
- Disable autobalancing of the rcu_node combining
- tree. This is used by rcutorture, and might
- possibly be useful for architectures having high
- cache-to-cache transfer latencies.
-
- rcutree.rcu_fanout_leaf= [KNL]
- Change the number of CPUs assigned to each
- leaf rcu_node structure. Useful for very
- large systems, which will choose the value 64,
- and for NUMA systems with large remote-access
- latencies, which will choose a value aligned
- with the appropriate hardware boundaries.
-
- rcutree.rcu_min_cached_objs= [KNL]
- Minimum number of objects which are cached and
- maintained per one CPU. Object size is equal
- to PAGE_SIZE. The cache allows to reduce the
- pressure to page allocator, also it makes the
- whole algorithm to behave better in low memory
- condition.
-
- rcutree.rcu_delay_page_cache_fill_msec= [KNL]
- Set the page-cache refill delay (in milliseconds)
- in response to low-memory conditions. The range
- of permitted values is in the range 0:100000.
-
rcutree.jiffies_till_first_fqs= [KNL]
Set delay from grace-period initialization to
first attempt to force quiescent states.
@@ -4811,21 +4810,6 @@
When RCU_NOCB_CPU is set, also adjust the
priority of NOCB callback kthreads.
- rcutree.rcu_divisor= [KNL]
- Set the shift-right count to use to compute
- the callback-invocation batch limit bl from
- the number of callbacks queued on this CPU.
- The result will be bounded below by the value of
- the rcutree.blimit kernel parameter. Every bl
- callbacks, the softirq handler will exit in
- order to allow the CPU to do other work.
-
- Please note that this callback-invocation batch
- limit applies only to non-offloaded callback
- invocation. Offloaded callbacks are instead
- invoked in the context of an rcuoc kthread, which
- scheduler will preempt as it does any other task.
-
rcutree.nocb_nobypass_lim_per_jiffy= [KNL]
On callback-offloaded (rcu_nocbs) CPUs,
RCU reduces the lock contention that would
@@ -4839,14 +4823,6 @@
the ->nocb_bypass queue. The definition of "too
many" is supplied by this kernel boot parameter.
- rcutree.rcu_nocb_gp_stride= [KNL]
- Set the number of NOCB callback kthreads in
- each group, which defaults to the square root
- of the number of CPUs. Larger numbers reduce
- the wakeup overhead on the global grace-period
- kthread, but increases that same overhead on
- each group's NOCB grace-period kthread.
-
rcutree.qhimark= [KNL]
Set threshold of queued RCU callbacks beyond which
batch limiting is disabled.
@@ -4864,6 +4840,56 @@
on rcutree.qhimark at boot time and to zero to
disable more aggressive help enlistment.
+ rcutree.rcu_delay_page_cache_fill_msec= [KNL]
+ Set the page-cache refill delay (in milliseconds)
+ in response to low-memory conditions. The range
+ of permitted values is in the range 0:100000.
+
+ rcutree.rcu_divisor= [KNL]
+ Set the shift-right count to use to compute
+ the callback-invocation batch limit bl from
+ the number of callbacks queued on this CPU.
+ The result will be bounded below by the value of
+ the rcutree.blimit kernel parameter. Every bl
+ callbacks, the softirq handler will exit in
+ order to allow the CPU to do other work.
+
+ Please note that this callback-invocation batch
+ limit applies only to non-offloaded callback
+ invocation. Offloaded callbacks are instead
+ invoked in the context of an rcuoc kthread, which
+ scheduler will preempt as it does any other task.
+
+ rcutree.rcu_fanout_exact= [KNL]
+ Disable autobalancing of the rcu_node combining
+ tree. This is used by rcutorture, and might
+ possibly be useful for architectures having high
+ cache-to-cache transfer latencies.
+
+ rcutree.rcu_fanout_leaf= [KNL]
+ Change the number of CPUs assigned to each
+ leaf rcu_node structure. Useful for very
+ large systems, which will choose the value 64,
+ and for NUMA systems with large remote-access
+ latencies, which will choose a value aligned
+ with the appropriate hardware boundaries.
+
+ rcutree.rcu_min_cached_objs= [KNL]
+ Minimum number of objects which are cached and
+ maintained per one CPU. Object size is equal
+ to PAGE_SIZE. The cache allows to reduce the
+ pressure to page allocator, also it makes the
+ whole algorithm to behave better in low memory
+ condition.
+
+ rcutree.rcu_nocb_gp_stride= [KNL]
+ Set the number of NOCB callback kthreads in
+ each group, which defaults to the square root
+ of the number of CPUs. Larger numbers reduce
+ the wakeup overhead on the global grace-period
+ kthread, but increases that same overhead on
+ each group's NOCB grace-period kthread.
+
rcutree.rcu_kick_kthreads= [KNL]
Cause the grace-period kthread to get an extra
wake_up() if it sleeps three times longer than
@@ -4871,6 +4897,13 @@
This wake_up() will be accompanied by a
WARN_ONCE() splat and an ftrace_dump().
+ rcutree.rcu_resched_ns= [KNL]
+ Limit the time spend invoking a batch of RCU
+ callbacks to the specified number of nanoseconds.
+ By default, this limit is checked only once
+ every 32 callbacks in order to limit the pain
+ inflicted by local_clock() overhead.
+
rcutree.rcu_unlock_delay= [KNL]
In CONFIG_RCU_STRICT_GRACE_PERIOD=y kernels,
this specifies an rcu_read_unlock()-time delay
@@ -4885,6 +4918,16 @@
rcu_node tree with an eye towards determining
why a new grace period has not yet started.
+ rcutree.use_softirq= [KNL]
+ If set to zero, move all RCU_SOFTIRQ processing to
+ per-CPU rcuc kthreads. Defaults to a non-zero
+ value, meaning that RCU_SOFTIRQ is used by default.
+ Specify rcutree.use_softirq=0 to use rcuc kthreads.
+
+ But note that CONFIG_PREEMPT_RT=y kernels disable
+ this kernel boot parameter, forcibly setting it
+ to zero.
+
rcuscale.gp_async= [KNL]
Measure performance of asynchronous
grace-period primitives such as call_rcu().
@@ -5087,8 +5130,17 @@
rcutorture.stall_cpu_block= [KNL]
Sleep while stalling if set. This will result
- in warnings from preemptible RCU in addition
- to any other stall-related activity.
+ in warnings from preemptible RCU in addition to
+ any other stall-related activity. Note that
+ in kernels built with CONFIG_PREEMPTION=n and
+ CONFIG_PREEMPT_COUNT=y, this parameter will
+ cause the CPU to pass through a quiescent state.
+ Given CONFIG_PREEMPTION=n, this will suppress
+ RCU CPU stall warnings, but will instead result
+ in scheduling-while-atomic splats.
+
+ Use of this module parameter results in splats.
+
rcutorture.stall_cpu_holdoff= [KNL]
Time to wait (s) after boot before inducing stall.
@@ -5452,7 +5504,12 @@
port and the regular usb controller gets disabled.
root= [KNL] Root filesystem
- See name_to_dev_t comment in init/do_mounts.c.
+ Usually this a a block device specifier of some kind,
+ see the early_lookup_bdev comment in
+ block/early-lookup.c for details.
+ Alternatively this can be "ram" for the legacy initial
+ ramdisk, "nfs" and "cifs" for root on a network file
+ system, or "mtd" and "ubi" for mounting from raw flash.
rootdelay= [KNL] Delay (in seconds) to pause before attempting to
mount the root filesystem
@@ -5735,7 +5792,7 @@
1: Fast pin select (default)
2: ATC IRMode
- smt= [KNL,S390] Set the maximum number of threads (logical
+ smt= [KNL,MIPS,S390] Set the maximum number of threads (logical
CPUs) to use per physical CPU on systems capable of
symmetric multithreading (SMT). Will be capped to the
actual hardware limit.
@@ -5839,6 +5896,17 @@
Not specifying this option is equivalent to
spectre_v2_user=auto.
+ spec_rstack_overflow=
+ [X86] Control RAS overflow mitigation on AMD Zen CPUs
+
+ off - Disable mitigation
+ microcode - Enable microcode mitigation only
+ safe-ret - Enable sw-only safe RET mitigation (default)
+ ibpb - Enable mitigation by issuing IBPB on
+ kernel entry
+ ibpb-vmexit - Issue IBPB only on VMEXIT
+ (cloud-specific mitigation)
+
spec_store_bypass_disable=
[HW] Control Speculative Store Bypass (SSB) Disable mitigation
(Speculative Store Bypass vulnerability)
@@ -6563,6 +6631,12 @@
unknown_nmi_panic
[X86] Cause panic on unknown NMI.
+ unwind_debug [X86-64]
+ Enable unwinder debug output. This can be
+ useful for debugging certain unwinder error
+ conditions, including corrupt stacks and
+ bad/missing unwinder metadata.
+
usbcore.authorized_default=
[USB] Default USB device authorization:
(default -1 = authorized except for wireless USB,
@@ -6931,6 +7005,18 @@
it can be updated at runtime by writing to the
corresponding sysfs file.
+ workqueue.cpu_intensive_thresh_us=
+ Per-cpu work items which run for longer than this
+ threshold are automatically considered CPU intensive
+ and excluded from concurrency management to prevent
+ them from noticeably delaying other per-cpu work
+ items. Default is 10000 (10ms).
+
+ If CONFIG_WQ_CPU_INTENSIVE_REPORT is set, the kernel
+ will report the work functions which violate this
+ threshold repeatedly. They are likely good
+ candidates for using WQ_UNBOUND workqueues instead.
+
workqueue.disable_numa
By default, all work items queued to unbound
workqueues are affine to the NUMA nodes they're
diff --git a/Documentation/admin-guide/media/rkisp1.rst b/Documentation/admin-guide/media/rkisp1.rst
index ccf4187..6f14d95 100644
--- a/Documentation/admin-guide/media/rkisp1.rst
+++ b/Documentation/admin-guide/media/rkisp1.rst
@@ -10,8 +10,8 @@
============
This file documents the driver for the Rockchip ISP1 that is part of RK3288
-and RK3399 SoCs. The driver is located under drivers/staging/media/rkisp1
-and uses the Media-Controller API.
+and RK3399 SoCs. The driver is located under drivers/media/platform/rockchip/
+rkisp1 and uses the Media-Controller API.
Revisions
=========
diff --git a/Documentation/admin-guide/mm/damon/start.rst b/Documentation/admin-guide/mm/damon/start.rst
index 9f88afc..7aa0071 100644
--- a/Documentation/admin-guide/mm/damon/start.rst
+++ b/Documentation/admin-guide/mm/damon/start.rst
@@ -119,9 +119,9 @@
Data Access Pattern Aware Memory Management
===========================================
-Below three commands make every memory region of size >=4K that doesn't
-accessed for >=60 seconds in your workload to be swapped out. ::
+Below command makes every memory region of size >=4K that has not accessed for
+>=60 seconds in your workload to be swapped out. ::
- $ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme
- $ echo "4K max 0 0 60s max pageout" >> test_scheme
- $ damo schemes -c test_scheme <pid of your workload>
+ $ sudo damo schemes --damos_access_rate 0 0 --damos_sz_region 4K max \
+ --damos_age 60s max --damos_action pageout \
+ <pid of your workload>
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 9b823fe..2d495fa 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -10,9 +10,8 @@
`This <https://github.com/awslabs/damo>`_ is for privileged people such as
system administrators who want a just-working human-friendly interface.
Using this, users can use the DAMON’s major features in a human-friendly way.
- It may not be highly tuned for special cases, though. It supports both
- virtual and physical address spaces monitoring. For more detail, please
- refer to its `usage document
+ It may not be highly tuned for special cases, though. For more detail,
+ please refer to its `usage document
<https://github.com/awslabs/damo/blob/next/USAGE.md>`_.
- *sysfs interface.*
:ref:`This <sysfs_interface>` is for privileged user space programmers who
@@ -20,11 +19,7 @@
features by reading from and writing to special sysfs files. Therefore,
you can write and use your personalized DAMON sysfs wrapper programs that
reads/writes the sysfs files instead of you. The `DAMON user space tool
- <https://github.com/awslabs/damo>`_ is one example of such programs. It
- supports both virtual and physical address spaces monitoring. Note that this
- interface provides only simple :ref:`statistics <damos_stats>` for the
- monitoring results. For detailed monitoring results, DAMON provides a
- :ref:`tracepoint <tracepoint>`.
+ <https://github.com/awslabs/damo>`_ is one example of such programs.
- *debugfs interface. (DEPRECATED!)*
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
<sysfs_interface>`. This is deprecated, so users should move to the
@@ -139,7 +134,7 @@
file clears the DAMON-based operating scheme action tried regions directory for
each DAMON-based operation scheme of the kdamond. For details of the
DAMON-based operation scheme action tried regions directory, please refer to
-:ref:tried_regions section <sysfs_schemes_tried_regions>`.
+:ref:`tried_regions section <sysfs_schemes_tried_regions>`.
If the state is ``on``, reading ``pid`` shows the pid of the kdamond thread.
@@ -259,12 +254,9 @@
contexts/<N>/schemes/
---------------------
-For usual DAMON-based data access aware memory management optimizations, users
-would normally want the system to apply a memory management action to a memory
-region of a specific access pattern. DAMON receives such formalized operation
-schemes from the user and applies those to the target memory regions. Users
-can get and set the schemes by reading from and writing to files under this
-directory.
+The directory for DAMON-based Operation Schemes (:ref:`DAMOS
+<damon_design_damos>`). Users can get and set the schemes by reading from and
+writing to files under this directory.
In the beginning, this directory has only one file, ``nr_schemes``. Writing a
number (``N``) to the file creates the number of child directories named ``0``
@@ -277,12 +269,12 @@
``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and one file
(``action``) exist.
-The ``action`` file is for setting and getting what action you want to apply to
-memory regions having specific access pattern of the interest. The keywords
-that can be written to and read from the file and their meaning are as below.
+The ``action`` file is for setting and getting the scheme's :ref:`action
+<damon_design_damos_action>`. The keywords that can be written to and read
+from the file and their meaning are as below.
Note that support of each action depends on the running DAMON operations set
-`implementation <sysfs_contexts>`.
+:ref:`implementation <sysfs_contexts>`.
- ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``.
Supported by ``vaddr`` and ``fvaddr`` operations set.
@@ -304,32 +296,21 @@
schemes/<N>/access_pattern/
---------------------------
-The target access pattern of each DAMON-based operation scheme is constructed
-with three ranges including the size of the region in bytes, number of
-monitored accesses per aggregate interval, and number of aggregated intervals
-for the age of the region.
+The directory for the target access :ref:`pattern
+<damon_design_damos_access_pattern>` of the given DAMON-based operation scheme.
Under the ``access_pattern`` directory, three directories (``sz``,
``nr_accesses``, and ``age``) each having two files (``min`` and ``max``)
exist. You can set and get the access pattern for the given scheme by writing
to and reading from the ``min`` and ``max`` files under ``sz``,
-``nr_accesses``, and ``age`` directories, respectively.
+``nr_accesses``, and ``age`` directories, respectively. Note that the ``min``
+and the ``max`` form a closed interval.
schemes/<N>/quotas/
-------------------
-Optimal ``target access pattern`` for each ``action`` is workload dependent, so
-not easy to find. Worse yet, setting a scheme of some action too aggressive
-can cause severe overhead. To avoid such overhead, users can limit time and
-size quota for each scheme. In detail, users can ask DAMON to try to use only
-up to specific time (``time quota``) for applying the action, and to apply the
-action to only up to specific amount (``size quota``) of memory regions having
-the target access pattern within a given time interval (``reset interval``).
-
-When the quota limit is expected to be exceeded, DAMON prioritizes found memory
-regions of the ``target access pattern`` based on their size, access frequency,
-and age. For personalized prioritization, users can set the weights for the
-three properties.
+The directory for the :ref:`quotas <damon_design_damos_quotas>` of the given
+DAMON-based operation scheme.
Under ``quotas`` directory, three files (``ms``, ``bytes``,
``reset_interval_ms``) and one directory (``weights``) having three files
@@ -337,23 +318,26 @@
You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and
``reset interval`` in milliseconds by writing the values to the three files,
-respectively. You can also set the prioritization weights for size, access
-frequency, and age in per-thousand unit by writing the values to the three
-files under the ``weights`` directory.
+respectively. Then, DAMON tries to use only up to ``time quota`` milliseconds
+for applying the ``action`` to memory regions of the ``access_pattern``, and to
+apply the action to only up to ``bytes`` bytes of memory regions within the
+``reset_interval_ms``. Setting both ``ms`` and ``bytes`` zero disables the
+quota limits.
+
+You can also set the :ref:`prioritization weights
+<damon_design_damos_quotas_prioritization>` for size, access frequency, and age
+in per-thousand unit by writing the values to the three files under the
+``weights`` directory.
schemes/<N>/watermarks/
-----------------------
-To allow easy activation and deactivation of each scheme based on system
-status, DAMON provides a feature called watermarks. The feature receives five
-values called ``metric``, ``interval``, ``high``, ``mid``, and ``low``. The
-``metric`` is the system metric such as free memory ratio that can be measured.
-If the metric value of the system is higher than the value in ``high`` or lower
-than ``low`` at the memoent, the scheme is deactivated. If the value is lower
-than ``mid``, the scheme is activated.
+The directory for the :ref:`watermarks <damon_design_damos_watermarks>` of the
+given DAMON-based operation scheme.
Under the watermarks directory, five files (``metric``, ``interval_us``,
-``high``, ``mid``, and ``low``) for setting each value exist. You can set and
+``high``, ``mid``, and ``low``) for setting the metric, the time interval
+between check of the metric, and the three watermarks exist. You can set and
get the five values by writing to the files, respectively.
Keywords and meanings of those that can be written to the ``metric`` file are
@@ -367,12 +351,8 @@
schemes/<N>/filters/
--------------------
-Users could know something more than the kernel for specific types of memory.
-In the case, users could do their own management for the memory and hence
-doesn't want DAMOS bothers that. Users could limit DAMOS by setting the access
-pattern of the scheme and/or the monitoring regions for the purpose, but that
-can be inefficient in some cases. In such cases, users could set non-access
-pattern driven filters using files in this directory.
+The directory for the :ref:`filters <damon_design_damos_filters>` of the given
+DAMON-based operation scheme.
In the beginning, this directory has only one file, ``nr_filters``. Writing a
number (``N``) to the file creates the number of child directories named ``0``
@@ -432,13 +412,17 @@
exposing detailed information about each of the memory region that the
corresponding scheme's ``action`` has tried to be applied under this directory,
during next :ref:`aggregation interval <sysfs_monitoring_attrs>`. The
-information includes address range, ``nr_accesses``, , and ``age`` of the
-region.
+information includes address range, ``nr_accesses``, and ``age`` of the region.
The directories will be removed when another special keyword,
``clear_schemes_tried_regions``, is written to the relevant
``kdamonds/<N>/state`` file.
+The expected usage of this directory is investigations of schemes' behaviors,
+and query-like efficient data access monitoring results retrievals. For the
+latter use case, in particular, users can set the ``action`` as ``stat`` and
+set the ``access pattern`` as their interested pattern that they want to query.
+
tried_regions/<N>/
------------------
@@ -600,15 +584,10 @@
Schemes
-------
-For usual DAMON-based data access aware memory management optimizations, users
-would simply want the system to apply a memory management action to a memory
-region of a specific access pattern. DAMON receives such formalized operation
-schemes from the user and applies those to the target processes.
-
-Users can get and set the schemes by reading from and writing to ``schemes``
-debugfs file. Reading the file also shows the statistics of each scheme. To
-the file, each of the schemes should be represented in each line in below
-form::
+Users can get and set the DAMON-based operation :ref:`schemes
+<damon_design_damos>` by reading from and writing to ``schemes`` debugfs file.
+Reading the file also shows the statistics of each scheme. To the file, each
+of the schemes should be represented in each line in below form::
<target access pattern> <action> <quota> <watermarks>
@@ -617,8 +596,9 @@
Target Access Pattern
~~~~~~~~~~~~~~~~~~~~~
-The ``<target access pattern>`` is constructed with three ranges in below
-form::
+The target access :ref:`pattern <damon_design_damos_access_pattern>` of the
+scheme. The ``<target access pattern>`` is constructed with three ranges in
+below form::
min-size max-size min-acc max-acc min-age max-age
@@ -631,9 +611,9 @@
Action
~~~~~~
-The ``<action>`` is a predefined integer for memory management actions, which
-DAMON will apply to the regions having the target access pattern. The
-supported numbers and their meanings are as below.
+The ``<action>`` is a predefined integer for memory management :ref:`actions
+<damon_design_damos_action>`. The supported numbers and their meanings are as
+below.
- 0: Call ``madvise()`` for the region with ``MADV_WILLNEED``. Ignored if
``target`` is ``paddr``.
@@ -649,10 +629,8 @@
Quota
~~~~~
-Optimal ``target access pattern`` for each ``action`` is workload dependent, so
-not easy to find. Worse yet, setting a scheme of some action too aggressive
-can cause severe overhead. To avoid such overhead, users can limit time and
-size quota for the scheme via the ``<quota>`` in below form::
+Users can set the :ref:`quotas <damon_design_damos_quotas>` of the given scheme
+via the ``<quota>`` in below form::
<ms> <sz> <reset interval> <priority weights>
@@ -662,19 +640,17 @@
``<sz>`` bytes of memory regions within the ``<reset interval>``. Setting both
``<ms>`` and ``<sz>`` zero disables the quota limits.
-When the quota limit is expected to be exceeded, DAMON prioritizes found memory
-regions of the ``target access pattern`` based on their size, access frequency,
-and age. For personalized prioritization, users can set the weights for the
-three properties in ``<priority weights>`` in below form::
+For the :ref:`prioritization <damon_design_damos_quotas_prioritization>`, users
+can set the weights for the three properties in ``<priority weights>`` in below
+form::
<size weight> <access frequency weight> <age weight>
Watermarks
~~~~~~~~~~
-Some schemes would need to run based on current value of the system's specific
-metrics like free memory ratio. For such cases, users can specify watermarks
-for the condition.::
+Users can specify :ref:`watermarks <damon_design_damos_watermarks>` of the
+given scheme via ``<watermarks>`` in below form::
<metric> <check interval> <high mark> <middle mark> <low mark>
@@ -797,10 +773,12 @@
Tracepoint for Monitoring Results
=================================
-DAMON provides the monitoring results via a tracepoint,
-``damon:damon_aggregated``. While the monitoring is turned on, you could
-record the tracepoint events and show results using tracepoint supporting tools
-like ``perf``. For example::
+Users can get the monitoring results via the :ref:`tried_regions
+<sysfs_schemes_tried_regions>` or a tracepoint, ``damon:damon_aggregated``.
+While the tried regions directory is useful for getting a snapshot, the
+tracepoint is useful for getting a full record of the results. While the
+monitoring is turned on, you could record the tracepoint events and show
+results using tracepoint supporting tools like ``perf``. For example::
# echo on > monitor_on
# perf record -e damon:damon_aggregated &
diff --git a/Documentation/admin-guide/perf/cxl.rst b/Documentation/admin-guide/perf/cxl.rst
new file mode 100644
index 0000000..9233ea0
--- /dev/null
+++ b/Documentation/admin-guide/perf/cxl.rst
@@ -0,0 +1,68 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+CXL Performance Monitoring Unit (CPMU)
+======================================
+
+The CXL rev 3.0 specification provides a definition of CXL Performance
+Monitoring Unit in section 13.2: Performance Monitoring.
+
+CXL components (e.g. Root Port, Switch Upstream Port, End Point) may have
+any number of CPMU instances. CPMU capabilities are fully discoverable from
+the devices. The specification provides event definitions for all CXL protocol
+message types and a set of additional events for things commonly counted on
+CXL devices (e.g. DRAM events).
+
+CPMU driver
+===========
+
+The CPMU driver registers a perf PMU with the name pmu_mem<X>.<Y> on the CXL bus
+representing the Yth CPMU for memX.
+
+ /sys/bus/cxl/device/pmu_mem<X>.<Y>
+
+The associated PMU is registered as
+
+ /sys/bus/event_sources/devices/cxl_pmu_mem<X>.<Y>
+
+In common with other CXL bus devices, the id has no specific meaning and the
+relationship to specific CXL device should be established via the device parent
+of the device on the CXL bus.
+
+PMU driver provides description of available events and filter options in sysfs.
+
+The "format" directory describes all formats of the config (event vendor id,
+group id and mask) config1 (threshold, filter enables) and config2 (filter
+parameters) fields of the perf_event_attr structure. The "events" directory
+describes all documented events show in perf list.
+
+The events shown in perf list are the most fine grained events with a single
+bit of the event mask set. More general events may be enable by setting
+multiple mask bits in config. For example, all Device to Host Read Requests
+may be captured on a single counter by setting the bits for all of
+
+* d2h_req_rdcurr
+* d2h_req_rdown
+* d2h_req_rdshared
+* d2h_req_rdany
+* d2h_req_rdownnodata
+
+Example of usage::
+
+ $#perf list
+ cxl_pmu_mem0.0/clock_ticks/ [Kernel PMU event]
+ cxl_pmu_mem0.0/d2h_req_rdshared/ [Kernel PMU event]
+ cxl_pmu_mem0.0/h2d_req_snpcur/ [Kernel PMU event]
+ cxl_pmu_mem0.0/h2d_req_snpdata/ [Kernel PMU event]
+ cxl_pmu_mem0.0/h2d_req_snpinv/ [Kernel PMU event]
+ -----------------------------------------------------------
+
+ $# perf stat -a -e cxl_pmu_mem0.0/clock_ticks/ -e cxl_pmu_mem0.0/d2h_req_rdshared/
+
+Vendor specific events may also be available and if so can be used via
+
+ $# perf stat -a -e cxl_pmu_mem0.0/vid=VID,gid=GID,mask=MASK/
+
+The driver does not support sampling so "perf record" is unsupported.
+It only supports system-wide counting so attaching to a task is
+unsupported.
diff --git a/Documentation/admin-guide/perf/hisi-pmu.rst b/Documentation/admin-guide/perf/hisi-pmu.rst
index 5469793..e0174d2 100644
--- a/Documentation/admin-guide/perf/hisi-pmu.rst
+++ b/Documentation/admin-guide/perf/hisi-pmu.rst
@@ -56,14 +56,14 @@
For HiSilicon uncore PMU v2 whose identifier is 0x30, the topology is the same
as PMU v1, but some new functions are added to the hardware.
-(a) L3C PMU supports filtering by core/thread within the cluster which can be
+1. L3C PMU supports filtering by core/thread within the cluster which can be
specified as a bitmap::
$# perf stat -a -e hisi_sccl3_l3c0/config=0x02,tt_core=0x3/ sleep 5
This will only count the operations from core/thread 0 and 1 in this cluster.
-(b) Tracetag allow the user to chose to count only read, write or atomic
+2. Tracetag allow the user to chose to count only read, write or atomic
operations via the tt_req parameeter in perf. The default value counts all
operations. tt_req is 3bits, 3'b100 represents read operations, 3'b101
represents write operations, 3'b110 represents atomic store operations and
@@ -73,14 +73,16 @@
This will only count the read operations in this cluster.
-(c) Datasrc allows the user to check where the data comes from. It is 5 bits.
+3. Datasrc allows the user to check where the data comes from. It is 5 bits.
Some important codes are as follows:
-5'b00001: comes from L3C in this die;
-5'b01000: comes from L3C in the cross-die;
-5'b01001: comes from L3C which is in another socket;
-5'b01110: comes from the local DDR;
-5'b01111: comes from the cross-die DDR;
-5'b10000: comes from cross-socket DDR;
+
+- 5'b00001: comes from L3C in this die;
+- 5'b01000: comes from L3C in the cross-die;
+- 5'b01001: comes from L3C which is in another socket;
+- 5'b01110: comes from the local DDR;
+- 5'b01111: comes from the cross-die DDR;
+- 5'b10000: comes from cross-socket DDR;
+
etc, it is mainly helpful to find that the data source is nearest from the CPU
cores. If datasrc_cfg is used in the multi-chips, the datasrc_skt shall be
configured in perf command::
@@ -88,15 +90,25 @@
$# perf stat -a -e hisi_sccl3_l3c0/config=0xb9,datasrc_cfg=0xE/,
hisi_sccl3_l3c0/config=0xb9,datasrc_cfg=0xF/ sleep 5
-(d)Some HiSilicon SoCs encapsulate multiple CPU and IO dies. Each CPU die
+4. Some HiSilicon SoCs encapsulate multiple CPU and IO dies. Each CPU die
contains several Compute Clusters (CCLs). The I/O dies are called Super I/O
clusters (SICL) containing multiple I/O clusters (ICLs). Each CCL/ICL in the
SoC has a unique ID. Each ID is 11bits, include a 6-bit SCCL-ID and 5-bit
CCL/ICL-ID. For I/O die, the ICL-ID is followed by:
-5'b00000: I/O_MGMT_ICL;
-5'b00001: Network_ICL;
-5'b00011: HAC_ICL;
-5'b10000: PCIe_ICL;
+
+- 5'b00000: I/O_MGMT_ICL;
+- 5'b00001: Network_ICL;
+- 5'b00011: HAC_ICL;
+- 5'b10000: PCIe_ICL;
+
+5. uring_channel: UC PMU events 0x47~0x59 supports filtering by tx request
+uring channel. It is 2 bits. Some important codes are as follows:
+
+- 2'b11: count the events which sent to the uring_ext (MATA) channel;
+- 2'b01: is the same as 2'b11;
+- 2'b10: count the events which sent to the uring (non-MATA) channel;
+- 2'b00: default value, count the events which sent to the both uring and
+ uring_ext channel;
Users could configure IDs to count data come from specific CCL/ICL, by setting
srcid_cmd & srcid_msk, and data desitined for specific CCL/ICL by setting
diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst
index 9de64a4..f60be04 100644
--- a/Documentation/admin-guide/perf/index.rst
+++ b/Documentation/admin-guide/perf/index.rst
@@ -21,3 +21,4 @@
alibaba_pmu
nvidia-pmu
meson-ddr-pmu
+ cxl
diff --git a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst
index 09169d9..5ab3440 100644
--- a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst
+++ b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst
@@ -5,7 +5,7 @@
Intel Uncore Frequency Scaling
==============================
-:Copyright: |copy| 2022 Intel Corporation
+:Copyright: |copy| 2022-2023 Intel Corporation
:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
@@ -58,3 +58,58 @@
``current_freq_khz``
This attribute is used to get the current uncore frequency.
+
+SoCs with TPMI (Topology Aware Register and PM Capsule Interface)
+-----------------------------------------------------------------
+
+An SoC can contain multiple power domains with individual or collection
+of mesh partitions. This partition is called fabric cluster.
+
+Certain type of meshes will need to run at the same frequency, they will
+be placed in the same fabric cluster. Benefit of fabric cluster is that it
+offers a scalable mechanism to deal with partitioned fabrics in a SoC.
+
+The current sysfs interface supports controls at package and die level.
+This interface is not enough to support more granular control at
+fabric cluster level.
+
+SoCs with the support of TPMI (Topology Aware Register and PM Capsule
+Interface), can have multiple power domains. Each power domain can
+contain one or more fabric clusters.
+
+To represent controls at fabric cluster level in addition to the
+controls at package and die level (like systems without TPMI
+support), sysfs is enhanced. This granular interface is presented in the
+sysfs with directories names prefixed with "uncore". For example:
+uncore00, uncore01 etc.
+
+The scope of control is specified by attributes "package_id", "domain_id"
+and "fabric_cluster_id" in the directory.
+
+Attributes in each directory:
+
+``domain_id``
+ This attribute is used to get the power domain id of this instance.
+
+``fabric_cluster_id``
+ This attribute is used to get the fabric cluster id of this instance.
+
+``package_id``
+ This attribute is used to get the package id of this instance.
+
+The other attributes are same as presented at package_*_die_* level.
+
+In most of current use cases, the "max_freq_khz" and "min_freq_khz"
+is updated at "package_*_die_*" level. This model will be still supported
+with the following approach:
+
+When user uses controls at "package_*_die_*" level, then every fabric
+cluster is affected in that package and die. For example: user changes
+"max_freq_khz" in the package_00_die_00, then "max_freq_khz" for uncore*
+directory with the same package id will be updated. In this case user can
+still update "max_freq_khz" at each uncore* level, which is more restrictive.
+Similarly, user can update "min_freq_khz" at "package_*_die_*" level
+to apply at each uncore* level.
+
+Support for "current_freq_khz" is available only at each fabric cluster
+level (i.e., in uncore* directory).
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index d85d90f..3800fab 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -949,7 +949,7 @@
The default value is 0 (access disabled).
-See Documentation/arm64/perf.rst for more information.
+See Documentation/arch/arm64/perf.rst for more information.
pid_max
diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst
index 466c560..4877563 100644
--- a/Documentation/admin-guide/sysctl/net.rst
+++ b/Documentation/admin-guide/sysctl/net.rst
@@ -386,8 +386,8 @@
txrehash
--------
-Controls default hash rethink behaviour on listening socket when SO_TXREHASH
-option is set to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt).
+Controls default hash rethink behaviour on socket when SO_TXREHASH option is set
+to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt).
If set to 1 (default), hash rethink is performed on listening socket.
If set to 0, hash rethink is not performed.
diff --git a/Documentation/arm/arm.rst b/Documentation/arch/arm/arm.rst
similarity index 100%
rename from Documentation/arm/arm.rst
rename to Documentation/arch/arm/arm.rst
diff --git a/Documentation/arm/booting.rst b/Documentation/arch/arm/booting.rst
similarity index 100%
rename from Documentation/arm/booting.rst
rename to Documentation/arch/arm/booting.rst
diff --git a/Documentation/arm/cluster-pm-race-avoidance.rst b/Documentation/arch/arm/cluster-pm-race-avoidance.rst
similarity index 100%
rename from Documentation/arm/cluster-pm-race-avoidance.rst
rename to Documentation/arch/arm/cluster-pm-race-avoidance.rst
diff --git a/Documentation/arm/features.rst b/Documentation/arch/arm/features.rst
similarity index 100%
rename from Documentation/arm/features.rst
rename to Documentation/arch/arm/features.rst
diff --git a/Documentation/arm/firmware.rst b/Documentation/arch/arm/firmware.rst
similarity index 100%
rename from Documentation/arm/firmware.rst
rename to Documentation/arch/arm/firmware.rst
diff --git a/Documentation/arm/google/chromebook-boot-flow.rst b/Documentation/arch/arm/google/chromebook-boot-flow.rst
similarity index 100%
rename from Documentation/arm/google/chromebook-boot-flow.rst
rename to Documentation/arch/arm/google/chromebook-boot-flow.rst
diff --git a/Documentation/arm/index.rst b/Documentation/arch/arm/index.rst
similarity index 100%
rename from Documentation/arm/index.rst
rename to Documentation/arch/arm/index.rst
diff --git a/Documentation/arm/interrupts.rst b/Documentation/arch/arm/interrupts.rst
similarity index 100%
rename from Documentation/arm/interrupts.rst
rename to Documentation/arch/arm/interrupts.rst
diff --git a/Documentation/arm/ixp4xx.rst b/Documentation/arch/arm/ixp4xx.rst
similarity index 100%
rename from Documentation/arm/ixp4xx.rst
rename to Documentation/arch/arm/ixp4xx.rst
diff --git a/Documentation/arm/kernel_mode_neon.rst b/Documentation/arch/arm/kernel_mode_neon.rst
similarity index 100%
rename from Documentation/arm/kernel_mode_neon.rst
rename to Documentation/arch/arm/kernel_mode_neon.rst
diff --git a/Documentation/arm/kernel_user_helpers.rst b/Documentation/arch/arm/kernel_user_helpers.rst
similarity index 100%
rename from Documentation/arm/kernel_user_helpers.rst
rename to Documentation/arch/arm/kernel_user_helpers.rst
diff --git a/Documentation/arm/keystone/knav-qmss.rst b/Documentation/arch/arm/keystone/knav-qmss.rst
similarity index 100%
rename from Documentation/arm/keystone/knav-qmss.rst
rename to Documentation/arch/arm/keystone/knav-qmss.rst
diff --git a/Documentation/arm/keystone/overview.rst b/Documentation/arch/arm/keystone/overview.rst
similarity index 100%
rename from Documentation/arm/keystone/overview.rst
rename to Documentation/arch/arm/keystone/overview.rst
diff --git a/Documentation/arm/marvell.rst b/Documentation/arch/arm/marvell.rst
similarity index 100%
rename from Documentation/arm/marvell.rst
rename to Documentation/arch/arm/marvell.rst
diff --git a/Documentation/arm/mem_alignment.rst b/Documentation/arch/arm/mem_alignment.rst
similarity index 100%
rename from Documentation/arm/mem_alignment.rst
rename to Documentation/arch/arm/mem_alignment.rst
diff --git a/Documentation/arm/memory.rst b/Documentation/arch/arm/memory.rst
similarity index 100%
rename from Documentation/arm/memory.rst
rename to Documentation/arch/arm/memory.rst
diff --git a/Documentation/arm/microchip.rst b/Documentation/arch/arm/microchip.rst
similarity index 100%
rename from Documentation/arm/microchip.rst
rename to Documentation/arch/arm/microchip.rst
diff --git a/Documentation/arm/netwinder.rst b/Documentation/arch/arm/netwinder.rst
similarity index 100%
rename from Documentation/arm/netwinder.rst
rename to Documentation/arch/arm/netwinder.rst
diff --git a/Documentation/arm/nwfpe/index.rst b/Documentation/arch/arm/nwfpe/index.rst
similarity index 100%
rename from Documentation/arm/nwfpe/index.rst
rename to Documentation/arch/arm/nwfpe/index.rst
diff --git a/Documentation/arm/nwfpe/netwinder-fpe.rst b/Documentation/arch/arm/nwfpe/netwinder-fpe.rst
similarity index 100%
rename from Documentation/arm/nwfpe/netwinder-fpe.rst
rename to Documentation/arch/arm/nwfpe/netwinder-fpe.rst
diff --git a/Documentation/arm/nwfpe/notes.rst b/Documentation/arch/arm/nwfpe/notes.rst
similarity index 100%
rename from Documentation/arm/nwfpe/notes.rst
rename to Documentation/arch/arm/nwfpe/notes.rst
diff --git a/Documentation/arm/nwfpe/nwfpe.rst b/Documentation/arch/arm/nwfpe/nwfpe.rst
similarity index 100%
rename from Documentation/arm/nwfpe/nwfpe.rst
rename to Documentation/arch/arm/nwfpe/nwfpe.rst
diff --git a/Documentation/arm/nwfpe/todo.rst b/Documentation/arch/arm/nwfpe/todo.rst
similarity index 100%
rename from Documentation/arm/nwfpe/todo.rst
rename to Documentation/arch/arm/nwfpe/todo.rst
diff --git a/Documentation/arm/omap/dss.rst b/Documentation/arch/arm/omap/dss.rst
similarity index 100%
rename from Documentation/arm/omap/dss.rst
rename to Documentation/arch/arm/omap/dss.rst
diff --git a/Documentation/arm/omap/index.rst b/Documentation/arch/arm/omap/index.rst
similarity index 100%
rename from Documentation/arm/omap/index.rst
rename to Documentation/arch/arm/omap/index.rst
diff --git a/Documentation/arm/omap/omap.rst b/Documentation/arch/arm/omap/omap.rst
similarity index 100%
rename from Documentation/arm/omap/omap.rst
rename to Documentation/arch/arm/omap/omap.rst
diff --git a/Documentation/arm/omap/omap_pm.rst b/Documentation/arch/arm/omap/omap_pm.rst
similarity index 100%
rename from Documentation/arm/omap/omap_pm.rst
rename to Documentation/arch/arm/omap/omap_pm.rst
diff --git a/Documentation/arm/porting.rst b/Documentation/arch/arm/porting.rst
similarity index 100%
rename from Documentation/arm/porting.rst
rename to Documentation/arch/arm/porting.rst
diff --git a/Documentation/arm/pxa/mfp.rst b/Documentation/arch/arm/pxa/mfp.rst
similarity index 100%
rename from Documentation/arm/pxa/mfp.rst
rename to Documentation/arch/arm/pxa/mfp.rst
diff --git a/Documentation/arm/sa1100/assabet.rst b/Documentation/arch/arm/sa1100/assabet.rst
similarity index 100%
rename from Documentation/arm/sa1100/assabet.rst
rename to Documentation/arch/arm/sa1100/assabet.rst
diff --git a/Documentation/arm/sa1100/cerf.rst b/Documentation/arch/arm/sa1100/cerf.rst
similarity index 100%
rename from Documentation/arm/sa1100/cerf.rst
rename to Documentation/arch/arm/sa1100/cerf.rst
diff --git a/Documentation/arm/sa1100/index.rst b/Documentation/arch/arm/sa1100/index.rst
similarity index 100%
rename from Documentation/arm/sa1100/index.rst
rename to Documentation/arch/arm/sa1100/index.rst
diff --git a/Documentation/arm/sa1100/lart.rst b/Documentation/arch/arm/sa1100/lart.rst
similarity index 100%
rename from Documentation/arm/sa1100/lart.rst
rename to Documentation/arch/arm/sa1100/lart.rst
diff --git a/Documentation/arm/sa1100/serial_uart.rst b/Documentation/arch/arm/sa1100/serial_uart.rst
similarity index 100%
rename from Documentation/arm/sa1100/serial_uart.rst
rename to Documentation/arch/arm/sa1100/serial_uart.rst
diff --git a/Documentation/arm/samsung/bootloader-interface.rst b/Documentation/arch/arm/samsung/bootloader-interface.rst
similarity index 100%
rename from Documentation/arm/samsung/bootloader-interface.rst
rename to Documentation/arch/arm/samsung/bootloader-interface.rst
diff --git a/Documentation/arm/samsung/clksrc-change-registers.awk b/Documentation/arch/arm/samsung/clksrc-change-registers.awk
similarity index 100%
rename from Documentation/arm/samsung/clksrc-change-registers.awk
rename to Documentation/arch/arm/samsung/clksrc-change-registers.awk
diff --git a/Documentation/arm/samsung/gpio.rst b/Documentation/arch/arm/samsung/gpio.rst
similarity index 100%
rename from Documentation/arm/samsung/gpio.rst
rename to Documentation/arch/arm/samsung/gpio.rst
diff --git a/Documentation/arm/samsung/index.rst b/Documentation/arch/arm/samsung/index.rst
similarity index 100%
rename from Documentation/arm/samsung/index.rst
rename to Documentation/arch/arm/samsung/index.rst
diff --git a/Documentation/arm/samsung/overview.rst b/Documentation/arch/arm/samsung/overview.rst
similarity index 100%
rename from Documentation/arm/samsung/overview.rst
rename to Documentation/arch/arm/samsung/overview.rst
diff --git a/Documentation/arm/setup.rst b/Documentation/arch/arm/setup.rst
similarity index 100%
rename from Documentation/arm/setup.rst
rename to Documentation/arch/arm/setup.rst
diff --git a/Documentation/arm/spear/overview.rst b/Documentation/arch/arm/spear/overview.rst
similarity index 100%
rename from Documentation/arm/spear/overview.rst
rename to Documentation/arch/arm/spear/overview.rst
diff --git a/Documentation/arm/sti/overview.rst b/Documentation/arch/arm/sti/overview.rst
similarity index 100%
rename from Documentation/arm/sti/overview.rst
rename to Documentation/arch/arm/sti/overview.rst
diff --git a/Documentation/arm/sti/stih407-overview.rst b/Documentation/arch/arm/sti/stih407-overview.rst
similarity index 100%
rename from Documentation/arm/sti/stih407-overview.rst
rename to Documentation/arch/arm/sti/stih407-overview.rst
diff --git a/Documentation/arm/sti/stih418-overview.rst b/Documentation/arch/arm/sti/stih418-overview.rst
similarity index 100%
rename from Documentation/arm/sti/stih418-overview.rst
rename to Documentation/arch/arm/sti/stih418-overview.rst
diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arch/arm/stm32/overview.rst
similarity index 100%
rename from Documentation/arm/stm32/overview.rst
rename to Documentation/arch/arm/stm32/overview.rst
diff --git a/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst b/Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst
similarity index 100%
rename from Documentation/arm/stm32/stm32-dma-mdma-chaining.rst
rename to Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst
diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arch/arm/stm32/stm32f429-overview.rst
similarity index 100%
rename from Documentation/arm/stm32/stm32f429-overview.rst
rename to Documentation/arch/arm/stm32/stm32f429-overview.rst
diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arch/arm/stm32/stm32f746-overview.rst
similarity index 100%
rename from Documentation/arm/stm32/stm32f746-overview.rst
rename to Documentation/arch/arm/stm32/stm32f746-overview.rst
diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arch/arm/stm32/stm32f769-overview.rst
similarity index 100%
rename from Documentation/arm/stm32/stm32f769-overview.rst
rename to Documentation/arch/arm/stm32/stm32f769-overview.rst
diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arch/arm/stm32/stm32h743-overview.rst
similarity index 100%
rename from Documentation/arm/stm32/stm32h743-overview.rst
rename to Documentation/arch/arm/stm32/stm32h743-overview.rst
diff --git a/Documentation/arm/stm32/stm32h750-overview.rst b/Documentation/arch/arm/stm32/stm32h750-overview.rst
similarity index 100%
rename from Documentation/arm/stm32/stm32h750-overview.rst
rename to Documentation/arch/arm/stm32/stm32h750-overview.rst
diff --git a/Documentation/arm/stm32/stm32mp13-overview.rst b/Documentation/arch/arm/stm32/stm32mp13-overview.rst
similarity index 100%
rename from Documentation/arm/stm32/stm32mp13-overview.rst
rename to Documentation/arch/arm/stm32/stm32mp13-overview.rst
diff --git a/Documentation/arm/stm32/stm32mp151-overview.rst b/Documentation/arch/arm/stm32/stm32mp151-overview.rst
similarity index 100%
rename from Documentation/arm/stm32/stm32mp151-overview.rst
rename to Documentation/arch/arm/stm32/stm32mp151-overview.rst
diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arch/arm/stm32/stm32mp157-overview.rst
similarity index 100%
rename from Documentation/arm/stm32/stm32mp157-overview.rst
rename to Documentation/arch/arm/stm32/stm32mp157-overview.rst
diff --git a/Documentation/arm/sunxi.rst b/Documentation/arch/arm/sunxi.rst
similarity index 100%
rename from Documentation/arm/sunxi.rst
rename to Documentation/arch/arm/sunxi.rst
diff --git a/Documentation/arm/sunxi/clocks.rst b/Documentation/arch/arm/sunxi/clocks.rst
similarity index 100%
rename from Documentation/arm/sunxi/clocks.rst
rename to Documentation/arch/arm/sunxi/clocks.rst
diff --git a/Documentation/arm/swp_emulation.rst b/Documentation/arch/arm/swp_emulation.rst
similarity index 100%
rename from Documentation/arm/swp_emulation.rst
rename to Documentation/arch/arm/swp_emulation.rst
diff --git a/Documentation/arm/tcm.rst b/Documentation/arch/arm/tcm.rst
similarity index 100%
rename from Documentation/arm/tcm.rst
rename to Documentation/arch/arm/tcm.rst
diff --git a/Documentation/arm/uefi.rst b/Documentation/arch/arm/uefi.rst
similarity index 100%
rename from Documentation/arm/uefi.rst
rename to Documentation/arch/arm/uefi.rst
diff --git a/Documentation/arm/vfp/release-notes.rst b/Documentation/arch/arm/vfp/release-notes.rst
similarity index 100%
rename from Documentation/arm/vfp/release-notes.rst
rename to Documentation/arch/arm/vfp/release-notes.rst
diff --git a/Documentation/arm/vlocks.rst b/Documentation/arch/arm/vlocks.rst
similarity index 100%
rename from Documentation/arm/vlocks.rst
rename to Documentation/arch/arm/vlocks.rst
diff --git a/Documentation/arch/arm64/acpi_object_usage.rst b/Documentation/arch/arm64/acpi_object_usage.rst
new file mode 100644
index 0000000..1da2220
--- /dev/null
+++ b/Documentation/arch/arm64/acpi_object_usage.rst
@@ -0,0 +1,809 @@
+===========
+ACPI Tables
+===========
+
+The expectations of individual ACPI tables are discussed in the list that
+follows.
+
+If a section number is used, it refers to a section number in the ACPI
+specification where the object is defined. If "Signature Reserved" is used,
+the table signature (the first four bytes of the table) is the only portion
+of the table recognized by the specification, and the actual table is defined
+outside of the UEFI Forum (see Section 5.2.6 of the specification).
+
+For ACPI on arm64, tables also fall into the following categories:
+
+ - Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
+
+ - Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
+
+ - Optional: AGDI, BGRT, CEDT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT,
+ HMAT, IBFT, IORT, MCHI, MPAM, MPST, MSCT, NFIT, PMTT, PPTT, RASF, SBST,
+ SDEI, SLIT, SPMI, SRAT, STAO, TCPA, TPM2, UEFI, XENV
+
+ - Not supported: AEST, APMT, BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT,
+ MSDM, OEMx, PDTT, PSDT, RAS2, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
+
+====== ========================================================================
+Table Usage for ARMv8 Linux
+====== ========================================================================
+AEST Signature Reserved (signature == "AEST")
+
+ **Arm Error Source Table**
+
+ This table informs the OS of any error nodes in the system that are
+ compliant with the Arm RAS architecture.
+
+AGDI Signature Reserved (signature == "AGDI")
+
+ **Arm Generic diagnostic Dump and Reset Device Interface Table**
+
+ This table describes a non-maskable event, that is used by the platform
+ firmware, to request the OS to generate a diagnostic dump and reset the device.
+
+APMT Signature Reserved (signature == "APMT")
+
+ **Arm Performance Monitoring Table**
+
+ This table describes the properties of PMU support implmented by
+ components in the system.
+
+BERT Section 18.3 (signature == "BERT")
+
+ **Boot Error Record Table**
+
+ Must be supplied if RAS support is provided by the platform. It
+ is recommended this table be supplied.
+
+BOOT Signature Reserved (signature == "BOOT")
+
+ **simple BOOT flag table**
+
+ Microsoft only table, will not be supported.
+
+BGRT Section 5.2.22 (signature == "BGRT")
+
+ **Boot Graphics Resource Table**
+
+ Optional, not currently supported, with no real use-case for an
+ ARM server.
+
+CEDT Signature Reserved (signature == "CEDT")
+
+ **CXL Early Discovery Table**
+
+ This table allows the OS to discover any CXL Host Bridges and the Host
+ Bridge registers.
+
+CPEP Section 5.2.18 (signature == "CPEP")
+
+ **Corrected Platform Error Polling table**
+
+ Optional, not currently supported, and not recommended until such
+ time as ARM-compatible hardware is available, and the specification
+ suitably modified.
+
+CSRT Signature Reserved (signature == "CSRT")
+
+ **Core System Resources Table**
+
+ Optional, not currently supported.
+
+DBG2 Signature Reserved (signature == "DBG2")
+
+ **DeBuG port table 2**
+
+ License has changed and should be usable. Optional if used instead
+ of earlycon=<device> on the command line.
+
+DBGP Signature Reserved (signature == "DBGP")
+
+ **DeBuG Port table**
+
+ Microsoft only table, will not be supported.
+
+DSDT Section 5.2.11.1 (signature == "DSDT")
+
+ **Differentiated System Description Table**
+
+ A DSDT is required; see also SSDT.
+
+ ACPI tables contain only one DSDT but can contain one or more SSDTs,
+ which are optional. Each SSDT can only add to the ACPI namespace,
+ but cannot modify or replace anything in the DSDT.
+
+DMAR Signature Reserved (signature == "DMAR")
+
+ **DMA Remapping table**
+
+ x86 only table, will not be supported.
+
+DRTM Signature Reserved (signature == "DRTM")
+
+ **Dynamic Root of Trust for Measurement table**
+
+ Optional, not currently supported.
+
+ECDT Section 5.2.16 (signature == "ECDT")
+
+ **Embedded Controller Description Table**
+
+ Optional, not currently supported, but could be used on ARM if and
+ only if one uses the GPE_BIT field to represent an IRQ number, since
+ there are no GPE blocks defined in hardware reduced mode. This would
+ need to be modified in the ACPI specification.
+
+EINJ Section 18.6 (signature == "EINJ")
+
+ **Error Injection table**
+
+ This table is very useful for testing platform response to error
+ conditions; it allows one to inject an error into the system as
+ if it had actually occurred. However, this table should not be
+ shipped with a production system; it should be dynamically loaded
+ and executed with the ACPICA tools only during testing.
+
+ERST Section 18.5 (signature == "ERST")
+
+ **Error Record Serialization Table**
+
+ On a platform supports RAS, this table must be supplied if it is not
+ UEFI-based; if it is UEFI-based, this table may be supplied. When this
+ table is not present, UEFI run time service will be utilized to save
+ and retrieve hardware error information to and from a persistent store.
+
+ETDT Signature Reserved (signature == "ETDT")
+
+ **Event Timer Description Table**
+
+ Obsolete table, will not be supported.
+
+FACS Section 5.2.10 (signature == "FACS")
+
+ **Firmware ACPI Control Structure**
+
+ It is unlikely that this table will be terribly useful. If it is
+ provided, the Global Lock will NOT be used since it is not part of
+ the hardware reduced profile, and only 64-bit address fields will
+ be considered valid.
+
+FADT Section 5.2.9 (signature == "FACP")
+
+ **Fixed ACPI Description Table**
+ Required for arm64.
+
+
+ The HW_REDUCED_ACPI flag must be set. All of the fields that are
+ to be ignored when HW_REDUCED_ACPI is set are expected to be set to
+ zero.
+
+ If an FACS table is provided, the X_FIRMWARE_CTRL field is to be
+ used, not FIRMWARE_CTRL.
+
+ If PSCI is used (as is recommended), make sure that ARM_BOOT_ARCH is
+ filled in properly - that the PSCI_COMPLIANT flag is set and that
+ PSCI_USE_HVC is set or unset as needed (see table 5-37).
+
+ For the DSDT that is also required, the X_DSDT field is to be used,
+ not the DSDT field.
+
+FPDT Section 5.2.23 (signature == "FPDT")
+
+ **Firmware Performance Data Table**
+
+ Optional, useful for boot performance profiling.
+
+GTDT Section 5.2.24 (signature == "GTDT")
+
+ **Generic Timer Description Table**
+
+ Required for arm64.
+
+HEST Section 18.3.2 (signature == "HEST")
+
+ **Hardware Error Source Table**
+
+ ARM-specific error sources have been defined; please use those or the
+ PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER
+ Bridge), or use type 9 (Generic Hardware Error Source). Firmware first
+ error handling is possible if and only if Trusted Firmware is being
+ used on arm64.
+
+ Must be supplied if RAS support is provided by the platform. It
+ is recommended this table be supplied.
+
+HMAT Section 5.2.28 (signature == "HMAT")
+
+ **Heterogeneous Memory Attribute Table**
+
+ This table describes the memory attributes, such as memory side cache
+ attributes and bandwidth and latency details, related to Memory Proximity
+ Domains. The OS uses this information to optimize the system memory
+ configuration.
+
+HPET Signature Reserved (signature == "HPET")
+
+ **High Precision Event timer Table**
+
+ x86 only table, will not be supported.
+
+IBFT Signature Reserved (signature == "IBFT")
+
+ **iSCSI Boot Firmware Table**
+
+ Microsoft defined table, support TBD.
+
+IORT Signature Reserved (signature == "IORT")
+
+ **Input Output Remapping Table**
+
+ arm64 only table, required in order to describe IO topology, SMMUs,
+ and GIC ITSs, and how those various components are connected together,
+ such as identifying which components are behind which SMMUs/ITSs.
+ This table will only be required on certain SBSA platforms (e.g.,
+ when using GICv3-ITS and an SMMU); on SBSA Level 0 platforms, it
+ remains optional.
+
+IVRS Signature Reserved (signature == "IVRS")
+
+ **I/O Virtualization Reporting Structure**
+
+ x86_64 (AMD) only table, will not be supported.
+
+LPIT Signature Reserved (signature == "LPIT")
+
+ **Low Power Idle Table**
+
+ x86 only table as of ACPI 5.1; starting with ACPI 6.0, processor
+ descriptions and power states on ARM platforms should use the DSDT
+ and define processor container devices (_HID ACPI0010, Section 8.4,
+ and more specifically 8.4.3 and 8.4.4).
+
+MADT Section 5.2.12 (signature == "APIC")
+
+ **Multiple APIC Description Table**
+
+ Required for arm64. Only the GIC interrupt controller structures
+ should be used (types 0xA - 0xF).
+
+MCFG Signature Reserved (signature == "MCFG")
+
+ **Memory-mapped ConFiGuration space**
+
+ If the platform supports PCI/PCIe, an MCFG table is required.
+
+MCHI Signature Reserved (signature == "MCHI")
+
+ **Management Controller Host Interface table**
+
+ Optional, not currently supported.
+
+MPAM Signature Reserved (signature == "MPAM")
+
+ **Memory Partitioning And Monitoring table**
+
+ This table allows the OS to discover the MPAM controls implemented by
+ the subsystems.
+
+MPST Section 5.2.21 (signature == "MPST")
+
+ **Memory Power State Table**
+
+ Optional, not currently supported.
+
+MSCT Section 5.2.19 (signature == "MSCT")
+
+ **Maximum System Characteristic Table**
+
+ Optional, not currently supported.
+
+MSDM Signature Reserved (signature == "MSDM")
+
+ **Microsoft Data Management table**
+
+ Microsoft only table, will not be supported.
+
+NFIT Section 5.2.25 (signature == "NFIT")
+
+ **NVDIMM Firmware Interface Table**
+
+ Optional, not currently supported.
+
+OEMx Signature of "OEMx" only
+
+ **OEM Specific Tables**
+
+ All tables starting with a signature of "OEM" are reserved for OEM
+ use. Since these are not meant to be of general use but are limited
+ to very specific end users, they are not recommended for use and are
+ not supported by the kernel for arm64.
+
+PCCT Section 14.1 (signature == "PCCT)
+
+ **Platform Communications Channel Table**
+
+ Recommend for use on arm64; use of PCC is recommended when using CPPC
+ to control performance and power for platform processors.
+
+PDTT Section 5.2.29 (signature == "PDTT")
+
+ **Platform Debug Trigger Table**
+
+ This table describes PCC channels used to gather debug logs of
+ non-architectural features.
+
+
+PMTT Section 5.2.21.12 (signature == "PMTT")
+
+ **Platform Memory Topology Table**
+
+ Optional, not currently supported.
+
+PPTT Section 5.2.30 (signature == "PPTT")
+
+ **Processor Properties Topology Table**
+
+ This table provides the processor and cache topology.
+
+PSDT Section 5.2.11.3 (signature == "PSDT")
+
+ **Persistent System Description Table**
+
+ Obsolete table, will not be supported.
+
+RAS2 Section 5.2.21 (signature == "RAS2")
+
+ **RAS Features 2 table**
+
+ This table provides interfaces for the RAS capabilities implemented in
+ the platform.
+
+RASF Section 5.2.20 (signature == "RASF")
+
+ **RAS Feature table**
+
+ Optional, not currently supported.
+
+RSDP Section 5.2.5 (signature == "RSD PTR")
+
+ **Root System Description PoinTeR**
+
+ Required for arm64.
+
+RSDT Section 5.2.7 (signature == "RSDT")
+
+ **Root System Description Table**
+
+ Since this table can only provide 32-bit addresses, it is deprecated
+ on arm64, and will not be used. If provided, it will be ignored.
+
+SBST Section 5.2.14 (signature == "SBST")
+
+ **Smart Battery Subsystem Table**
+
+ Optional, not currently supported.
+
+SDEI Signature Reserved (signature == "SDEI")
+
+ **Software Delegated Exception Interface table**
+
+ This table advertises the presence of the SDEI interface.
+
+SLIC Signature Reserved (signature == "SLIC")
+
+ **Software LIcensing table**
+
+ Microsoft only table, will not be supported.
+
+SLIT Section 5.2.17 (signature == "SLIT")
+
+ **System Locality distance Information Table**
+
+ Optional in general, but required for NUMA systems.
+
+SPCR Signature Reserved (signature == "SPCR")
+
+ **Serial Port Console Redirection table**
+
+ Required for arm64.
+
+SPMI Signature Reserved (signature == "SPMI")
+
+ **Server Platform Management Interface table**
+
+ Optional, not currently supported.
+
+SRAT Section 5.2.16 (signature == "SRAT")
+
+ **System Resource Affinity Table**
+
+ Optional, but if used, only the GICC Affinity structures are read.
+ To support arm64 NUMA, this table is required.
+
+SSDT Section 5.2.11.2 (signature == "SSDT")
+
+ **Secondary System Description Table**
+
+ These tables are a continuation of the DSDT; these are recommended
+ for use with devices that can be added to a running system, but can
+ also serve the purpose of dividing up device descriptions into more
+ manageable pieces.
+
+ An SSDT can only ADD to the ACPI namespace. It cannot modify or
+ replace existing device descriptions already in the namespace.
+
+ These tables are optional, however. ACPI tables should contain only
+ one DSDT but can contain many SSDTs.
+
+STAO Signature Reserved (signature == "STAO")
+
+ **_STA Override table**
+
+ Optional, but only necessary in virtualized environments in order to
+ hide devices from guest OSs.
+
+TCPA Signature Reserved (signature == "TCPA")
+
+ **Trusted Computing Platform Alliance table**
+
+ Optional, not currently supported, and may need changes to fully
+ interoperate with arm64.
+
+TPM2 Signature Reserved (signature == "TPM2")
+
+ **Trusted Platform Module 2 table**
+
+ Optional, not currently supported, and may need changes to fully
+ interoperate with arm64.
+
+UEFI Signature Reserved (signature == "UEFI")
+
+ **UEFI ACPI data table**
+
+ Optional, not currently supported. No known use case for arm64,
+ at present.
+
+WAET Signature Reserved (signature == "WAET")
+
+ **Windows ACPI Emulated devices Table**
+
+ Microsoft only table, will not be supported.
+
+WDAT Signature Reserved (signature == "WDAT")
+
+ **Watch Dog Action Table**
+
+ Microsoft only table, will not be supported.
+
+WDRT Signature Reserved (signature == "WDRT")
+
+ **Watch Dog Resource Table**
+
+ Microsoft only table, will not be supported.
+
+WPBT Signature Reserved (signature == "WPBT")
+
+ **Windows Platform Binary Table**
+
+ Microsoft only table, will not be supported.
+
+XENV Signature Reserved (signature == "XENV")
+
+ **Xen project table**
+
+ Optional, used only by Xen at present.
+
+XSDT Section 5.2.8 (signature == "XSDT")
+
+ **eXtended System Description Table**
+
+ Required for arm64.
+====== ========================================================================
+
+ACPI Objects
+------------
+The expectations on individual ACPI objects that are likely to be used are
+shown in the list that follows; any object not explicitly mentioned below
+should be used as needed for a particular platform or particular subsystem,
+such as power management or PCI.
+
+===== ================ ========================================================
+Name Section Usage for ARMv8 Linux
+===== ================ ========================================================
+_CCA 6.2.17 This method must be defined for all bus masters
+ on arm64 - there are no assumptions made about
+ whether such devices are cache coherent or not.
+ The _CCA value is inherited by all descendants of
+ these devices so it does not need to be repeated.
+ Without _CCA on arm64, the kernel does not know what
+ to do about setting up DMA for the device.
+
+ NB: this method provides default cache coherency
+ attributes; the presence of an SMMU can be used to
+ modify that, however. For example, a master could
+ default to non-coherent, but be made coherent with
+ the appropriate SMMU configuration (see Table 17 of
+ the IORT specification, ARM Document DEN 0049B).
+
+_CID 6.1.2 Use as needed, see also _HID.
+
+_CLS 6.1.3 Use as needed, see also _HID.
+
+_CPC 8.4.7.1 Use as needed, power management specific. CPPC is
+ recommended on arm64.
+
+_CRS 6.2.2 Required on arm64.
+
+_CSD 8.4.2.2 Use as needed, used only in conjunction with _CST.
+
+_CST 8.4.2.1 Low power idle states (8.4.4) are recommended instead
+ of C-states.
+
+_DDN 6.1.4 This field can be used for a device name. However,
+ it is meant for DOS device names (e.g., COM1), so be
+ careful of its use across OSes.
+
+_DSD 6.2.5 To be used with caution. If this object is used, try
+ to use it within the constraints already defined by the
+ Device Properties UUID. Only in rare circumstances
+ should it be necessary to create a new _DSD UUID.
+
+ In either case, submit the _DSD definition along with
+ any driver patches for discussion, especially when
+ device properties are used. A driver will not be
+ considered complete without a corresponding _DSD
+ description. Once approved by kernel maintainers,
+ the UUID or device properties must then be registered
+ with the UEFI Forum; this may cause some iteration as
+ more than one OS will be registering entries.
+
+_DSM 9.1.1 Do not use this method. It is not standardized, the
+ return values are not well documented, and it is
+ currently a frequent source of error.
+
+\_GL 5.7.1 This object is not to be used in hardware reduced
+ mode, and therefore should not be used on arm64.
+
+_GLK 6.5.7 This object requires a global lock be defined; there
+ is no global lock on arm64 since it runs in hardware
+ reduced mode. Hence, do not use this object on arm64.
+
+\_GPE 5.3.1 This namespace is for x86 use only. Do not use it
+ on arm64.
+
+_HID 6.1.5 This is the primary object to use in device probing,
+ though _CID and _CLS may also be used.
+
+_INI 6.5.1 Not required, but can be useful in setting up devices
+ when UEFI leaves them in a state that may not be what
+ the driver expects before it starts probing.
+
+_LPI 8.4.4.3 Recommended for use with processor definitions (_HID
+ ACPI0010) on arm64. See also _RDI.
+
+_MLS 6.1.7 Highly recommended for use in internationalization.
+
+_OFF 7.2.2 It is recommended to define this method for any device
+ that can be turned on or off.
+
+_ON 7.2.3 It is recommended to define this method for any device
+ that can be turned on or off.
+
+\_OS 5.7.3 This method will return "Linux" by default (this is
+ the value of the macro ACPI_OS_NAME on Linux). The
+ command line parameter acpi_os=<string> can be used
+ to set it to some other value.
+
+_OSC 6.2.11 This method can be a global method in ACPI (i.e.,
+ \_SB._OSC), or it may be associated with a specific
+ device (e.g., \_SB.DEV0._OSC), or both. When used
+ as a global method, only capabilities published in
+ the ACPI specification are allowed. When used as
+ a device-specific method, the process described for
+ using _DSD MUST be used to create an _OSC definition;
+ out-of-process use of _OSC is not allowed. That is,
+ submit the device-specific _OSC usage description as
+ part of the kernel driver submission, get it approved
+ by the kernel community, then register it with the
+ UEFI Forum.
+
+\_OSI 5.7.2 Deprecated on ARM64. As far as ACPI firmware is
+ concerned, _OSI is not to be used to determine what
+ sort of system is being used or what functionality
+ is provided. The _OSC method is to be used instead.
+
+_PDC 8.4.1 Deprecated, do not use on arm64.
+
+\_PIC 5.8.1 The method should not be used. On arm64, the only
+ interrupt model available is GIC.
+
+\_PR 5.3.1 This namespace is for x86 use only on legacy systems.
+ Do not use it on arm64.
+
+_PRT 6.2.13 Required as part of the definition of all PCI root
+ devices.
+
+_PRx 7.3.8-11 Use as needed; power management specific. If _PR0 is
+ defined, _PR3 must also be defined.
+
+_PSx 7.3.2-5 Use as needed; power management specific. If _PS0 is
+ defined, _PS3 must also be defined. If clocks or
+ regulators need adjusting to be consistent with power
+ usage, change them in these methods.
+
+_RDI 8.4.4.4 Recommended for use with processor definitions (_HID
+ ACPI0010) on arm64. This should only be used in
+ conjunction with _LPI.
+
+\_REV 5.7.4 Always returns the latest version of ACPI supported.
+
+\_SB 5.3.1 Required on arm64; all devices must be defined in this
+ namespace.
+
+_SLI 6.2.15 Use is recommended when SLIT table is in use.
+
+_STA 6.3.7, It is recommended to define this method for any device
+ 7.2.4 that can be turned on or off. See also the STAO table
+ that provides overrides to hide devices in virtualized
+ environments.
+
+_SRS 6.2.16 Use as needed; see also _PRS.
+
+_STR 6.1.10 Recommended for conveying device names to end users;
+ this is preferred over using _DDN.
+
+_SUB 6.1.9 Use as needed; _HID or _CID are preferred.
+
+_SUN 6.1.11 Use as needed, but recommended.
+
+_SWS 7.4.3 Use as needed; power management specific; this may
+ require specification changes for use on arm64.
+
+_UID 6.1.12 Recommended for distinguishing devices of the same
+ class; define it if at all possible.
+===== ================ ========================================================
+
+
+
+
+ACPI Event Model
+----------------
+Do not use GPE block devices; these are not supported in the hardware reduced
+profile used by arm64. Since there are no GPE blocks defined for use on ARM
+platforms, ACPI events must be signaled differently.
+
+There are two options: GPIO-signaled interrupts (Section 5.6.5), and
+interrupt-signaled events (Section 5.6.9). Interrupt-signaled events are a
+new feature in the ACPI 6.1 specification. Either - or both - can be used
+on a given platform, and which to use may be dependent of limitations in any
+given SoC. If possible, interrupt-signaled events are recommended.
+
+
+ACPI Processor Control
+----------------------
+Section 8 of the ACPI specification changed significantly in version 6.0.
+Processors should now be defined as Device objects with _HID ACPI0007; do
+not use the deprecated Processor statement in ASL. All multiprocessor systems
+should also define a hierarchy of processors, done with Processor Container
+Devices (see Section 8.4.3.1, _HID ACPI0010); do not use processor aggregator
+devices (Section 8.5) to describe processor topology. Section 8.4 of the
+specification describes the semantics of these object definitions and how
+they interrelate.
+
+Most importantly, the processor hierarchy defined also defines the low power
+idle states that are available to the platform, along with the rules for
+determining which processors can be turned on or off and the circumstances
+that control that. Without this information, the processors will run in
+whatever power state they were left in by UEFI.
+
+Note too, that the processor Device objects defined and the entries in the
+MADT for GICs are expected to be in synchronization. The _UID of the Device
+object must correspond to processor IDs used in the MADT.
+
+It is recommended that CPPC (8.4.5) be used as the primary model for processor
+performance control on arm64. C-states and P-states may become available at
+some point in the future, but most current design work appears to favor CPPC.
+
+Further, it is essential that the ARMv8 SoC provide a fully functional
+implementation of PSCI; this will be the only mechanism supported by ACPI
+to control CPU power state. Booting of secondary CPUs using the ACPI
+parking protocol is possible, but discouraged, since only PSCI is supported
+for ARM servers.
+
+
+ACPI System Address Map Interfaces
+----------------------------------
+In Section 15 of the ACPI specification, several methods are mentioned as
+possible mechanisms for conveying memory resource information to the kernel.
+For arm64, we will only support UEFI for booting with ACPI, hence the UEFI
+GetMemoryMap() boot service is the only mechanism that will be used.
+
+
+ACPI Platform Error Interfaces (APEI)
+-------------------------------------
+The APEI tables supported are described above.
+
+APEI requires the equivalent of an SCI and an NMI on ARMv8. The SCI is used
+to notify the OSPM of errors that have occurred but can be corrected and the
+system can continue correct operation, even if possibly degraded. The NMI is
+used to indicate fatal errors that cannot be corrected, and require immediate
+attention.
+
+Since there is no direct equivalent of the x86 SCI or NMI, arm64 handles
+these slightly differently. The SCI is handled as a high priority interrupt;
+given that these are corrected (or correctable) errors being reported, this
+is sufficient. The NMI is emulated as the highest priority interrupt
+possible. This implies some caution must be used since there could be
+interrupts at higher privilege levels or even interrupts at the same priority
+as the emulated NMI. In Linux, this should not be the case but one should
+be aware it could happen.
+
+
+ACPI Objects Not Supported on ARM64
+-----------------------------------
+While this may change in the future, there are several classes of objects
+that can be defined, but are not currently of general interest to ARM servers.
+Some of these objects have x86 equivalents, and may actually make sense in ARM
+servers. However, there is either no hardware available at present, or there
+may not even be a non-ARM implementation yet. Hence, they are not currently
+supported.
+
+The following classes of objects are not supported:
+
+ - Section 9.2: ambient light sensor devices
+
+ - Section 9.3: battery devices
+
+ - Section 9.4: lids (e.g., laptop lids)
+
+ - Section 9.8.2: IDE controllers
+
+ - Section 9.9: floppy controllers
+
+ - Section 9.10: GPE block devices
+
+ - Section 9.15: PC/AT RTC/CMOS devices
+
+ - Section 9.16: user presence detection devices
+
+ - Section 9.17: I/O APIC devices; all GICs must be enumerable via MADT
+
+ - Section 9.18: time and alarm devices (see 9.15)
+
+ - Section 10: power source and power meter devices
+
+ - Section 11: thermal management
+
+ - Section 12: embedded controllers interface
+
+ - Section 13: SMBus interfaces
+
+
+This also means that there is no support for the following objects:
+
+==== =========================== ==== ==========
+Name Section Name Section
+==== =========================== ==== ==========
+_ALC 9.3.4 _FDM 9.10.3
+_ALI 9.3.2 _FIX 6.2.7
+_ALP 9.3.6 _GAI 10.4.5
+_ALR 9.3.5 _GHL 10.4.7
+_ALT 9.3.3 _GTM 9.9.2.1.1
+_BCT 10.2.2.10 _LID 9.5.1
+_BDN 6.5.3 _PAI 10.4.4
+_BIF 10.2.2.1 _PCL 10.3.2
+_BIX 10.2.2.1 _PIF 10.3.3
+_BLT 9.2.3 _PMC 10.4.1
+_BMA 10.2.2.4 _PMD 10.4.8
+_BMC 10.2.2.12 _PMM 10.4.3
+_BMD 10.2.2.11 _PRL 10.3.4
+_BMS 10.2.2.5 _PSR 10.3.1
+_BST 10.2.2.6 _PTP 10.4.2
+_BTH 10.2.2.7 _SBS 10.1.3
+_BTM 10.2.2.9 _SHL 10.4.6
+_BTP 10.2.2.8 _STM 9.9.2.1.1
+_DCK 6.5.2 _UPD 9.16.1
+_EC 12.12 _UPP 9.16.2
+_FDE 9.10.1 _WPC 10.5.2
+_FDI 9.10.2 _WPP 10.5.3
+==== =========================== ==== ==========
diff --git a/Documentation/arm64/amu.rst b/Documentation/arch/arm64/amu.rst
similarity index 100%
rename from Documentation/arm64/amu.rst
rename to Documentation/arch/arm64/amu.rst
diff --git a/Documentation/arch/arm64/arm-acpi.rst b/Documentation/arch/arm64/arm-acpi.rst
new file mode 100644
index 0000000..94274a8
--- /dev/null
+++ b/Documentation/arch/arm64/arm-acpi.rst
@@ -0,0 +1,575 @@
+===================
+ACPI on Arm systems
+===================
+
+ACPI can be used for Armv8 and Armv9 systems designed to follow
+the BSA (Arm Base System Architecture) [0] and BBR (Arm
+Base Boot Requirements) [1] specifications. Both BSA and BBR are publicly
+accessible documents.
+Arm Servers, in addition to being BSA compliant, comply with a set
+of rules defined in SBSA (Server Base System Architecture) [2].
+
+The Arm kernel implements the reduced hardware model of ACPI version
+5.1 or later. Links to the specification and all external documents
+it refers to are managed by the UEFI Forum. The specification is
+available at http://www.uefi.org/specifications and documents referenced
+by the specification can be found via http://www.uefi.org/acpi.
+
+If an Arm system does not meet the requirements of the BSA and BBR,
+or cannot be described using the mechanisms defined in the required ACPI
+specifications, then ACPI may not be a good fit for the hardware.
+
+While the documents mentioned above set out the requirements for building
+industry-standard Arm systems, they also apply to more than one operating
+system. The purpose of this document is to describe the interaction between
+ACPI and Linux only, on an Arm system -- that is, what Linux expects of
+ACPI and what ACPI can expect of Linux.
+
+
+Why ACPI on Arm?
+----------------
+Before examining the details of the interface between ACPI and Linux, it is
+useful to understand why ACPI is being used. Several technologies already
+exist in Linux for describing non-enumerable hardware, after all. In this
+section we summarize a blog post [3] from Grant Likely that outlines the
+reasoning behind ACPI on Arm systems. Actually, we snitch a good portion
+of the summary text almost directly, to be honest.
+
+The short form of the rationale for ACPI on Arm is:
+
+- ACPI’s byte code (AML) allows the platform to encode hardware behavior,
+ while DT explicitly does not support this. For hardware vendors, being
+ able to encode behavior is a key tool used in supporting operating
+ system releases on new hardware.
+
+- ACPI’s OSPM defines a power management model that constrains what the
+ platform is allowed to do into a specific model, while still providing
+ flexibility in hardware design.
+
+- In the enterprise server environment, ACPI has established bindings (such
+ as for RAS) which are currently used in production systems. DT does not.
+ Such bindings could be defined in DT at some point, but doing so means Arm
+ and x86 would end up using completely different code paths in both firmware
+ and the kernel.
+
+- Choosing a single interface to describe the abstraction between a platform
+ and an OS is important. Hardware vendors would not be required to implement
+ both DT and ACPI if they want to support multiple operating systems. And,
+ agreeing on a single interface instead of being fragmented into per OS
+ interfaces makes for better interoperability overall.
+
+- The new ACPI governance process works well and Linux is now at the same
+ table as hardware vendors and other OS vendors. In fact, there is no
+ longer any reason to feel that ACPI only belongs to Windows or that
+ Linux is in any way secondary to Microsoft in this arena. The move of
+ ACPI governance into the UEFI forum has significantly opened up the
+ specification development process, and currently, a large portion of the
+ changes being made to ACPI are being driven by Linux.
+
+Key to the use of ACPI is the support model. For servers in general, the
+responsibility for hardware behaviour cannot solely be the domain of the
+kernel, but rather must be split between the platform and the kernel, in
+order to allow for orderly change over time. ACPI frees the OS from needing
+to understand all the minute details of the hardware so that the OS doesn’t
+need to be ported to each and every device individually. It allows the
+hardware vendors to take responsibility for power management behaviour without
+depending on an OS release cycle which is not under their control.
+
+ACPI is also important because hardware and OS vendors have already worked
+out the mechanisms for supporting a general purpose computing ecosystem. The
+infrastructure is in place, the bindings are in place, and the processes are
+in place. DT does exactly what Linux needs it to when working with vertically
+integrated devices, but there are no good processes for supporting what the
+server vendors need. Linux could potentially get there with DT, but doing so
+really just duplicates something that already works. ACPI already does what
+the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
+vendors would still end up providing two completely separate firmware
+interfaces -- one for Linux and one for Windows.
+
+
+Kernel Compatibility
+--------------------
+One of the primary motivations for ACPI is standardization, and using that
+to provide backward compatibility for Linux kernels. In the server market,
+software and hardware are often used for long periods. ACPI allows the
+kernel and firmware to agree on a consistent abstraction that can be
+maintained over time, even as hardware or software change. As long as the
+abstraction is supported, systems can be updated without necessarily having
+to replace the kernel.
+
+When a Linux driver or subsystem is first implemented using ACPI, it by
+definition ends up requiring a specific version of the ACPI specification
+-- it's baseline. ACPI firmware must continue to work, even though it may
+not be optimal, with the earliest kernel version that first provides support
+for that baseline version of ACPI. There may be a need for additional drivers,
+but adding new functionality (e.g., CPU power management) should not break
+older kernel versions. Further, ACPI firmware must also work with the most
+recent version of the kernel.
+
+
+Relationship with Device Tree
+-----------------------------
+ACPI support in drivers and subsystems for Arm should never be mutually
+exclusive with DT support at compile time.
+
+At boot time the kernel will only use one description method depending on
+parameters passed from the boot loader (including kernel bootargs).
+
+Regardless of whether DT or ACPI is used, the kernel must always be capable
+of booting with either scheme (in kernels with both schemes enabled at compile
+time).
+
+
+Booting using ACPI tables
+-------------------------
+The only defined method for passing ACPI tables to the kernel on Arm
+is via the UEFI system configuration table. Just so it is explicit, this
+means that ACPI is only supported on platforms that boot via UEFI.
+
+When an Arm system boots, it can either have DT information, ACPI tables,
+or in some very unusual cases, both. If no command line parameters are used,
+the kernel will try to use DT for device enumeration; if there is no DT
+present, the kernel will try to use ACPI tables, but only if they are present.
+In neither is available, the kernel will not boot. If acpi=force is used
+on the command line, the kernel will attempt to use ACPI tables first, but
+fall back to DT if there are no ACPI tables present. The basic idea is that
+the kernel will not fail to boot unless it absolutely has no other choice.
+
+Processing of ACPI tables may be disabled by passing acpi=off on the kernel
+command line; this is the default behavior.
+
+In order for the kernel to load and use ACPI tables, the UEFI implementation
+MUST set the ACPI_20_TABLE_GUID to point to the RSDP table (the table with
+the ACPI signature "RSD PTR "). If this pointer is incorrect and acpi=force
+is used, the kernel will disable ACPI and try to use DT to boot instead; the
+kernel has, in effect, determined that ACPI tables are not present at that
+point.
+
+If the pointer to the RSDP table is correct, the table will be mapped into
+the kernel by the ACPI core, using the address provided by UEFI.
+
+The ACPI core will then locate and map in all other ACPI tables provided by
+using the addresses in the RSDP table to find the XSDT (eXtended System
+Description Table). The XSDT in turn provides the addresses to all other
+ACPI tables provided by the system firmware; the ACPI core will then traverse
+this table and map in the tables listed.
+
+The ACPI core will ignore any provided RSDT (Root System Description Table).
+RSDTs have been deprecated and are ignored on arm64 since they only allow
+for 32-bit addresses.
+
+Further, the ACPI core will only use the 64-bit address fields in the FADT
+(Fixed ACPI Description Table). Any 32-bit address fields in the FADT will
+be ignored on arm64.
+
+Hardware reduced mode (see Section 4.1 of the ACPI 6.1 specification) will
+be enforced by the ACPI core on arm64. Doing so allows the ACPI core to
+run less complex code since it no longer has to provide support for legacy
+hardware from other architectures. Any fields that are not to be used for
+hardware reduced mode must be set to zero.
+
+For the ACPI core to operate properly, and in turn provide the information
+the kernel needs to configure devices, it expects to find the following
+tables (all section numbers refer to the ACPI 6.5 specification):
+
+ - RSDP (Root System Description Pointer), section 5.2.5
+
+ - XSDT (eXtended System Description Table), section 5.2.8
+
+ - FADT (Fixed ACPI Description Table), section 5.2.9
+
+ - DSDT (Differentiated System Description Table), section
+ 5.2.11.1
+
+ - MADT (Multiple APIC Description Table), section 5.2.12
+
+ - GTDT (Generic Timer Description Table), section 5.2.24
+
+ - PPTT (Processor Properties Topology Table), section 5.2.30
+
+ - DBG2 (DeBuG port table 2), section 5.2.6, specifically Table 5-6.
+
+ - APMT (Arm Performance Monitoring unit Table), section 5.2.6, specifically Table 5-6.
+
+ - AGDI (Arm Generic diagnostic Dump and Reset Device Interface Table), section 5.2.6, specifically Table 5-6.
+
+ - If PCI is supported, the MCFG (Memory mapped ConFiGuration
+ Table), section 5.2.6, specifically Table 5-6.
+
+ - If booting without a console=<device> kernel parameter is
+ supported, the SPCR (Serial Port Console Redirection table),
+ section 5.2.6, specifically Table 5-6.
+
+ - If necessary to describe the I/O topology, SMMUs and GIC ITSs,
+ the IORT (Input Output Remapping Table, section 5.2.6, specifically
+ Table 5-6).
+
+ - If NUMA is supported, the following tables are required:
+
+ - SRAT (System Resource Affinity Table), section 5.2.16
+
+ - SLIT (System Locality distance Information Table), section 5.2.17
+
+ - If NUMA is supported, and the system contains heterogeneous memory,
+ the HMAT (Heterogeneous Memory Attribute Table), section 5.2.28.
+
+ - If the ACPI Platform Error Interfaces are required, the following
+ tables are conditionally required:
+
+ - BERT (Boot Error Record Table, section 18.3.1)
+
+ - EINJ (Error INJection table, section 18.6.1)
+
+ - ERST (Error Record Serialization Table, section 18.5)
+
+ - HEST (Hardware Error Source Table, section 18.3.2)
+
+ - SDEI (Software Delegated Exception Interface table, section 5.2.6,
+ specifically Table 5-6)
+
+ - AEST (Arm Error Source Table, section 5.2.6,
+ specifically Table 5-6)
+
+ - RAS2 (ACPI RAS2 feature table, section 5.2.21)
+
+ - If the system contains controllers using PCC channel, the
+ PCCT (Platform Communications Channel Table), section 14.1
+
+ - If the system contains a controller to capture board-level system state,
+ and communicates with the host via PCC, the PDTT (Platform Debug Trigger
+ Table), section 5.2.29.
+
+ - If NVDIMM is supported, the NFIT (NVDIMM Firmware Interface Table), section 5.2.26
+
+ - If video framebuffer is present, the BGRT (Boot Graphics Resource Table), section 5.2.23
+
+ - If IPMI is implemented, the SPMI (Server Platform Management Interface),
+ section 5.2.6, specifically Table 5-6.
+
+ - If the system contains a CXL Host Bridge, the CEDT (CXL Early Discovery
+ Table), section 5.2.6, specifically Table 5-6.
+
+ - If the system supports MPAM, the MPAM (Memory Partitioning And Monitoring table), section 5.2.6,
+ specifically Table 5-6.
+
+ - If the system lacks persistent storage, the IBFT (ISCSI Boot Firmware
+ Table), section 5.2.6, specifically Table 5-6.
+
+
+If the above tables are not all present, the kernel may or may not be
+able to boot properly since it may not be able to configure all of the
+devices available. This list of tables is not meant to be all inclusive;
+in some environments other tables may be needed (e.g., any of the APEI
+tables from section 18) to support specific functionality.
+
+
+ACPI Detection
+--------------
+Drivers should determine their probe() type by checking for a null
+value for ACPI_HANDLE, or checking .of_node, or other information in
+the device structure. This is detailed further in the "Driver
+Recommendations" section.
+
+In non-driver code, if the presence of ACPI needs to be detected at
+run time, then check the value of acpi_disabled. If CONFIG_ACPI is not
+set, acpi_disabled will always be 1.
+
+
+Device Enumeration
+------------------
+Device descriptions in ACPI should use standard recognized ACPI interfaces.
+These may contain less information than is typically provided via a Device
+Tree description for the same device. This is also one of the reasons that
+ACPI can be useful -- the driver takes into account that it may have less
+detailed information about the device and uses sensible defaults instead.
+If done properly in the driver, the hardware can change and improve over
+time without the driver having to change at all.
+
+Clocks provide an excellent example. In DT, clocks need to be specified
+and the drivers need to take them into account. In ACPI, the assumption
+is that UEFI will leave the device in a reasonable default state, including
+any clock settings. If for some reason the driver needs to change a clock
+value, this can be done in an ACPI method; all the driver needs to do is
+invoke the method and not concern itself with what the method needs to do
+to change the clock. Changing the hardware can then take place over time
+by changing what the ACPI method does, and not the driver.
+
+In DT, the parameters needed by the driver to set up clocks as in the example
+above are known as "bindings"; in ACPI, these are known as "Device Properties"
+and provided to a driver via the _DSD object.
+
+ACPI tables are described with a formal language called ASL, the ACPI
+Source Language (section 19 of the specification). This means that there
+are always multiple ways to describe the same thing -- including device
+properties. For example, device properties could use an ASL construct
+that looks like this: Name(KEY0, "value0"). An ACPI device driver would
+then retrieve the value of the property by evaluating the KEY0 object.
+However, using Name() this way has multiple problems: (1) ACPI limits
+names ("KEY0") to four characters unlike DT; (2) there is no industry
+wide registry that maintains a list of names, minimizing re-use; (3)
+there is also no registry for the definition of property values ("value0"),
+again making re-use difficult; and (4) how does one maintain backward
+compatibility as new hardware comes out? The _DSD method was created
+to solve precisely these sorts of problems; Linux drivers should ALWAYS
+use the _DSD method for device properties and nothing else.
+
+The _DSM object (ACPI Section 9.14.1) could also be used for conveying
+device properties to a driver. Linux drivers should only expect it to
+be used if _DSD cannot represent the data required, and there is no way
+to create a new UUID for the _DSD object. Note that there is even less
+regulation of the use of _DSM than there is of _DSD. Drivers that depend
+on the contents of _DSM objects will be more difficult to maintain over
+time because of this; as of this writing, the use of _DSM is the cause
+of quite a few firmware problems and is not recommended.
+
+Drivers should look for device properties in the _DSD object ONLY; the _DSD
+object is described in the ACPI specification section 6.2.5, but this only
+describes how to define the structure of an object returned via _DSD, and
+how specific data structures are defined by specific UUIDs. Linux should
+only use the _DSD Device Properties UUID [4]:
+
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
+
+Common device properties can be registered by creating a pull request to [4] so
+that they may be used across all operating systems supporting ACPI.
+Device properties that have not been registered with the UEFI Forum can be used
+but not as "uefi-" common properties.
+
+Before creating new device properties, check to be sure that they have not
+been defined before and either registered in the Linux kernel documentation
+as DT bindings, or the UEFI Forum as device properties. While we do not want
+to simply move all DT bindings into ACPI device properties, we can learn from
+what has been previously defined.
+
+If it is necessary to define a new device property, or if it makes sense to
+synthesize the definition of a binding so it can be used in any firmware,
+both DT bindings and ACPI device properties for device drivers have review
+processes. Use them both. When the driver itself is submitted for review
+to the Linux mailing lists, the device property definitions needed must be
+submitted at the same time. A driver that supports ACPI and uses device
+properties will not be considered complete without their definitions. Once
+the device property has been accepted by the Linux community, it must be
+registered with the UEFI Forum [4], which will review it again for consistency
+within the registry. This may require iteration. The UEFI Forum, though,
+will always be the canonical site for device property definitions.
+
+It may make sense to provide notice to the UEFI Forum that there is the
+intent to register a previously unused device property name as a means of
+reserving the name for later use. Other operating system vendors will
+also be submitting registration requests and this may help smooth the
+process.
+
+Once registration and review have been completed, the kernel provides an
+interface for looking up device properties in a manner independent of
+whether DT or ACPI is being used. This API should be used [5]; it can
+eliminate some duplication of code paths in driver probing functions and
+discourage divergence between DT bindings and ACPI device properties.
+
+
+Programmable Power Control Resources
+------------------------------------
+Programmable power control resources include such resources as voltage/current
+providers (regulators) and clock sources.
+
+With ACPI, the kernel clock and regulator framework is not expected to be used
+at all.
+
+The kernel assumes that power control of these resources is represented with
+Power Resource Objects (ACPI section 7.1). The ACPI core will then handle
+correctly enabling and disabling resources as they are needed. In order to
+get that to work, ACPI assumes each device has defined D-states and that these
+can be controlled through the optional ACPI methods _PS0, _PS1, _PS2, and _PS3;
+in ACPI, _PS0 is the method to invoke to turn a device full on, and _PS3 is for
+turning a device full off.
+
+There are two options for using those Power Resources. They can:
+
+ - be managed in a _PSx method which gets called on entry to power
+ state Dx.
+
+ - be declared separately as power resources with their own _ON and _OFF
+ methods. They are then tied back to D-states for a particular device
+ via _PRx which specifies which power resources a device needs to be on
+ while in Dx. Kernel then tracks number of devices using a power resource
+ and calls _ON/_OFF as needed.
+
+The kernel ACPI code will also assume that the _PSx methods follow the normal
+ACPI rules for such methods:
+
+ - If either _PS0 or _PS3 is implemented, then the other method must also
+ be implemented.
+
+ - If a device requires usage or setup of a power resource when on, the ASL
+ should organize that it is allocated/enabled using the _PS0 method.
+
+ - Resources allocated or enabled in the _PS0 method should be disabled
+ or de-allocated in the _PS3 method.
+
+ - Firmware will leave the resources in a reasonable state before handing
+ over control to the kernel.
+
+Such code in _PSx methods will of course be very platform specific. But,
+this allows the driver to abstract out the interface for operating the device
+and avoid having to read special non-standard values from ACPI tables. Further,
+abstracting the use of these resources allows the hardware to change over time
+without requiring updates to the driver.
+
+
+Clocks
+------
+ACPI makes the assumption that clocks are initialized by the firmware --
+UEFI, in this case -- to some working value before control is handed over
+to the kernel. This has implications for devices such as UARTs, or SoC-driven
+LCD displays, for example.
+
+When the kernel boots, the clocks are assumed to be set to reasonable
+working values. If for some reason the frequency needs to change -- e.g.,
+throttling for power management -- the device driver should expect that
+process to be abstracted out into some ACPI method that can be invoked
+(please see the ACPI specification for further recommendations on standard
+methods to be expected). The only exceptions to this are CPU clocks where
+CPPC provides a much richer interface than ACPI methods. If the clocks
+are not set, there is no direct way for Linux to control them.
+
+If an SoC vendor wants to provide fine-grained control of the system clocks,
+they could do so by providing ACPI methods that could be invoked by Linux
+drivers. However, this is NOT recommended and Linux drivers should NOT use
+such methods, even if they are provided. Such methods are not currently
+standardized in the ACPI specification, and using them could tie a kernel
+to a very specific SoC, or tie an SoC to a very specific version of the
+kernel, both of which we are trying to avoid.
+
+
+Driver Recommendations
+----------------------
+DO NOT remove any DT handling when adding ACPI support for a driver. The
+same device may be used on many different systems.
+
+DO try to structure the driver so that it is data-driven. That is, set up
+a struct containing internal per-device state based on defaults and whatever
+else must be discovered by the driver probe function. Then, have the rest
+of the driver operate off of the contents of that struct. Doing so should
+allow most divergence between ACPI and DT functionality to be kept local to
+the probe function instead of being scattered throughout the driver. For
+example::
+
+ static int device_probe_dt(struct platform_device *pdev)
+ {
+ /* DT specific functionality */
+ ...
+ }
+
+ static int device_probe_acpi(struct platform_device *pdev)
+ {
+ /* ACPI specific functionality */
+ ...
+ }
+
+ static int device_probe(struct platform_device *pdev)
+ {
+ ...
+ struct device_node node = pdev->dev.of_node;
+ ...
+
+ if (node)
+ ret = device_probe_dt(pdev);
+ else if (ACPI_HANDLE(&pdev->dev))
+ ret = device_probe_acpi(pdev);
+ else
+ /* other initialization */
+ ...
+ /* Continue with any generic probe operations */
+ ...
+ }
+
+DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it
+clear the different names the driver is probed for, both from DT and from
+ACPI::
+
+ static struct of_device_id virtio_mmio_match[] = {
+ { .compatible = "virtio,mmio", },
+ { }
+ };
+ MODULE_DEVICE_TABLE(of, virtio_mmio_match);
+
+ static const struct acpi_device_id virtio_mmio_acpi_match[] = {
+ { "LNRO0005", },
+ { }
+ };
+ MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
+
+
+ASWG
+----
+The ACPI specification changes regularly. During the year 2014, for instance,
+version 5.1 was released and version 6.0 substantially completed, with most of
+the changes being driven by Arm-specific requirements. Proposed changes are
+presented and discussed in the ASWG (ACPI Specification Working Group) which
+is a part of the UEFI Forum. The current version of the ACPI specification
+is 6.5 release in August 2022.
+
+Participation in this group is open to all UEFI members. Please see
+http://www.uefi.org/workinggroup for details on group membership.
+
+It is the intent of the Arm ACPI kernel code to follow the ACPI specification
+as closely as possible, and to only implement functionality that complies with
+the released standards from UEFI ASWG. As a practical matter, there will be
+vendors that provide bad ACPI tables or violate the standards in some way.
+If this is because of errors, quirks and fix-ups may be necessary, but will
+be avoided if possible. If there are features missing from ACPI that preclude
+it from being used on a platform, ECRs (Engineering Change Requests) should be
+submitted to ASWG and go through the normal approval process; for those that
+are not UEFI members, many other members of the Linux community are and would
+likely be willing to assist in submitting ECRs.
+
+
+Linux Code
+----------
+Individual items specific to Linux on Arm, contained in the Linux
+source code, are in the list that follows:
+
+ACPI_OS_NAME
+ This macro defines the string to be returned when
+ an ACPI method invokes the _OS method. On Arm
+ systems, this macro will be "Linux" by default.
+ The command line parameter acpi_os=<string>
+ can be used to set it to some other value. The
+ default value for other architectures is "Microsoft
+ Windows NT", for example.
+
+ACPI Objects
+------------
+Detailed expectations for ACPI tables and object are listed in the file
+Documentation/arch/arm64/acpi_object_usage.rst.
+
+
+References
+----------
+[0] https://developer.arm.com/documentation/den0094/latest
+ document Arm-DEN-0094: "Arm Base System Architecture", version 1.0C, dated 6 Oct 2022
+
+[1] https://developer.arm.com/documentation/den0044/latest
+ Document Arm-DEN-0044: "Arm Base Boot Requirements", version 2.0G, dated 15 Apr 2022
+
+[2] https://developer.arm.com/documentation/den0029/latest
+ Document Arm-DEN-0029: "Arm Server Base System Architecture", version 7.1, dated 06 Oct 2022
+
+[3] http://www.secretlab.ca/archives/151,
+ 10 Jan 2015, Copyright (c) 2015,
+ Linaro Ltd., written by Grant Likely.
+
+[4] _DSD (Device Specific Data) Implementation Guide
+ https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf
+
+[5] Kernel code for the unified device
+ property interface can be found in
+ include/linux/property.h and drivers/base/property.c.
+
+
+Authors
+-------
+- Al Stone <al.stone@linaro.org>
+- Graeme Gregory <graeme.gregory@linaro.org>
+- Hanjun Guo <hanjun.guo@linaro.org>
+
+- Grant Likely <grant.likely@linaro.org>, for the "Why ACPI on ARM?" section
diff --git a/Documentation/arm64/asymmetric-32bit.rst b/Documentation/arch/arm64/asymmetric-32bit.rst
similarity index 100%
rename from Documentation/arm64/asymmetric-32bit.rst
rename to Documentation/arch/arm64/asymmetric-32bit.rst
diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst
new file mode 100644
index 0000000..b57776a
--- /dev/null
+++ b/Documentation/arch/arm64/booting.rst
@@ -0,0 +1,463 @@
+=====================
+Booting AArch64 Linux
+=====================
+
+Author: Will Deacon <will.deacon@arm.com>
+
+Date : 07 September 2012
+
+This document is based on the ARM booting document by Russell King and
+is relevant to all public releases of the AArch64 Linux kernel.
+
+The AArch64 exception model is made up of a number of exception levels
+(EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure
+counterpart. EL2 is the hypervisor level, EL3 is the highest priority
+level and exists only in secure mode. Both are architecturally optional.
+
+For the purposes of this document, we will use the term `boot loader`
+simply to define all software that executes on the CPU(s) before control
+is passed to the Linux kernel. This may include secure monitor and
+hypervisor code, or it may just be a handful of instructions for
+preparing a minimal boot environment.
+
+Essentially, the boot loader should provide (as a minimum) the
+following:
+
+1. Setup and initialise the RAM
+2. Setup the device tree
+3. Decompress the kernel image
+4. Call the kernel image
+
+
+1. Setup and initialise RAM
+---------------------------
+
+Requirement: MANDATORY
+
+The boot loader is expected to find and initialise all RAM that the
+kernel will use for volatile data storage in the system. It performs
+this in a machine dependent manner. (It may use internal algorithms
+to automatically locate and size all RAM, or it may use knowledge of
+the RAM in the machine, or any other method the boot loader designer
+sees fit.)
+
+
+2. Setup the device tree
+-------------------------
+
+Requirement: MANDATORY
+
+The device tree blob (dtb) must be placed on an 8-byte boundary and must
+not exceed 2 megabytes in size. Since the dtb will be mapped cacheable
+using blocks of up to 2 megabytes in size, it must not be placed within
+any 2M region which must be mapped with any specific attributes.
+
+NOTE: versions prior to v4.2 also require that the DTB be placed within
+the 512 MB region starting at text_offset bytes below the kernel Image.
+
+3. Decompress the kernel image
+------------------------------
+
+Requirement: OPTIONAL
+
+The AArch64 kernel does not currently provide a decompressor and
+therefore requires decompression (gzip etc.) to be performed by the boot
+loader if a compressed Image target (e.g. Image.gz) is used. For
+bootloaders that do not implement this requirement, the uncompressed
+Image target is available instead.
+
+
+4. Call the kernel image
+------------------------
+
+Requirement: MANDATORY
+
+The decompressed kernel image contains a 64-byte header as follows::
+
+ u32 code0; /* Executable code */
+ u32 code1; /* Executable code */
+ u64 text_offset; /* Image load offset, little endian */
+ u64 image_size; /* Effective Image size, little endian */
+ u64 flags; /* kernel flags, little endian */
+ u64 res2 = 0; /* reserved */
+ u64 res3 = 0; /* reserved */
+ u64 res4 = 0; /* reserved */
+ u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
+ u32 res5; /* reserved (used for PE COFF offset) */
+
+
+Header notes:
+
+- As of v3.17, all fields are little endian unless stated otherwise.
+
+- code0/code1 are responsible for branching to stext.
+
+- when booting through EFI, code0/code1 are initially skipped.
+ res5 is an offset to the PE header and the PE header has the EFI
+ entry point (efi_stub_entry). When the stub has done its work, it
+ jumps to code0 to resume the normal boot process.
+
+- Prior to v3.17, the endianness of text_offset was not specified. In
+ these cases image_size is zero and text_offset is 0x80000 in the
+ endianness of the kernel. Where image_size is non-zero image_size is
+ little-endian and must be respected. Where image_size is zero,
+ text_offset can be assumed to be 0x80000.
+
+- The flags field (introduced in v3.17) is a little-endian 64-bit field
+ composed as follows:
+
+ ============= ===============================================================
+ Bit 0 Kernel endianness. 1 if BE, 0 if LE.
+ Bit 1-2 Kernel Page size.
+
+ * 0 - Unspecified.
+ * 1 - 4K
+ * 2 - 16K
+ * 3 - 64K
+ Bit 3 Kernel physical placement
+
+ 0
+ 2MB aligned base should be as close as possible
+ to the base of DRAM, since memory below it is not
+ accessible via the linear mapping
+ 1
+ 2MB aligned base such that all image_size bytes
+ counted from the start of the image are within
+ the 48-bit addressable range of physical memory
+ Bits 4-63 Reserved.
+ ============= ===============================================================
+
+- When image_size is zero, a bootloader should attempt to keep as much
+ memory as possible free for use by the kernel immediately after the
+ end of the kernel image. The amount of space required will vary
+ depending on selected features, and is effectively unbound.
+
+The Image must be placed text_offset bytes from a 2MB aligned base
+address anywhere in usable system RAM and called there. The region
+between the 2 MB aligned base address and the start of the image has no
+special significance to the kernel, and may be used for other purposes.
+At least image_size bytes from the start of the image must be free for
+use by the kernel.
+NOTE: versions prior to v4.6 cannot make use of memory below the
+physical offset of the Image so it is recommended that the Image be
+placed as close as possible to the start of system RAM.
+
+If an initrd/initramfs is passed to the kernel at boot, it must reside
+entirely within a 1 GB aligned physical memory window of up to 32 GB in
+size that fully covers the kernel Image as well.
+
+Any memory described to the kernel (even that below the start of the
+image) which is not marked as reserved from the kernel (e.g., with a
+memreserve region in the device tree) will be considered as available to
+the kernel.
+
+Before jumping into the kernel, the following conditions must be met:
+
+- Quiesce all DMA capable devices so that memory does not get
+ corrupted by bogus network packets or disk data. This will save
+ you many hours of debug.
+
+- Primary CPU general-purpose register settings:
+
+ - x0 = physical address of device tree blob (dtb) in system RAM.
+ - x1 = 0 (reserved for future use)
+ - x2 = 0 (reserved for future use)
+ - x3 = 0 (reserved for future use)
+
+- CPU mode
+
+ All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
+ IRQ and FIQ).
+ The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order
+ to have access to the virtualisation extensions), or in EL1.
+
+- Caches, MMUs
+
+ The MMU must be off.
+
+ The instruction cache may be on or off, and must not hold any stale
+ entries corresponding to the loaded kernel image.
+
+ The address range corresponding to the loaded kernel image must be
+ cleaned to the PoC. In the presence of a system cache or other
+ coherent masters with caches enabled, this will typically require
+ cache maintenance by VA rather than set/way operations.
+ System caches which respect the architected cache maintenance by VA
+ operations must be configured and may be enabled.
+ System caches which do not respect architected cache maintenance by VA
+ operations (not recommended) must be configured and disabled.
+
+- Architected timers
+
+ CNTFRQ must be programmed with the timer frequency and CNTVOFF must
+ be programmed with a consistent value on all CPUs. If entering the
+ kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where
+ available.
+
+- Coherency
+
+ All CPUs to be booted by the kernel must be part of the same coherency
+ domain on entry to the kernel. This may require IMPLEMENTATION DEFINED
+ initialisation to enable the receiving of maintenance operations on
+ each CPU.
+
+- System registers
+
+ All writable architected system registers at or below the exception
+ level where the kernel image will be entered must be initialised by
+ software at a higher exception level to prevent execution in an UNKNOWN
+ state.
+
+ For all systems:
+ - If EL3 is present:
+
+ - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
+ executing on.
+ - The value of SCR_EL3.FIQ must be the same as the one present at boot
+ time whenever the kernel is executing.
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.HCE (bit 8) must be initialised to 0b1.
+
+ For systems with a GICv3 interrupt controller to be used in v3 mode:
+ - If EL3 is present:
+
+ - ICC_SRE_EL3.Enable (bit 3) must be initialised to 0b1.
+ - ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
+ - ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across
+ all CPUs the kernel is executing on, and must stay constant
+ for the lifetime of the kernel.
+
+ - If the kernel is entered at EL1:
+
+ - ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
+ - ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
+
+ - The DT or ACPI tables must describe a GICv3 interrupt controller.
+
+ For systems with a GICv3 interrupt controller to be used in
+ compatibility (v2) mode:
+
+ - If EL3 is present:
+
+ ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0.
+
+ - If the kernel is entered at EL1:
+
+ ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.
+
+ - The DT or ACPI tables must describe a GICv2 interrupt controller.
+
+ For CPUs with pointer authentication functionality:
+
+ - If EL3 is present:
+
+ - SCR_EL3.APK (bit 16) must be initialised to 0b1
+ - SCR_EL3.API (bit 17) must be initialised to 0b1
+
+ - If the kernel is entered at EL1:
+
+ - HCR_EL2.APK (bit 40) must be initialised to 0b1
+ - HCR_EL2.API (bit 41) must be initialised to 0b1
+
+ For CPUs with Activity Monitors Unit v1 (AMUv1) extension present:
+
+ - If EL3 is present:
+
+ - CPTR_EL3.TAM (bit 30) must be initialised to 0b0
+ - CPTR_EL2.TAM (bit 30) must be initialised to 0b0
+ - AMCNTENSET0_EL0 must be initialised to 0b1111
+ - AMCNTENSET1_EL0 must be initialised to a platform specific value
+ having 0b1 set for the corresponding bit for each of the auxiliary
+ counters present.
+
+ - If the kernel is entered at EL1:
+
+ - AMCNTENSET0_EL0 must be initialised to 0b1111
+ - AMCNTENSET1_EL0 must be initialised to a platform specific value
+ having 0b1 set for the corresponding bit for each of the auxiliary
+ counters present.
+
+ For CPUs with the Fine Grained Traps (FEAT_FGT) extension present:
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
+
+ For CPUs with support for HCRX_EL2 (FEAT_HCX) present:
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.HXEn (bit 38) must be initialised to 0b1.
+
+ For CPUs with Advanced SIMD and floating point support:
+
+ - If EL3 is present:
+
+ - CPTR_EL3.TFP (bit 10) must be initialised to 0b0.
+
+ - If EL2 is present and the kernel is entered at EL1:
+
+ - CPTR_EL2.TFP (bit 10) must be initialised to 0b0.
+
+ For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
+
+ - if EL3 is present:
+
+ - CPTR_EL3.EZ (bit 8) must be initialised to 0b1.
+
+ - ZCR_EL3.LEN must be initialised to the same value for all CPUs the
+ kernel is executed on.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - CPTR_EL2.TZ (bit 8) must be initialised to 0b0.
+
+ - CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11.
+
+ - ZCR_EL2.LEN must be initialised to the same value for all CPUs the
+ kernel will execute on.
+
+ For CPUs with the Scalable Matrix Extension (FEAT_SME):
+
+ - If EL3 is present:
+
+ - CPTR_EL3.ESM (bit 12) must be initialised to 0b1.
+
+ - SCR_EL3.EnTP2 (bit 41) must be initialised to 0b1.
+
+ - SMCR_EL3.LEN must be initialised to the same value for all CPUs the
+ kernel will execute on.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - CPTR_EL2.TSM (bit 12) must be initialised to 0b0.
+
+ - CPTR_EL2.SMEN (bits 25:24) must be initialised to 0b11.
+
+ - SCTLR_EL2.EnTP2 (bit 60) must be initialised to 0b1.
+
+ - SMCR_EL2.LEN must be initialised to the same value for all CPUs the
+ kernel will execute on.
+
+ - HWFGRTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
+
+ - HWFGWTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
+
+ - HWFGRTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
+
+ - HWFGWTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
+
+ For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64):
+
+ - If EL3 is present:
+
+ - SMCR_EL3.FA64 (bit 31) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - SMCR_EL2.FA64 (bit 31) must be initialised to 0b1.
+
+ For CPUs with the Memory Tagging Extension feature (FEAT_MTE2):
+
+ - If EL3 is present:
+
+ - SCR_EL3.ATA (bit 26) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
+
+ For CPUs with the Scalable Matrix Extension version 2 (FEAT_SME2):
+
+ - If EL3 is present:
+
+ - SMCR_EL3.EZT0 (bit 30) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1.
+
+ For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS):
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1.
+
+ For CPUs with the Extended Translation Control Register feature (FEAT_TCR2):
+
+ - If EL3 is present:
+
+ - SCR_EL3.TCR2En (bit 43) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HCRX_EL2.TCR2En (bit 14) must be initialised to 0b1.
+
+ For CPUs with the Stage 1 Permission Indirection Extension feature (FEAT_S1PIE):
+
+ - If EL3 is present:
+
+ - SCR_EL3.PIEn (bit 45) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HFGRTR_EL2.nPIR_EL1 (bit 58) must be initialised to 0b1.
+
+ - HFGWTR_EL2.nPIR_EL1 (bit 58) must be initialised to 0b1.
+
+ - HFGRTR_EL2.nPIRE0_EL1 (bit 57) must be initialised to 0b1.
+
+ - HFGRWR_EL2.nPIRE0_EL1 (bit 57) must be initialised to 0b1.
+
+The requirements described above for CPU mode, caches, MMUs, architected
+timers, coherency and system registers apply to all CPUs. All CPUs must
+enter the kernel in the same exception level. Where the values documented
+disable traps it is permissible for these traps to be enabled so long as
+those traps are handled transparently by higher exception levels as though
+the values documented were set.
+
+The boot loader is expected to enter the kernel on each CPU in the
+following manner:
+
+- The primary CPU must jump directly to the first instruction of the
+ kernel image. The device tree blob passed by this CPU must contain
+ an 'enable-method' property for each cpu node. The supported
+ enable-methods are described below.
+
+ It is expected that the bootloader will generate these device tree
+ properties and insert them into the blob prior to kernel entry.
+
+- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr'
+ property in their cpu node. This property identifies a
+ naturally-aligned 64-bit zero-initalised memory location.
+
+ These CPUs should spin outside of the kernel in a reserved area of
+ memory (communicated to the kernel by a /memreserve/ region in the
+ device tree) polling their cpu-release-addr location, which must be
+ contained in the reserved region. A wfe instruction may be inserted
+ to reduce the overhead of the busy-loop and a sev will be issued by
+ the primary CPU. When a read of the location pointed to by the
+ cpu-release-addr returns a non-zero value, the CPU must jump to this
+ value. The value will be written as a single 64-bit little-endian
+ value, so CPUs must convert the read value to their native endianness
+ before jumping to it.
+
+- CPUs with a "psci" enable method should remain outside of
+ the kernel (i.e. outside of the regions of memory described to the
+ kernel in the memory node, or in a reserved area of memory described
+ to the kernel by a /memreserve/ region in the device tree). The
+ kernel will issue CPU_ON calls as described in ARM document number ARM
+ DEN 0022A ("Power State Coordination Interface System Software on ARM
+ processors") to bring CPUs into the kernel.
+
+ The device tree should contain a 'psci' node, as described in
+ Documentation/devicetree/bindings/arm/psci.yaml.
+
+- Secondary CPU general-purpose register settings
+
+ - x0 = 0 (reserved for future use)
+ - x1 = 0 (reserved for future use)
+ - x2 = 0 (reserved for future use)
+ - x3 = 0 (reserved for future use)
diff --git a/Documentation/arch/arm64/cpu-feature-registers.rst b/Documentation/arch/arm64/cpu-feature-registers.rst
new file mode 100644
index 0000000..4e4625f
--- /dev/null
+++ b/Documentation/arch/arm64/cpu-feature-registers.rst
@@ -0,0 +1,402 @@
+===========================
+ARM64 CPU Feature Registers
+===========================
+
+Author: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+
+This file describes the ABI for exporting the AArch64 CPU ID/feature
+registers to userspace. The availability of this ABI is advertised
+via the HWCAP_CPUID in HWCAPs.
+
+1. Motivation
+-------------
+
+The ARM architecture defines a set of feature registers, which describe
+the capabilities of the CPU/system. Access to these system registers is
+restricted from EL0 and there is no reliable way for an application to
+extract this information to make better decisions at runtime. There is
+limited information available to the application via HWCAPs, however
+there are some issues with their usage.
+
+ a) Any change to the HWCAPs requires an update to userspace (e.g libc)
+ to detect the new changes, which can take a long time to appear in
+ distributions. Exposing the registers allows applications to get the
+ information without requiring updates to the toolchains.
+
+ b) Access to HWCAPs is sometimes limited (e.g prior to libc, or
+ when ld is initialised at startup time).
+
+ c) HWCAPs cannot represent non-boolean information effectively. The
+ architecture defines a canonical format for representing features
+ in the ID registers; this is well defined and is capable of
+ representing all valid architecture variations.
+
+
+2. Requirements
+---------------
+
+ a) Safety:
+
+ Applications should be able to use the information provided by the
+ infrastructure to run safely across the system. This has greater
+ implications on a system with heterogeneous CPUs.
+ The infrastructure exports a value that is safe across all the
+ available CPU on the system.
+
+ e.g, If at least one CPU doesn't implement CRC32 instructions, while
+ others do, we should report that the CRC32 is not implemented.
+ Otherwise an application could crash when scheduled on the CPU
+ which doesn't support CRC32.
+
+ b) Security:
+
+ Applications should only be able to receive information that is
+ relevant to the normal operation in userspace. Hence, some of the
+ fields are masked out(i.e, made invisible) and their values are set to
+ indicate the feature is 'not supported'. See Section 4 for the list
+ of visible features. Also, the kernel may manipulate the fields
+ based on what it supports. e.g, If FP is not supported by the
+ kernel, the values could indicate that the FP is not available
+ (even when the CPU provides it).
+
+ c) Implementation Defined Features
+
+ The infrastructure doesn't expose any register which is
+ IMPLEMENTATION DEFINED as per ARMv8-A Architecture.
+
+ d) CPU Identification:
+
+ MIDR_EL1 is exposed to help identify the processor. On a
+ heterogeneous system, this could be racy (just like getcpu()). The
+ process could be migrated to another CPU by the time it uses the
+ register value, unless the CPU affinity is set. Hence, there is no
+ guarantee that the value reflects the processor that it is
+ currently executing on. The REVIDR is not exposed due to this
+ constraint, as REVIDR makes sense only in conjunction with the
+ MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
+ at::
+
+ /sys/devices/system/cpu/cpu$ID/regs/identification/
+ \- midr
+ \- revidr
+
+3. Implementation
+--------------------
+
+The infrastructure is built on the emulation of the 'MRS' instruction.
+Accessing a restricted system register from an application generates an
+exception and ends up in SIGILL being delivered to the process.
+The infrastructure hooks into the exception handler and emulates the
+operation if the source belongs to the supported system register space.
+
+The infrastructure emulates only the following system register space::
+
+ Op0=3, Op1=0, CRn=0, CRm=0,2,3,4,5,6,7
+
+(See Table C5-6 'System instruction encodings for non-Debug System
+register accesses' in ARMv8 ARM DDI 0487A.h, for the list of
+registers).
+
+The following rules are applied to the value returned by the
+infrastructure:
+
+ a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0.
+ b) The value of a reserved field is populated with the reserved
+ value as defined by the architecture.
+ c) The value of a 'visible' field holds the system wide safe value
+ for the particular feature (except for MIDR_EL1, see section 4).
+ d) All other fields (i.e, invisible fields) are set to indicate
+ the feature is missing (as defined by the architecture).
+
+4. List of registers with visible features
+-------------------------------------------
+
+ 1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | RNDR | [63-60] | y |
+ +------------------------------+---------+---------+
+ | TS | [55-52] | y |
+ +------------------------------+---------+---------+
+ | FHM | [51-48] | y |
+ +------------------------------+---------+---------+
+ | DP | [47-44] | y |
+ +------------------------------+---------+---------+
+ | SM4 | [43-40] | y |
+ +------------------------------+---------+---------+
+ | SM3 | [39-36] | y |
+ +------------------------------+---------+---------+
+ | SHA3 | [35-32] | y |
+ +------------------------------+---------+---------+
+ | RDM | [31-28] | y |
+ +------------------------------+---------+---------+
+ | ATOMICS | [23-20] | y |
+ +------------------------------+---------+---------+
+ | CRC32 | [19-16] | y |
+ +------------------------------+---------+---------+
+ | SHA2 | [15-12] | y |
+ +------------------------------+---------+---------+
+ | SHA1 | [11-8] | y |
+ +------------------------------+---------+---------+
+ | AES | [7-4] | y |
+ +------------------------------+---------+---------+
+
+
+ 2) ID_AA64PFR0_EL1 - Processor Feature Register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | DIT | [51-48] | y |
+ +------------------------------+---------+---------+
+ | SVE | [35-32] | y |
+ +------------------------------+---------+---------+
+ | GIC | [27-24] | n |
+ +------------------------------+---------+---------+
+ | AdvSIMD | [23-20] | y |
+ +------------------------------+---------+---------+
+ | FP | [19-16] | y |
+ +------------------------------+---------+---------+
+ | EL3 | [15-12] | n |
+ +------------------------------+---------+---------+
+ | EL2 | [11-8] | n |
+ +------------------------------+---------+---------+
+ | EL1 | [7-4] | n |
+ +------------------------------+---------+---------+
+ | EL0 | [3-0] | n |
+ +------------------------------+---------+---------+
+
+
+ 3) ID_AA64PFR1_EL1 - Processor Feature Register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | MTE | [11-8] | y |
+ +------------------------------+---------+---------+
+ | SSBS | [7-4] | y |
+ +------------------------------+---------+---------+
+ | BT | [3-0] | y |
+ +------------------------------+---------+---------+
+
+
+ 4) MIDR_EL1 - Main ID Register
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | Implementer | [31-24] | y |
+ +------------------------------+---------+---------+
+ | Variant | [23-20] | y |
+ +------------------------------+---------+---------+
+ | Architecture | [19-16] | y |
+ +------------------------------+---------+---------+
+ | PartNum | [15-4] | y |
+ +------------------------------+---------+---------+
+ | Revision | [3-0] | y |
+ +------------------------------+---------+---------+
+
+ NOTE: The 'visible' fields of MIDR_EL1 will contain the value
+ as available on the CPU where it is fetched and is not a system
+ wide safe value.
+
+ 5) ID_AA64ISAR1_EL1 - Instruction set attribute register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | I8MM | [55-52] | y |
+ +------------------------------+---------+---------+
+ | DGH | [51-48] | y |
+ +------------------------------+---------+---------+
+ | BF16 | [47-44] | y |
+ +------------------------------+---------+---------+
+ | SB | [39-36] | y |
+ +------------------------------+---------+---------+
+ | FRINTTS | [35-32] | y |
+ +------------------------------+---------+---------+
+ | GPI | [31-28] | y |
+ +------------------------------+---------+---------+
+ | GPA | [27-24] | y |
+ +------------------------------+---------+---------+
+ | LRCPC | [23-20] | y |
+ +------------------------------+---------+---------+
+ | FCMA | [19-16] | y |
+ +------------------------------+---------+---------+
+ | JSCVT | [15-12] | y |
+ +------------------------------+---------+---------+
+ | API | [11-8] | y |
+ +------------------------------+---------+---------+
+ | APA | [7-4] | y |
+ +------------------------------+---------+---------+
+ | DPB | [3-0] | y |
+ +------------------------------+---------+---------+
+
+ 6) ID_AA64MMFR0_EL1 - Memory model feature register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | ECV | [63-60] | y |
+ +------------------------------+---------+---------+
+
+ 7) ID_AA64MMFR2_EL1 - Memory model feature register 2
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | AT | [35-32] | y |
+ +------------------------------+---------+---------+
+
+ 8) ID_AA64ZFR0_EL1 - SVE feature ID register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | F64MM | [59-56] | y |
+ +------------------------------+---------+---------+
+ | F32MM | [55-52] | y |
+ +------------------------------+---------+---------+
+ | I8MM | [47-44] | y |
+ +------------------------------+---------+---------+
+ | SM4 | [43-40] | y |
+ +------------------------------+---------+---------+
+ | SHA3 | [35-32] | y |
+ +------------------------------+---------+---------+
+ | BF16 | [23-20] | y |
+ +------------------------------+---------+---------+
+ | BitPerm | [19-16] | y |
+ +------------------------------+---------+---------+
+ | AES | [7-4] | y |
+ +------------------------------+---------+---------+
+ | SVEVer | [3-0] | y |
+ +------------------------------+---------+---------+
+
+ 8) ID_AA64MMFR1_EL1 - Memory model feature register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | AFP | [47-44] | y |
+ +------------------------------+---------+---------+
+
+ 9) ID_AA64ISAR2_EL1 - Instruction set attribute register 2
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | MOPS | [19-16] | y |
+ +------------------------------+---------+---------+
+ | RPRES | [7-4] | y |
+ +------------------------------+---------+---------+
+ | WFXT | [3-0] | y |
+ +------------------------------+---------+---------+
+
+ 10) MVFR0_EL1 - AArch32 Media and VFP Feature Register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | FPDP | [11-8] | y |
+ +------------------------------+---------+---------+
+
+ 11) MVFR1_EL1 - AArch32 Media and VFP Feature Register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | SIMDFMAC | [31-28] | y |
+ +------------------------------+---------+---------+
+ | SIMDSP | [19-16] | y |
+ +------------------------------+---------+---------+
+ | SIMDInt | [15-12] | y |
+ +------------------------------+---------+---------+
+ | SIMDLS | [11-8] | y |
+ +------------------------------+---------+---------+
+
+ 12) ID_ISAR5_EL1 - AArch32 Instruction Set Attribute Register 5
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | CRC32 | [19-16] | y |
+ +------------------------------+---------+---------+
+ | SHA2 | [15-12] | y |
+ +------------------------------+---------+---------+
+ | SHA1 | [11-8] | y |
+ +------------------------------+---------+---------+
+ | AES | [7-4] | y |
+ +------------------------------+---------+---------+
+
+
+Appendix I: Example
+-------------------
+
+::
+
+ /*
+ * Sample program to demonstrate the MRS emulation ABI.
+ *
+ * Copyright (C) 2015-2016, ARM Ltd
+ *
+ * Author: Suzuki K Poulose <suzuki.poulose@arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+ #include <asm/hwcap.h>
+ #include <stdio.h>
+ #include <sys/auxv.h>
+
+ #define get_cpu_ftr(id) ({ \
+ unsigned long __val; \
+ asm("mrs %0, "#id : "=r" (__val)); \
+ printf("%-20s: 0x%016lx\n", #id, __val); \
+ })
+
+ int main(void)
+ {
+
+ if (!(getauxval(AT_HWCAP) & HWCAP_CPUID)) {
+ fputs("CPUID registers unavailable\n", stderr);
+ return 1;
+ }
+
+ get_cpu_ftr(ID_AA64ISAR0_EL1);
+ get_cpu_ftr(ID_AA64ISAR1_EL1);
+ get_cpu_ftr(ID_AA64MMFR0_EL1);
+ get_cpu_ftr(ID_AA64MMFR1_EL1);
+ get_cpu_ftr(ID_AA64PFR0_EL1);
+ get_cpu_ftr(ID_AA64PFR1_EL1);
+ get_cpu_ftr(ID_AA64DFR0_EL1);
+ get_cpu_ftr(ID_AA64DFR1_EL1);
+
+ get_cpu_ftr(MIDR_EL1);
+ get_cpu_ftr(MPIDR_EL1);
+ get_cpu_ftr(REVIDR_EL1);
+
+ #if 0
+ /* Unexposed register access causes SIGILL */
+ get_cpu_ftr(ID_MMFR0_EL1);
+ #endif
+
+ return 0;
+ }
diff --git a/Documentation/arch/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst
new file mode 100644
index 0000000..8c8addb
--- /dev/null
+++ b/Documentation/arch/arm64/elf_hwcaps.rst
@@ -0,0 +1,312 @@
+.. _elf_hwcaps_index:
+
+================
+ARM64 ELF hwcaps
+================
+
+This document describes the usage and semantics of the arm64 ELF hwcaps.
+
+
+1. Introduction
+---------------
+
+Some hardware or software features are only available on some CPU
+implementations, and/or with certain kernel configurations, but have no
+architected discovery mechanism available to userspace code at EL0. The
+kernel exposes the presence of these features to userspace through a set
+of flags called hwcaps, exposed in the auxiliary vector.
+
+Userspace software can test for features by acquiring the AT_HWCAP or
+AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
+flags are set, e.g.::
+
+ bool floating_point_is_present(void)
+ {
+ unsigned long hwcaps = getauxval(AT_HWCAP);
+ if (hwcaps & HWCAP_FP)
+ return true;
+
+ return false;
+ }
+
+Where software relies on a feature described by a hwcap, it should check
+the relevant hwcap flag to verify that the feature is present before
+attempting to make use of the feature.
+
+Features cannot be probed reliably through other means. When a feature
+is not available, attempting to use it may result in unpredictable
+behaviour, and is not guaranteed to result in any reliable indication
+that the feature is unavailable, such as a SIGILL.
+
+
+2. Interpretation of hwcaps
+---------------------------
+
+The majority of hwcaps are intended to indicate the presence of features
+which are described by architected ID registers inaccessible to
+userspace code at EL0. These hwcaps are defined in terms of ID register
+fields, and should be interpreted with reference to the definition of
+these fields in the ARM Architecture Reference Manual (ARM ARM).
+
+Such hwcaps are described below in the form::
+
+ Functionality implied by idreg.field == val.
+
+Such hwcaps indicate the availability of functionality that the ARM ARM
+defines as being present when idreg.field has value val, but do not
+indicate that idreg.field is precisely equal to val, nor do they
+indicate the absence of functionality implied by other values of
+idreg.field.
+
+Other hwcaps may indicate the presence of features which cannot be
+described by ID registers alone. These may be described without
+reference to ID registers, and may refer to other documentation.
+
+
+3. The hwcaps exposed in AT_HWCAP
+---------------------------------
+
+HWCAP_FP
+ Functionality implied by ID_AA64PFR0_EL1.FP == 0b0000.
+
+HWCAP_ASIMD
+ Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0000.
+
+HWCAP_EVTSTRM
+ The generic timer is configured to generate events at a frequency of
+ approximately 10KHz.
+
+HWCAP_AES
+ Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001.
+
+HWCAP_PMULL
+ Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0010.
+
+HWCAP_SHA1
+ Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001.
+
+HWCAP_SHA2
+ Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001.
+
+HWCAP_CRC32
+ Functionality implied by ID_AA64ISAR0_EL1.CRC32 == 0b0001.
+
+HWCAP_ATOMICS
+ Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0010.
+
+HWCAP_FPHP
+ Functionality implied by ID_AA64PFR0_EL1.FP == 0b0001.
+
+HWCAP_ASIMDHP
+ Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0001.
+
+HWCAP_CPUID
+ EL0 access to certain ID registers is available, to the extent
+ described by Documentation/arch/arm64/cpu-feature-registers.rst.
+
+ These ID registers may imply the availability of features.
+
+HWCAP_ASIMDRDM
+ Functionality implied by ID_AA64ISAR0_EL1.RDM == 0b0001.
+
+HWCAP_JSCVT
+ Functionality implied by ID_AA64ISAR1_EL1.JSCVT == 0b0001.
+
+HWCAP_FCMA
+ Functionality implied by ID_AA64ISAR1_EL1.FCMA == 0b0001.
+
+HWCAP_LRCPC
+ Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0001.
+
+HWCAP_DCPOP
+ Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001.
+
+HWCAP_SHA3
+ Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
+
+HWCAP_SM3
+ Functionality implied by ID_AA64ISAR0_EL1.SM3 == 0b0001.
+
+HWCAP_SM4
+ Functionality implied by ID_AA64ISAR0_EL1.SM4 == 0b0001.
+
+HWCAP_ASIMDDP
+ Functionality implied by ID_AA64ISAR0_EL1.DP == 0b0001.
+
+HWCAP_SHA512
+ Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010.
+
+HWCAP_SVE
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
+
+HWCAP_ASIMDFHM
+ Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
+
+HWCAP_DIT
+ Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001.
+
+HWCAP_USCAT
+ Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001.
+
+HWCAP_ILRCPC
+ Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0010.
+
+HWCAP_FLAGM
+ Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001.
+
+HWCAP_SSBS
+ Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010.
+
+HWCAP_SB
+ Functionality implied by ID_AA64ISAR1_EL1.SB == 0b0001.
+
+HWCAP_PACA
+ Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or
+ ID_AA64ISAR1_EL1.API == 0b0001, as described by
+ Documentation/arch/arm64/pointer-authentication.rst.
+
+HWCAP_PACG
+ Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
+ ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
+ Documentation/arch/arm64/pointer-authentication.rst.
+
+HWCAP2_DCPODP
+ Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
+
+HWCAP2_SVE2
+ Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
+
+HWCAP2_SVEAES
+ Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
+
+HWCAP2_SVEPMULL
+ Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010.
+
+HWCAP2_SVEBITPERM
+ Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001.
+
+HWCAP2_SVESHA3
+ Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001.
+
+HWCAP2_SVESM4
+ Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
+
+HWCAP2_FLAGM2
+ Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
+
+HWCAP2_FRINT
+ Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
+
+HWCAP2_SVEI8MM
+ Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001.
+
+HWCAP2_SVEF32MM
+ Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001.
+
+HWCAP2_SVEF64MM
+ Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001.
+
+HWCAP2_SVEBF16
+ Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001.
+
+HWCAP2_I8MM
+ Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
+
+HWCAP2_BF16
+ Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0001.
+
+HWCAP2_DGH
+ Functionality implied by ID_AA64ISAR1_EL1.DGH == 0b0001.
+
+HWCAP2_RNG
+ Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
+
+HWCAP2_BTI
+ Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
+
+HWCAP2_MTE
+ Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
+ by Documentation/arch/arm64/memory-tagging-extension.rst.
+
+HWCAP2_ECV
+ Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
+
+HWCAP2_AFP
+ Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
+
+HWCAP2_RPRES
+ Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
+
+HWCAP2_MTE3
+ Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
+ by Documentation/arch/arm64/memory-tagging-extension.rst.
+
+HWCAP2_SME
+ Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described
+ by Documentation/arch/arm64/sme.rst.
+
+HWCAP2_SME_I16I64
+ Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111.
+
+HWCAP2_SME_F64F64
+ Functionality implied by ID_AA64SMFR0_EL1.F64F64 == 0b1.
+
+HWCAP2_SME_I8I32
+ Functionality implied by ID_AA64SMFR0_EL1.I8I32 == 0b1111.
+
+HWCAP2_SME_F16F32
+ Functionality implied by ID_AA64SMFR0_EL1.F16F32 == 0b1.
+
+HWCAP2_SME_B16F32
+ Functionality implied by ID_AA64SMFR0_EL1.B16F32 == 0b1.
+
+HWCAP2_SME_F32F32
+ Functionality implied by ID_AA64SMFR0_EL1.F32F32 == 0b1.
+
+HWCAP2_SME_FA64
+ Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1.
+
+HWCAP2_WFXT
+ Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
+
+HWCAP2_EBF16
+ Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
+
+HWCAP2_SVE_EBF16
+ Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0010.
+
+HWCAP2_CSSC
+ Functionality implied by ID_AA64ISAR2_EL1.CSSC == 0b0001.
+
+HWCAP2_RPRFM
+ Functionality implied by ID_AA64ISAR2_EL1.RPRFM == 0b0001.
+
+HWCAP2_SVE2P1
+ Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0010.
+
+HWCAP2_SME2
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0001.
+
+HWCAP2_SME2P1
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0010.
+
+HWCAP2_SMEI16I32
+ Functionality implied by ID_AA64SMFR0_EL1.I16I32 == 0b0101
+
+HWCAP2_SMEBI32I32
+ Functionality implied by ID_AA64SMFR0_EL1.BI32I32 == 0b1
+
+HWCAP2_SMEB16B16
+ Functionality implied by ID_AA64SMFR0_EL1.B16B16 == 0b1
+
+HWCAP2_SMEF16F16
+ Functionality implied by ID_AA64SMFR0_EL1.F16F16 == 0b1
+
+HWCAP2_MOPS
+ Functionality implied by ID_AA64ISAR2_EL1.MOPS == 0b0001.
+
+4. Unused AT_HWCAP bits
+-----------------------
+
+For interoperation with userspace, the kernel guarantees that bits 62
+and 63 of AT_HWCAP will always be returned as 0.
diff --git a/Documentation/arm64/features.rst b/Documentation/arch/arm64/features.rst
similarity index 100%
rename from Documentation/arm64/features.rst
rename to Documentation/arch/arm64/features.rst
diff --git a/Documentation/arm64/hugetlbpage.rst b/Documentation/arch/arm64/hugetlbpage.rst
similarity index 100%
rename from Documentation/arm64/hugetlbpage.rst
rename to Documentation/arch/arm64/hugetlbpage.rst
diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
new file mode 100644
index 0000000..d08e9242
--- /dev/null
+++ b/Documentation/arch/arm64/index.rst
@@ -0,0 +1,38 @@
+.. _arm64_index:
+
+==================
+ARM64 Architecture
+==================
+
+.. toctree::
+ :maxdepth: 1
+
+ acpi_object_usage
+ amu
+ arm-acpi
+ asymmetric-32bit
+ booting
+ cpu-feature-registers
+ elf_hwcaps
+ hugetlbpage
+ kdump
+ legacy_instructions
+ memory
+ memory-tagging-extension
+ perf
+ pointer-authentication
+ ptdump
+ silicon-errata
+ sme
+ sve
+ tagged-address-abi
+ tagged-pointers
+
+ features
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/arm64/kasan-offsets.sh b/Documentation/arch/arm64/kasan-offsets.sh
similarity index 100%
rename from Documentation/arm64/kasan-offsets.sh
rename to Documentation/arch/arm64/kasan-offsets.sh
diff --git a/Documentation/arch/arm64/kdump.rst b/Documentation/arch/arm64/kdump.rst
new file mode 100644
index 0000000..56a89f4
--- /dev/null
+++ b/Documentation/arch/arm64/kdump.rst
@@ -0,0 +1,92 @@
+=======================================
+crashkernel memory reservation on arm64
+=======================================
+
+Author: Baoquan He <bhe@redhat.com>
+
+Kdump mechanism is used to capture a corrupted kernel vmcore so that
+it can be subsequently analyzed. In order to do this, a preliminarily
+reserved memory is needed to pre-load the kdump kernel and boot such
+kernel if corruption happens.
+
+That reserved memory for kdump is adapted to be able to minimally
+accommodate the kdump kernel and the user space programs needed for the
+vmcore collection.
+
+Kernel parameter
+================
+
+Through the kernel parameters below, memory can be reserved accordingly
+during the early stage of the first kernel booting so that a continuous
+large chunk of memomy can be found. The low memory reservation needs to
+be considered if the crashkernel is reserved from the high memory area.
+
+- crashkernel=size@offset
+- crashkernel=size
+- crashkernel=size,high crashkernel=size,low
+
+Low memory and high memory
+==========================
+
+For kdump reservations, low memory is the memory area under a specific
+limit, usually decided by the accessible address bits of the DMA-capable
+devices needed by the kdump kernel to run. Those devices not related to
+vmcore dumping can be ignored. On arm64, the low memory upper bound is
+not fixed: it is 1G on the RPi4 platform but 4G on most other systems.
+On special kernels built with CONFIG_ZONE_(DMA|DMA32) disabled, the
+whole system RAM is low memory. Outside of the low memory described
+above, the rest of system RAM is considered high memory.
+
+Implementation
+==============
+
+1) crashkernel=size@offset
+--------------------------
+
+The crashkernel memory must be reserved at the user-specified region or
+fail if already occupied.
+
+
+2) crashkernel=size
+-------------------
+
+The crashkernel memory region will be reserved in any available position
+according to the search order:
+
+Firstly, the kernel searches the low memory area for an available region
+with the specified size.
+
+If searching for low memory fails, the kernel falls back to searching
+the high memory area for an available region of the specified size. If
+the reservation in high memory succeeds, a default size reservation in
+the low memory will be done. Currently the default size is 128M,
+sufficient for the low memory needs of the kdump kernel.
+
+Note: crashkernel=size is the recommended option for crashkernel kernel
+reservations. The user would not need to know the system memory layout
+for a specific platform.
+
+3) crashkernel=size,high crashkernel=size,low
+---------------------------------------------
+
+crashkernel=size,(high|low) are an important supplement to
+crashkernel=size. They allows the user to specify how much memory needs
+to be allocated from the high memory and low memory respectively. On
+many systems the low memory is precious and crashkernel reservations
+from this area should be kept to a minimum.
+
+To reserve memory for crashkernel=size,high, searching is first
+attempted from the high memory region. If the reservation succeeds, the
+low memory reservation will be done subsequently.
+
+If reservation from the high memory failed, the kernel falls back to
+searching the low memory with the specified size in crashkernel=,high.
+If it succeeds, no further reservation for low memory is needed.
+
+Notes:
+
+- If crashkernel=,low is not specified, the default low memory
+ reservation will be done automatically.
+
+- if crashkernel=0,low is specified, it means that the low memory
+ reservation is omitted intentionally.
diff --git a/Documentation/arm64/legacy_instructions.rst b/Documentation/arch/arm64/legacy_instructions.rst
similarity index 100%
rename from Documentation/arm64/legacy_instructions.rst
rename to Documentation/arch/arm64/legacy_instructions.rst
diff --git a/Documentation/arch/arm64/memory-tagging-extension.rst b/Documentation/arch/arm64/memory-tagging-extension.rst
new file mode 100644
index 0000000..6797250
--- /dev/null
+++ b/Documentation/arch/arm64/memory-tagging-extension.rst
@@ -0,0 +1,375 @@
+===============================================
+Memory Tagging Extension (MTE) in AArch64 Linux
+===============================================
+
+Authors: Vincenzo Frascino <vincenzo.frascino@arm.com>
+ Catalin Marinas <catalin.marinas@arm.com>
+
+Date: 2020-02-25
+
+This document describes the provision of the Memory Tagging Extension
+functionality in AArch64 Linux.
+
+Introduction
+============
+
+ARMv8.5 based processors introduce the Memory Tagging Extension (MTE)
+feature. MTE is built on top of the ARMv8.0 virtual address tagging TBI
+(Top Byte Ignore) feature and allows software to access a 4-bit
+allocation tag for each 16-byte granule in the physical address space.
+Such memory range must be mapped with the Normal-Tagged memory
+attribute. A logical tag is derived from bits 59-56 of the virtual
+address used for the memory access. A CPU with MTE enabled will compare
+the logical tag against the allocation tag and potentially raise an
+exception on mismatch, subject to system registers configuration.
+
+Userspace Support
+=================
+
+When ``CONFIG_ARM64_MTE`` is selected and Memory Tagging Extension is
+supported by the hardware, the kernel advertises the feature to
+userspace via ``HWCAP2_MTE``.
+
+PROT_MTE
+--------
+
+To access the allocation tags, a user process must enable the Tagged
+memory attribute on an address range using a new ``prot`` flag for
+``mmap()`` and ``mprotect()``:
+
+``PROT_MTE`` - Pages allow access to the MTE allocation tags.
+
+The allocation tag is set to 0 when such pages are first mapped in the
+user address space and preserved on copy-on-write. ``MAP_SHARED`` is
+supported and the allocation tags can be shared between processes.
+
+**Note**: ``PROT_MTE`` is only supported on ``MAP_ANONYMOUS`` and
+RAM-based file mappings (``tmpfs``, ``memfd``). Passing it to other
+types of mapping will result in ``-EINVAL`` returned by these system
+calls.
+
+**Note**: The ``PROT_MTE`` flag (and corresponding memory type) cannot
+be cleared by ``mprotect()``.
+
+**Note**: ``madvise()`` memory ranges with ``MADV_DONTNEED`` and
+``MADV_FREE`` may have the allocation tags cleared (set to 0) at any
+point after the system call.
+
+Tag Check Faults
+----------------
+
+When ``PROT_MTE`` is enabled on an address range and a mismatch between
+the logical and allocation tags occurs on access, there are three
+configurable behaviours:
+
+- *Ignore* - This is the default mode. The CPU (and kernel) ignores the
+ tag check fault.
+
+- *Synchronous* - The kernel raises a ``SIGSEGV`` synchronously, with
+ ``.si_code = SEGV_MTESERR`` and ``.si_addr = <fault-address>``. The
+ memory access is not performed. If ``SIGSEGV`` is ignored or blocked
+ by the offending thread, the containing process is terminated with a
+ ``coredump``.
+
+- *Asynchronous* - The kernel raises a ``SIGSEGV``, in the offending
+ thread, asynchronously following one or multiple tag check faults,
+ with ``.si_code = SEGV_MTEAERR`` and ``.si_addr = 0`` (the faulting
+ address is unknown).
+
+- *Asymmetric* - Reads are handled as for synchronous mode while writes
+ are handled as for asynchronous mode.
+
+The user can select the above modes, per thread, using the
+``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where ``flags``
+contains any number of the following values in the ``PR_MTE_TCF_MASK``
+bit-field:
+
+- ``PR_MTE_TCF_NONE`` - *Ignore* tag check faults
+ (ignored if combined with other options)
+- ``PR_MTE_TCF_SYNC`` - *Synchronous* tag check fault mode
+- ``PR_MTE_TCF_ASYNC`` - *Asynchronous* tag check fault mode
+
+If no modes are specified, tag check faults are ignored. If a single
+mode is specified, the program will run in that mode. If multiple
+modes are specified, the mode is selected as described in the "Per-CPU
+preferred tag checking modes" section below.
+
+The current tag check fault configuration can be read using the
+``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call. If
+multiple modes were requested then all will be reported.
+
+Tag checking can also be disabled for a user thread by setting the
+``PSTATE.TCO`` bit with ``MSR TCO, #1``.
+
+**Note**: Signal handlers are always invoked with ``PSTATE.TCO = 0``,
+irrespective of the interrupted context. ``PSTATE.TCO`` is restored on
+``sigreturn()``.
+
+**Note**: There are no *match-all* logical tags available for user
+applications.
+
+**Note**: Kernel accesses to the user address space (e.g. ``read()``
+system call) are not checked if the user thread tag checking mode is
+``PR_MTE_TCF_NONE`` or ``PR_MTE_TCF_ASYNC``. If the tag checking mode is
+``PR_MTE_TCF_SYNC``, the kernel makes a best effort to check its user
+address accesses, however it cannot always guarantee it. Kernel accesses
+to user addresses are always performed with an effective ``PSTATE.TCO``
+value of zero, regardless of the user configuration.
+
+Excluding Tags in the ``IRG``, ``ADDG`` and ``SUBG`` instructions
+-----------------------------------------------------------------
+
+The architecture allows excluding certain tags to be randomly generated
+via the ``GCR_EL1.Exclude`` register bit-field. By default, Linux
+excludes all tags other than 0. A user thread can enable specific tags
+in the randomly generated set using the ``prctl(PR_SET_TAGGED_ADDR_CTRL,
+flags, 0, 0, 0)`` system call where ``flags`` contains the tags bitmap
+in the ``PR_MTE_TAG_MASK`` bit-field.
+
+**Note**: The hardware uses an exclude mask but the ``prctl()``
+interface provides an include mask. An include mask of ``0`` (exclusion
+mask ``0xffff``) results in the CPU always generating tag ``0``.
+
+Per-CPU preferred tag checking mode
+-----------------------------------
+
+On some CPUs the performance of MTE in stricter tag checking modes
+is similar to that of less strict tag checking modes. This makes it
+worthwhile to enable stricter checks on those CPUs when a less strict
+checking mode is requested, in order to gain the error detection
+benefits of the stricter checks without the performance downsides. To
+support this scenario, a privileged user may configure a stricter
+tag checking mode as the CPU's preferred tag checking mode.
+
+The preferred tag checking mode for each CPU is controlled by
+``/sys/devices/system/cpu/cpu<N>/mte_tcf_preferred``, to which a
+privileged user may write the value ``async``, ``sync`` or ``asymm``. The
+default preferred mode for each CPU is ``async``.
+
+To allow a program to potentially run in the CPU's preferred tag
+checking mode, the user program may set multiple tag check fault mode
+bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL,
+flags, 0, 0, 0)`` system call. If both synchronous and asynchronous
+modes are requested then asymmetric mode may also be selected by the
+kernel. If the CPU's preferred tag checking mode is in the task's set
+of provided tag checking modes, that mode will be selected. Otherwise,
+one of the modes in the task's mode will be selected by the kernel
+from the task's mode set using the preference order:
+
+ 1. Asynchronous
+ 2. Asymmetric
+ 3. Synchronous
+
+Note that there is no way for userspace to request multiple modes and
+also disable asymmetric mode.
+
+Initial process state
+---------------------
+
+On ``execve()``, the new process has the following configuration:
+
+- ``PR_TAGGED_ADDR_ENABLE`` set to 0 (disabled)
+- No tag checking modes are selected (tag check faults ignored)
+- ``PR_MTE_TAG_MASK`` set to 0 (all tags excluded)
+- ``PSTATE.TCO`` set to 0
+- ``PROT_MTE`` not set on any of the initial memory maps
+
+On ``fork()``, the new process inherits the parent's configuration and
+memory map attributes with the exception of the ``madvise()`` ranges
+with ``MADV_WIPEONFORK`` which will have the data and tags cleared (set
+to 0).
+
+The ``ptrace()`` interface
+--------------------------
+
+``PTRACE_PEEKMTETAGS`` and ``PTRACE_POKEMTETAGS`` allow a tracer to read
+the tags from or set the tags to a tracee's address space. The
+``ptrace()`` system call is invoked as ``ptrace(request, pid, addr,
+data)`` where:
+
+- ``request`` - one of ``PTRACE_PEEKMTETAGS`` or ``PTRACE_POKEMTETAGS``.
+- ``pid`` - the tracee's PID.
+- ``addr`` - address in the tracee's address space.
+- ``data`` - pointer to a ``struct iovec`` where ``iov_base`` points to
+ a buffer of ``iov_len`` length in the tracer's address space.
+
+The tags in the tracer's ``iov_base`` buffer are represented as one
+4-bit tag per byte and correspond to a 16-byte MTE tag granule in the
+tracee's address space.
+
+**Note**: If ``addr`` is not aligned to a 16-byte granule, the kernel
+will use the corresponding aligned address.
+
+``ptrace()`` return value:
+
+- 0 - tags were copied, the tracer's ``iov_len`` was updated to the
+ number of tags transferred. This may be smaller than the requested
+ ``iov_len`` if the requested address range in the tracee's or the
+ tracer's space cannot be accessed or does not have valid tags.
+- ``-EPERM`` - the specified process cannot be traced.
+- ``-EIO`` - the tracee's address range cannot be accessed (e.g. invalid
+ address) and no tags copied. ``iov_len`` not updated.
+- ``-EFAULT`` - fault on accessing the tracer's memory (``struct iovec``
+ or ``iov_base`` buffer) and no tags copied. ``iov_len`` not updated.
+- ``-EOPNOTSUPP`` - the tracee's address does not have valid tags (never
+ mapped with the ``PROT_MTE`` flag). ``iov_len`` not updated.
+
+**Note**: There are no transient errors for the requests above, so user
+programs should not retry in case of a non-zero system call return.
+
+``PTRACE_GETREGSET`` and ``PTRACE_SETREGSET`` with ``addr ==
+``NT_ARM_TAGGED_ADDR_CTRL`` allow ``ptrace()`` access to the tagged
+address ABI control and MTE configuration of a process as per the
+``prctl()`` options described in
+Documentation/arch/arm64/tagged-address-abi.rst and above. The corresponding
+``regset`` is 1 element of 8 bytes (``sizeof(long))``).
+
+Core dump support
+-----------------
+
+The allocation tags for user memory mapped with ``PROT_MTE`` are dumped
+in the core file as additional ``PT_AARCH64_MEMTAG_MTE`` segments. The
+program header for such segment is defined as:
+
+:``p_type``: ``PT_AARCH64_MEMTAG_MTE``
+:``p_flags``: 0
+:``p_offset``: segment file offset
+:``p_vaddr``: segment virtual address, same as the corresponding
+ ``PT_LOAD`` segment
+:``p_paddr``: 0
+:``p_filesz``: segment size in file, calculated as ``p_mem_sz / 32``
+ (two 4-bit tags cover 32 bytes of memory)
+:``p_memsz``: segment size in memory, same as the corresponding
+ ``PT_LOAD`` segment
+:``p_align``: 0
+
+The tags are stored in the core file at ``p_offset`` as two 4-bit tags
+in a byte. With the tag granule of 16 bytes, a 4K page requires 128
+bytes in the core file.
+
+Example of correct usage
+========================
+
+*MTE Example code*
+
+.. code-block:: c
+
+ /*
+ * To be compiled with -march=armv8.5-a+memtag
+ */
+ #include <errno.h>
+ #include <stdint.h>
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <unistd.h>
+ #include <sys/auxv.h>
+ #include <sys/mman.h>
+ #include <sys/prctl.h>
+
+ /*
+ * From arch/arm64/include/uapi/asm/hwcap.h
+ */
+ #define HWCAP2_MTE (1 << 18)
+
+ /*
+ * From arch/arm64/include/uapi/asm/mman.h
+ */
+ #define PROT_MTE 0x20
+
+ /*
+ * From include/uapi/linux/prctl.h
+ */
+ #define PR_SET_TAGGED_ADDR_CTRL 55
+ #define PR_GET_TAGGED_ADDR_CTRL 56
+ # define PR_TAGGED_ADDR_ENABLE (1UL << 0)
+ # define PR_MTE_TCF_SHIFT 1
+ # define PR_MTE_TCF_NONE (0UL << PR_MTE_TCF_SHIFT)
+ # define PR_MTE_TCF_SYNC (1UL << PR_MTE_TCF_SHIFT)
+ # define PR_MTE_TCF_ASYNC (2UL << PR_MTE_TCF_SHIFT)
+ # define PR_MTE_TCF_MASK (3UL << PR_MTE_TCF_SHIFT)
+ # define PR_MTE_TAG_SHIFT 3
+ # define PR_MTE_TAG_MASK (0xffffUL << PR_MTE_TAG_SHIFT)
+
+ /*
+ * Insert a random logical tag into the given pointer.
+ */
+ #define insert_random_tag(ptr) ({ \
+ uint64_t __val; \
+ asm("irg %0, %1" : "=r" (__val) : "r" (ptr)); \
+ __val; \
+ })
+
+ /*
+ * Set the allocation tag on the destination address.
+ */
+ #define set_tag(tagged_addr) do { \
+ asm volatile("stg %0, [%0]" : : "r" (tagged_addr) : "memory"); \
+ } while (0)
+
+ int main()
+ {
+ unsigned char *a;
+ unsigned long page_sz = sysconf(_SC_PAGESIZE);
+ unsigned long hwcap2 = getauxval(AT_HWCAP2);
+
+ /* check if MTE is present */
+ if (!(hwcap2 & HWCAP2_MTE))
+ return EXIT_FAILURE;
+
+ /*
+ * Enable the tagged address ABI, synchronous or asynchronous MTE
+ * tag check faults (based on per-CPU preference) and allow all
+ * non-zero tags in the randomly generated set.
+ */
+ if (prctl(PR_SET_TAGGED_ADDR_CTRL,
+ PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC |
+ (0xfffe << PR_MTE_TAG_SHIFT),
+ 0, 0, 0)) {
+ perror("prctl() failed");
+ return EXIT_FAILURE;
+ }
+
+ a = mmap(0, page_sz, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ if (a == MAP_FAILED) {
+ perror("mmap() failed");
+ return EXIT_FAILURE;
+ }
+
+ /*
+ * Enable MTE on the above anonymous mmap. The flag could be passed
+ * directly to mmap() and skip this step.
+ */
+ if (mprotect(a, page_sz, PROT_READ | PROT_WRITE | PROT_MTE)) {
+ perror("mprotect() failed");
+ return EXIT_FAILURE;
+ }
+
+ /* access with the default tag (0) */
+ a[0] = 1;
+ a[1] = 2;
+
+ printf("a[0] = %hhu a[1] = %hhu\n", a[0], a[1]);
+
+ /* set the logical and allocation tags */
+ a = (unsigned char *)insert_random_tag(a);
+ set_tag(a);
+
+ printf("%p\n", a);
+
+ /* non-zero tag access */
+ a[0] = 3;
+ printf("a[0] = %hhu a[1] = %hhu\n", a[0], a[1]);
+
+ /*
+ * If MTE is enabled correctly the next instruction will generate an
+ * exception.
+ */
+ printf("Expecting SIGSEGV...\n");
+ a[16] = 0xdd;
+
+ /* this should not be printed in the PR_MTE_TCF_SYNC mode */
+ printf("...haven't got one\n");
+
+ return EXIT_FAILURE;
+ }
diff --git a/Documentation/arch/arm64/memory.rst b/Documentation/arch/arm64/memory.rst
new file mode 100644
index 0000000..55a55f3
--- /dev/null
+++ b/Documentation/arch/arm64/memory.rst
@@ -0,0 +1,167 @@
+==============================
+Memory Layout on AArch64 Linux
+==============================
+
+Author: Catalin Marinas <catalin.marinas@arm.com>
+
+This document describes the virtual memory layout used by the AArch64
+Linux kernel. The architecture allows up to 4 levels of translation
+tables with a 4KB page size and up to 3 levels with a 64KB page size.
+
+AArch64 Linux uses either 3 levels or 4 levels of translation tables
+with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
+(256TB) virtual addresses, respectively, for both user and kernel. With
+64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
+virtual address, are used but the memory layout is the same.
+
+ARMv8.2 adds optional support for Large Virtual Address space. This is
+only available when running with a 64KB page size and expands the
+number of descriptors in the first level of translation.
+
+User addresses have bits 63:48 set to 0 while the kernel addresses have
+the same bits set to 1. TTBRx selection is given by bit 63 of the
+virtual address. The swapper_pg_dir contains only kernel (global)
+mappings while the user pgd contains only user (non-global) mappings.
+The swapper_pg_dir address is written to TTBR1 and never written to
+TTBR0.
+
+
+AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
+
+ Start End Size Use
+ -----------------------------------------------------------------------
+ 0000000000000000 0000ffffffffffff 256TB user
+ ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
+ [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region]
+ ffff800000000000 ffff80007fffffff 2GB modules
+ ffff800080000000 fffffbffefffffff 124TB vmalloc
+ fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
+ fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
+ fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
+ fffffbffff800000 fffffbffffffffff 8MB [guard region]
+ fffffc0000000000 fffffdffffffffff 2TB vmemmap
+ fffffe0000000000 ffffffffffffffff 2TB [guard region]
+
+
+AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
+
+ Start End Size Use
+ -----------------------------------------------------------------------
+ 0000000000000000 000fffffffffffff 4PB user
+ fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map
+ [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region]
+ ffff800000000000 ffff80007fffffff 2GB modules
+ ffff800080000000 fffffbffefffffff 124TB vmalloc
+ fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
+ fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
+ fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
+ fffffbffff800000 fffffbffffffffff 8MB [guard region]
+ fffffc0000000000 ffffffdfffffffff ~4TB vmemmap
+ ffffffe000000000 ffffffffffffffff 128GB [guard region]
+
+
+Translation table lookup with 4KB pages::
+
+ +--------+--------+--------+--------+--------+--------+--------+--------+
+ |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
+ +--------+--------+--------+--------+--------+--------+--------+--------+
+ | | | | | |
+ | | | | | v
+ | | | | | [11:0] in-page offset
+ | | | | +-> [20:12] L3 index
+ | | | +-----------> [29:21] L2 index
+ | | +---------------------> [38:30] L1 index
+ | +-------------------------------> [47:39] L0 index
+ +-------------------------------------------------> [63] TTBR0/1
+
+
+Translation table lookup with 64KB pages::
+
+ +--------+--------+--------+--------+--------+--------+--------+--------+
+ |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
+ +--------+--------+--------+--------+--------+--------+--------+--------+
+ | | | | |
+ | | | | v
+ | | | | [15:0] in-page offset
+ | | | +----------> [28:16] L3 index
+ | | +--------------------------> [41:29] L2 index
+ | +-------------------------------> [47:42] L1 index (48-bit)
+ | [51:42] L1 index (52-bit)
+ +-------------------------------------------------> [63] TTBR0/1
+
+
+When using KVM without the Virtualization Host Extensions, the
+hypervisor maps kernel pages in EL2 at a fixed (and potentially
+random) offset from the linear mapping. See the kern_hyp_va macro and
+kvm_update_va_mask function for more details. MMIO devices such as
+GICv2 gets mapped next to the HYP idmap page, as do vectors when
+ARM64_SPECTRE_V3A is enabled for particular CPUs.
+
+When using KVM with the Virtualization Host Extensions, no additional
+mappings are created, since the host kernel runs directly in EL2.
+
+52-bit VA support in the kernel
+-------------------------------
+If the ARMv8.2-LVA optional feature is present, and we are running
+with a 64KB page size; then it is possible to use 52-bits of address
+space for both userspace and kernel addresses. However, any kernel
+binary that supports 52-bit must also be able to fall back to 48-bit
+at early boot time if the hardware feature is not present.
+
+This fallback mechanism necessitates the kernel .text to be in the
+higher addresses such that they are invariant to 48/52-bit VAs. Due
+to the kasan shadow being a fraction of the entire kernel VA space,
+the end of the kasan shadow must also be in the higher half of the
+kernel VA space for both 48/52-bit. (Switching from 48-bit to 52-bit,
+the end of the kasan shadow is invariant and dependent on ~0UL,
+whilst the start address will "grow" towards the lower addresses).
+
+In order to optimise phys_to_virt and virt_to_phys, the PAGE_OFFSET
+is kept constant at 0xFFF0000000000000 (corresponding to 52-bit),
+this obviates the need for an extra variable read. The physvirt
+offset and vmemmap offsets are computed at early boot to enable
+this logic.
+
+As a single binary will need to support both 48-bit and 52-bit VA
+spaces, the VMEMMAP must be sized large enough for 52-bit VAs and
+also must be sized large enough to accommodate a fixed PAGE_OFFSET.
+
+Most code in the kernel should not need to consider the VA_BITS, for
+code that does need to know the VA size the variables are
+defined as follows:
+
+VA_BITS constant the *maximum* VA space size
+
+VA_BITS_MIN constant the *minimum* VA space size
+
+vabits_actual variable the *actual* VA space size
+
+
+Maximum and minimum sizes can be useful to ensure that buffers are
+sized large enough or that addresses are positioned close enough for
+the "worst" case.
+
+52-bit userspace VAs
+--------------------
+To maintain compatibility with software that relies on the ARMv8.0
+VA space maximum size of 48-bits, the kernel will, by default,
+return virtual addresses to userspace from a 48-bit range.
+
+Software can "opt-in" to receiving VAs from a 52-bit space by
+specifying an mmap hint parameter that is larger than 48-bit.
+
+For example:
+
+.. code-block:: c
+
+ maybe_high_address = mmap(~0UL, size, prot, flags,...);
+
+It is also possible to build a debug kernel that returns addresses
+from a 52-bit space by enabling the following kernel config options:
+
+.. code-block:: sh
+
+ CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y
+
+Note that this option is only intended for debugging applications
+and should not be used in production.
diff --git a/Documentation/arm64/perf.rst b/Documentation/arch/arm64/perf.rst
similarity index 100%
rename from Documentation/arm64/perf.rst
rename to Documentation/arch/arm64/perf.rst
diff --git a/Documentation/arm64/pointer-authentication.rst b/Documentation/arch/arm64/pointer-authentication.rst
similarity index 100%
rename from Documentation/arm64/pointer-authentication.rst
rename to Documentation/arch/arm64/pointer-authentication.rst
diff --git a/Documentation/arch/arm64/ptdump.rst b/Documentation/arch/arm64/ptdump.rst
new file mode 100644
index 0000000..5dcfc5d
--- /dev/null
+++ b/Documentation/arch/arm64/ptdump.rst
@@ -0,0 +1,96 @@
+======================
+Kernel page table dump
+======================
+
+ptdump is a debugfs interface that provides a detailed dump of the
+kernel page tables. It offers a comprehensive overview of the kernel
+virtual memory layout as well as the attributes associated with the
+various regions in a human-readable format. It is useful to dump the
+kernel page tables to verify permissions and memory types. Examining the
+page table entries and permissions helps identify potential security
+vulnerabilities such as mappings with overly permissive access rights or
+improper memory protections.
+
+Memory hotplug allows dynamic expansion or contraction of available
+memory without requiring a system reboot. To maintain the consistency
+and integrity of the memory management data structures, arm64 makes use
+of the ``mem_hotplug_lock`` semaphore in write mode. Additionally, in
+read mode, ``mem_hotplug_lock`` supports an efficient implementation of
+``get_online_mems()`` and ``put_online_mems()``. These protect the
+offlining of memory being accessed by the ptdump code.
+
+In order to dump the kernel page tables, enable the following
+configurations and mount debugfs::
+
+ CONFIG_GENERIC_PTDUMP=y
+ CONFIG_PTDUMP_CORE=y
+ CONFIG_PTDUMP_DEBUGFS=y
+
+ mount -t debugfs nodev /sys/kernel/debug
+ cat /sys/kernel/debug/kernel_page_tables
+
+On analysing the output of ``cat /sys/kernel/debug/kernel_page_tables``
+one can derive information about the virtual address range of the entry,
+followed by size of the memory region covered by this entry, the
+hierarchical structure of the page tables and finally the attributes
+associated with each page. The page attributes provide information about
+access permissions, execution capability, type of mapping such as leaf
+level PTE or block level PGD, PMD and PUD, and access status of a page
+within the kernel memory. Assessing these attributes can assist in
+understanding the memory layout, access patterns and security
+characteristics of the kernel pages.
+
+Kernel virtual memory layout example::
+
+ start address end address size attributes
+ +---------------------------------------------------------------------------------------+
+ | ---[ Linear Mapping start ]---------------------------------------------------------- |
+ | .................. |
+ | 0xfff0000000000000-0xfff0000000210000 2112K PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED |
+ | 0xfff0000000210000-0xfff0000001c00000 26560K PTE ro NX SHD AF UXN MEM/NORMAL |
+ | .................. |
+ | ---[ Linear Mapping end ]------------------------------------------------------------ |
+ +---------------------------------------------------------------------------------------+
+ | ---[ Modules start ]----------------------------------------------------------------- |
+ | .................. |
+ | 0xffff800000000000-0xffff800008000000 128M PTE |
+ | .................. |
+ | ---[ Modules end ]------------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+ | ---[ vmalloc() area ]---------------------------------------------------------------- |
+ | .................. |
+ | 0xffff800008010000-0xffff800008200000 1984K PTE ro x SHD AF UXN MEM/NORMAL |
+ | 0xffff800008200000-0xffff800008e00000 12M PTE ro x SHD AF CON UXN MEM/NORMAL |
+ | .................. |
+ | ---[ vmalloc() end ]----------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+ | ---[ Fixmap start ]------------------------------------------------------------------ |
+ | .................. |
+ | 0xfffffbfffdb80000-0xfffffbfffdb90000 64K PTE ro x SHD AF UXN MEM/NORMAL |
+ | 0xfffffbfffdb90000-0xfffffbfffdba0000 64K PTE ro NX SHD AF UXN MEM/NORMAL |
+ | .................. |
+ | ---[ Fixmap end ]-------------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+ | ---[ PCI I/O start ]----------------------------------------------------------------- |
+ | .................. |
+ | 0xfffffbfffe800000-0xfffffbffff800000 16M PTE |
+ | .................. |
+ | ---[ PCI I/O end ]------------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+ | ---[ vmemmap start ]----------------------------------------------------------------- |
+ | .................. |
+ | 0xfffffc0002000000-0xfffffc0002200000 2M PTE RW NX SHD AF UXN MEM/NORMAL |
+ | 0xfffffc0002200000-0xfffffc0020000000 478M PTE |
+ | .................. |
+ | ---[ vmemmap end ]------------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+
+``cat /sys/kernel/debug/kernel_page_tables`` output::
+
+ 0xfff0000001c00000-0xfff0000080000000 2020M PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED
+ 0xfff0000080000000-0xfff0000800000000 30G PMD
+ 0xfff0000800000000-0xfff0000800700000 7M PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED
+ 0xfff0000800700000-0xfff0000800710000 64K PTE ro NX SHD AF UXN MEM/NORMAL-TAGGED
+ 0xfff0000800710000-0xfff0000880000000 2089920K PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED
+ 0xfff0000880000000-0xfff0040000000000 4062G PMD
+ 0xfff0040000000000-0xffff800000000000 3964T PGD
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
new file mode 100644
index 0000000..bedd3a1
--- /dev/null
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -0,0 +1,230 @@
+=======================================
+Silicon Errata and Software Workarounds
+=======================================
+
+Author: Will Deacon <will.deacon@arm.com>
+
+Date : 27 November 2015
+
+It is an unfortunate fact of life that hardware is often produced with
+so-called "errata", which can cause it to deviate from the architecture
+under specific circumstances. For hardware produced by ARM, these
+errata are broadly classified into the following categories:
+
+ ========== ========================================================
+ Category A A critical error without a viable workaround.
+ Category B A significant or critical error with an acceptable
+ workaround.
+ Category C A minor error that is not expected to occur under normal
+ operation.
+ ========== ========================================================
+
+For more information, consult one of the "Software Developers Errata
+Notice" documents available on infocenter.arm.com (registration
+required).
+
+As far as Linux is concerned, Category B errata may require some special
+treatment in the operating system. For example, avoiding a particular
+sequence of code, or configuring the processor in a particular way. A
+less common situation may require similar actions in order to declassify
+a Category A erratum into a Category C erratum. These are collectively
+known as "software workarounds" and are only required in the minority of
+cases (e.g. those cases that both require a non-secure workaround *and*
+can be triggered by Linux).
+
+For software workarounds that may adversely impact systems unaffected by
+the erratum in question, a Kconfig entry is added under "Kernel
+Features" -> "ARM errata workarounds via the alternatives framework".
+These are enabled by default and patched in at runtime when an affected
+CPU is detected. For less-intrusive workarounds, a Kconfig option is not
+available and the code is structured (preferably with a comment) in such
+a way that the erratum will not be hit.
+
+This approach can make it slightly onerous to determine exactly which
+errata are worked around in an arbitrary kernel source tree, so this
+file acts as a registry of software workarounds in the Linux Kernel and
+will be updated when new workarounds are committed and backported to
+stable kernels.
+
++----------------+-----------------+-----------------+-----------------------------+
+| Implementor | Component | Erratum ID | Kconfig |
++================+=================+=================+=============================+
+| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A55 | #1530923 | ARM64_ERRATUM_1530923 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A55 | #2441007 | ARM64_ERRATUM_2441007 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #852523 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #1319537 | ARM64_ERRATUM_1319367 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #1742098 | ARM64_ERRATUM_1742098 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A72 | #853709 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A72 | #1319367 | ARM64_ERRATUM_1319367 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A72 | #1655431 | ARM64_ERRATUM_1742098 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N1 | #1349291 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | MMU-500 | #841119,826419 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | MMU-600 | #1076982,1209401| N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | MMU-700 | #2268618,2812531| N/A |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | GIC-700 | #2941627 | ARM64_ERRATUM_2941627 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 |
++----------------+-----------------+-----------------+-----------------------------+
+| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX GICv3 | #38539 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX SMMUv2 | #27704 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX2 SMMUv3| #74 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX2 SMMUv3| #126 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Marvell | ARM-MMU-500 | #582743 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
++----------------+-----------------+-----------------+-----------------------------+
+| NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip0{6,7} | #161010701 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip0{6,7} | #161010803 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo/Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1463225 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1418040 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1530923 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1024718 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 |
++----------------+-----------------+-----------------+-----------------------------+
+
++----------------+-----------------+-----------------+-----------------------------+
+| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
++----------------+-----------------+-----------------+-----------------------------+
+
++----------------+-----------------+-----------------+-----------------------------+
+| ASR | ASR8601 | #8601001 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
diff --git a/Documentation/arch/arm64/sme.rst b/Documentation/arch/arm64/sme.rst
new file mode 100644
index 0000000..ba529a1
--- /dev/null
+++ b/Documentation/arch/arm64/sme.rst
@@ -0,0 +1,468 @@
+===================================================
+Scalable Matrix Extension support for AArch64 Linux
+===================================================
+
+This document outlines briefly the interface provided to userspace by Linux in
+order to support use of the ARM Scalable Matrix Extension (SME).
+
+This is an outline of the most important features and issues only and not
+intended to be exhaustive. It should be read in conjunction with the SVE
+documentation in sve.rst which provides details on the Streaming SVE mode
+included in SME.
+
+This document does not aim to describe the SME architecture or programmer's
+model. To aid understanding, a minimal description of relevant programmer's
+model features for SME is included in Appendix A.
+
+
+1. General
+-----------
+
+* PSTATE.SM, PSTATE.ZA, the streaming mode vector length, the ZA and (when
+ present) ZTn register state and TPIDR2_EL0 are tracked per thread.
+
+* The presence of SME is reported to userspace via HWCAP2_SME in the aux vector
+ AT_HWCAP2 entry. Presence of this flag implies the presence of the SME
+ instructions and registers, and the Linux-specific system interfaces
+ described in this document. SME is reported in /proc/cpuinfo as "sme".
+
+* The presence of SME2 is reported to userspace via HWCAP2_SME2 in the
+ aux vector AT_HWCAP2 entry. Presence of this flag implies the presence of
+ the SME2 instructions and ZT0, and the Linux-specific system interfaces
+ described in this document. SME2 is reported in /proc/cpuinfo as "sme2".
+
+* Support for the execution of SME instructions in userspace can also be
+ detected by reading the CPU ID register ID_AA64PFR1_EL1 using an MRS
+ instruction, and checking that the value of the SME field is nonzero. [3]
+
+ It does not guarantee the presence of the system interfaces described in the
+ following sections: software that needs to verify that those interfaces are
+ present must check for HWCAP2_SME instead.
+
+* There are a number of optional SME features, presence of these is reported
+ through AT_HWCAP2 through:
+
+ HWCAP2_SME_I16I64
+ HWCAP2_SME_F64F64
+ HWCAP2_SME_I8I32
+ HWCAP2_SME_F16F32
+ HWCAP2_SME_B16F32
+ HWCAP2_SME_F32F32
+ HWCAP2_SME_FA64
+ HWCAP2_SME2
+
+ This list may be extended over time as the SME architecture evolves.
+
+ These extensions are also reported via the CPU ID register ID_AA64SMFR0_EL1,
+ which userspace can read using an MRS instruction. See elf_hwcaps.txt and
+ cpu-feature-registers.txt for details.
+
+* Debuggers should restrict themselves to interacting with the target via the
+ NT_ARM_SVE, NT_ARM_SSVE, NT_ARM_ZA and NT_ARM_ZT regsets. The recommended
+ way of detecting support for these regsets is to connect to a target process
+ first and then attempt a
+
+ ptrace(PTRACE_GETREGSET, pid, NT_ARM_<regset>, &iov).
+
+* Whenever ZA register values are exchanged in memory between userspace and
+ the kernel, the register value is encoded in memory as a series of horizontal
+ vectors from 0 to VL/8-1 stored in the same endianness invariant format as is
+ used for SVE vectors.
+
+* On thread creation TPIDR2_EL0 is preserved unless CLONE_SETTLS is specified,
+ in which case it is set to 0.
+
+2. Vector lengths
+------------------
+
+SME defines a second vector length similar to the SVE vector length which is
+controls the size of the streaming mode SVE vectors and the ZA matrix array.
+The ZA matrix is square with each side having as many bytes as a streaming
+mode SVE vector.
+
+
+3. Sharing of streaming and non-streaming mode SVE state
+---------------------------------------------------------
+
+It is implementation defined which if any parts of the SVE state are shared
+between streaming and non-streaming modes. When switching between modes
+via software interfaces such as ptrace if no register content is provided as
+part of switching no state will be assumed to be shared and everything will
+be zeroed.
+
+
+4. System call behaviour
+-------------------------
+
+* On syscall PSTATE.ZA is preserved, if PSTATE.ZA==1 then the contents of the
+ ZA matrix and ZTn (if present) are preserved.
+
+* On syscall PSTATE.SM will be cleared and the SVE registers will be handled
+ as per the standard SVE ABI.
+
+* None of the SVE registers, ZA or ZTn are used to pass arguments to
+ or receive results from any syscall.
+
+* On process creation (eg, clone()) the newly created process will have
+ PSTATE.SM cleared.
+
+* All other SME state of a thread, including the currently configured vector
+ length, the state of the PR_SME_VL_INHERIT flag, and the deferred vector
+ length (if any), is preserved across all syscalls, subject to the specific
+ exceptions for execve() described in section 6.
+
+
+5. Signal handling
+-------------------
+
+* Signal handlers are invoked with streaming mode and ZA disabled.
+
+* A new signal frame record TPIDR2_MAGIC is added formatted as a struct
+ tpidr2_context to allow access to TPIDR2_EL0 from signal handlers.
+
+* A new signal frame record za_context encodes the ZA register contents on
+ signal delivery. [1]
+
+* The signal frame record for ZA always contains basic metadata, in particular
+ the thread's vector length (in za_context.vl).
+
+* The ZA matrix may or may not be included in the record, depending on
+ the value of PSTATE.ZA. The registers are present if and only if:
+ za_context.head.size >= ZA_SIG_CONTEXT_SIZE(sve_vq_from_vl(za_context.vl))
+ in which case PSTATE.ZA == 1.
+
+* If matrix data is present, the remainder of the record has a vl-dependent
+ size and layout. Macros ZA_SIG_* are defined [1] to facilitate access to
+ them.
+
+* The matrix is stored as a series of horizontal vectors in the same format as
+ is used for SVE vectors.
+
+* If the ZA context is too big to fit in sigcontext.__reserved[], then extra
+ space is allocated on the stack, an extra_context record is written in
+ __reserved[] referencing this space. za_context is then written in the
+ extra space. Refer to [1] for further details about this mechanism.
+
+* If ZTn is supported and PSTATE.ZA==1 then a signal frame record for ZTn will
+ be generated.
+
+* The signal record for ZTn has magic ZT_MAGIC (0x5a544e01) and consists of a
+ standard signal frame header followed by a struct zt_context specifying
+ the number of ZTn registers supported by the system, then zt_context.nregs
+ blocks of 64 bytes of data per register.
+
+
+5. Signal return
+-----------------
+
+When returning from a signal handler:
+
+* If there is no za_context record in the signal frame, or if the record is
+ present but contains no register data as described in the previous section,
+ then ZA is disabled.
+
+* If za_context is present in the signal frame and contains matrix data then
+ PSTATE.ZA is set to 1 and ZA is populated with the specified data.
+
+* The vector length cannot be changed via signal return. If za_context.vl in
+ the signal frame does not match the current vector length, the signal return
+ attempt is treated as illegal, resulting in a forced SIGSEGV.
+
+* If ZTn is not supported or PSTATE.ZA==0 then it is illegal to have a
+ signal frame record for ZTn, resulting in a forced SIGSEGV.
+
+
+6. prctl extensions
+--------------------
+
+Some new prctl() calls are added to allow programs to manage the SME vector
+length:
+
+prctl(PR_SME_SET_VL, unsigned long arg)
+
+ Sets the vector length of the calling thread and related flags, where
+ arg == vl | flags. Other threads of the calling process are unaffected.
+
+ vl is the desired vector length, where sve_vl_valid(vl) must be true.
+
+ flags:
+
+ PR_SME_VL_INHERIT
+
+ Inherit the current vector length across execve(). Otherwise, the
+ vector length is reset to the system default at execve(). (See
+ Section 9.)
+
+ PR_SME_SET_VL_ONEXEC
+
+ Defer the requested vector length change until the next execve()
+ performed by this thread.
+
+ The effect is equivalent to implicit execution of the following
+ call immediately after the next execve() (if any) by the thread:
+
+ prctl(PR_SME_SET_VL, arg & ~PR_SME_SET_VL_ONEXEC)
+
+ This allows launching of a new program with a different vector
+ length, while avoiding runtime side effects in the caller.
+
+ Without PR_SME_SET_VL_ONEXEC, the requested change takes effect
+ immediately.
+
+
+ Return value: a nonnegative on success, or a negative value on error:
+ EINVAL: SME not supported, invalid vector length requested, or
+ invalid flags.
+
+
+ On success:
+
+ * Either the calling thread's vector length or the deferred vector length
+ to be applied at the next execve() by the thread (dependent on whether
+ PR_SME_SET_VL_ONEXEC is present in arg), is set to the largest value
+ supported by the system that is less than or equal to vl. If vl ==
+ SVE_VL_MAX, the value set will be the largest value supported by the
+ system.
+
+ * Any previously outstanding deferred vector length change in the calling
+ thread is cancelled.
+
+ * The returned value describes the resulting configuration, encoded as for
+ PR_SME_GET_VL. The vector length reported in this value is the new
+ current vector length for this thread if PR_SME_SET_VL_ONEXEC was not
+ present in arg; otherwise, the reported vector length is the deferred
+ vector length that will be applied at the next execve() by the calling
+ thread.
+
+ * Changing the vector length causes all of ZA, ZTn, P0..P15, FFR and all
+ bits of Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
+ unspecified, including both streaming and non-streaming SVE state.
+ Calling PR_SME_SET_VL with vl equal to the thread's current vector
+ length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag,
+ does not constitute a change to the vector length for this purpose.
+
+ * Changing the vector length causes PSTATE.ZA and PSTATE.SM to be cleared.
+ Calling PR_SME_SET_VL with vl equal to the thread's current vector
+ length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag,
+ does not constitute a change to the vector length for this purpose.
+
+
+prctl(PR_SME_GET_VL)
+
+ Gets the vector length of the calling thread.
+
+ The following flag may be OR-ed into the result:
+
+ PR_SME_VL_INHERIT
+
+ Vector length will be inherited across execve().
+
+ There is no way to determine whether there is an outstanding deferred
+ vector length change (which would only normally be the case between a
+ fork() or vfork() and the corresponding execve() in typical use).
+
+ To extract the vector length from the result, bitwise and it with
+ PR_SME_VL_LEN_MASK.
+
+ Return value: a nonnegative value on success, or a negative value on error:
+ EINVAL: SME not supported.
+
+
+7. ptrace extensions
+---------------------
+
+* A new regset NT_ARM_SSVE is defined for access to streaming mode SVE
+ state via PTRACE_GETREGSET and PTRACE_SETREGSET, this is documented in
+ sve.rst.
+
+* A new regset NT_ARM_ZA is defined for ZA state for access to ZA state via
+ PTRACE_GETREGSET and PTRACE_SETREGSET.
+
+ Refer to [2] for definitions.
+
+The regset data starts with struct user_za_header, containing:
+
+ size
+
+ Size of the complete regset, in bytes.
+ This depends on vl and possibly on other things in the future.
+
+ If a call to PTRACE_GETREGSET requests less data than the value of
+ size, the caller can allocate a larger buffer and retry in order to
+ read the complete regset.
+
+ max_size
+
+ Maximum size in bytes that the regset can grow to for the target
+ thread. The regset won't grow bigger than this even if the target
+ thread changes its vector length etc.
+
+ vl
+
+ Target thread's current streaming vector length, in bytes.
+
+ max_vl
+
+ Maximum possible streaming vector length for the target thread.
+
+ flags
+
+ Zero or more of the following flags, which have the same
+ meaning and behaviour as the corresponding PR_SET_VL_* flags:
+
+ SME_PT_VL_INHERIT
+
+ SME_PT_VL_ONEXEC (SETREGSET only).
+
+* The effects of changing the vector length and/or flags are equivalent to
+ those documented for PR_SME_SET_VL.
+
+ The caller must make a further GETREGSET call if it needs to know what VL is
+ actually set by SETREGSET, unless is it known in advance that the requested
+ VL is supported.
+
+* The size and layout of the payload depends on the header fields. The
+ SME_PT_ZA_*() macros are provided to facilitate access to the data.
+
+* In either case, for SETREGSET it is permissible to omit the payload, in which
+ case the vector length and flags are changed and PSTATE.ZA is set to 0
+ (along with any consequences of those changes). If a payload is provided
+ then PSTATE.ZA will be set to 1.
+
+* For SETREGSET, if the requested VL is not supported, the effect will be the
+ same as if the payload were omitted, except that an EIO error is reported.
+ No attempt is made to translate the payload data to the correct layout
+ for the vector length actually set. It is up to the caller to translate the
+ payload layout for the actual VL and retry.
+
+* The effect of writing a partial, incomplete payload is unspecified.
+
+* A new regset NT_ARM_ZT is defined for access to ZTn state via
+ PTRACE_GETREGSET and PTRACE_SETREGSET.
+
+* The NT_ARM_ZT regset consists of a single 512 bit register.
+
+* When PSTATE.ZA==0 reads of NT_ARM_ZT will report all bits of ZTn as 0.
+
+* Writes to NT_ARM_ZT will set PSTATE.ZA to 1.
+
+
+8. ELF coredump extensions
+---------------------------
+
+* NT_ARM_SSVE notes will be added to each coredump for
+ each thread of the dumped process. The contents will be equivalent to the
+ data that would have been read if a PTRACE_GETREGSET of the corresponding
+ type were executed for each thread when the coredump was generated.
+
+* A NT_ARM_ZA note will be added to each coredump for each thread of the
+ dumped process. The contents will be equivalent to the data that would have
+ been read if a PTRACE_GETREGSET of NT_ARM_ZA were executed for each thread
+ when the coredump was generated.
+
+* A NT_ARM_ZT note will be added to each coredump for each thread of the
+ dumped process. The contents will be equivalent to the data that would have
+ been read if a PTRACE_GETREGSET of NT_ARM_ZT were executed for each thread
+ when the coredump was generated.
+
+* The NT_ARM_TLS note will be extended to two registers, the second register
+ will contain TPIDR2_EL0 on systems that support SME and will be read as
+ zero with writes ignored otherwise.
+
+9. System runtime configuration
+--------------------------------
+
+* To mitigate the ABI impact of expansion of the signal frame, a policy
+ mechanism is provided for administrators, distro maintainers and developers
+ to set the default vector length for userspace processes:
+
+/proc/sys/abi/sme_default_vector_length
+
+ Writing the text representation of an integer to this file sets the system
+ default vector length to the specified value, unless the value is greater
+ than the maximum vector length supported by the system in which case the
+ default vector length is set to that maximum.
+
+ The result can be determined by reopening the file and reading its
+ contents.
+
+ At boot, the default vector length is initially set to 32 or the maximum
+ supported vector length, whichever is smaller and supported. This
+ determines the initial vector length of the init process (PID 1).
+
+ Reading this file returns the current system default vector length.
+
+* At every execve() call, the new vector length of the new process is set to
+ the system default vector length, unless
+
+ * PR_SME_VL_INHERIT (or equivalently SME_PT_VL_INHERIT) is set for the
+ calling thread, or
+
+ * a deferred vector length change is pending, established via the
+ PR_SME_SET_VL_ONEXEC flag (or SME_PT_VL_ONEXEC).
+
+* Modifying the system default vector length does not affect the vector length
+ of any existing process or thread that does not make an execve() call.
+
+
+Appendix A. SME programmer's model (informative)
+=================================================
+
+This section provides a minimal description of the additions made by SME to the
+ARMv8-A programmer's model that are relevant to this document.
+
+Note: This section is for information only and not intended to be complete or
+to replace any architectural specification.
+
+A.1. Registers
+---------------
+
+In A64 state, SME adds the following:
+
+* A new mode, streaming mode, in which a subset of the normal FPSIMD and SVE
+ features are available. When supported EL0 software may enter and leave
+ streaming mode at any time.
+
+ For best system performance it is strongly encouraged for software to enable
+ streaming mode only when it is actively being used.
+
+* A new vector length controlling the size of ZA and the Z registers when in
+ streaming mode, separately to the vector length used for SVE when not in
+ streaming mode. There is no requirement that either the currently selected
+ vector length or the set of vector lengths supported for the two modes in
+ a given system have any relationship. The streaming mode vector length
+ is referred to as SVL.
+
+* A new ZA matrix register. This is a square matrix of SVLxSVL bits. Most
+ operations on ZA require that streaming mode be enabled but ZA can be
+ enabled without streaming mode in order to load, save and retain data.
+
+ For best system performance it is strongly encouraged for software to enable
+ ZA only when it is actively being used.
+
+* A new ZT0 register is introduced when SME2 is present. This is a 512 bit
+ register which is accessible when PSTATE.ZA is set, as ZA itself is.
+
+* Two new 1 bit fields in PSTATE which may be controlled via the SMSTART and
+ SMSTOP instructions or by access to the SVCR system register:
+
+ * PSTATE.ZA, if this is 1 then the ZA matrix is accessible and has valid
+ data while if it is 0 then ZA can not be accessed. When PSTATE.ZA is
+ changed from 0 to 1 all bits in ZA are cleared.
+
+ * PSTATE.SM, if this is 1 then the PE is in streaming mode. When the value
+ of PSTATE.SM is changed then it is implementation defined if the subset
+ of the floating point register bits valid in both modes may be retained.
+ Any other bits will be cleared.
+
+
+References
+==========
+
+[1] arch/arm64/include/uapi/asm/sigcontext.h
+ AArch64 Linux signal ABI definitions
+
+[2] arch/arm64/include/uapi/asm/ptrace.h
+ AArch64 Linux ptrace ABI definitions
+
+[3] Documentation/arch/arm64/cpu-feature-registers.rst
diff --git a/Documentation/arch/arm64/sve.rst b/Documentation/arch/arm64/sve.rst
new file mode 100644
index 0000000..0d9a426
--- /dev/null
+++ b/Documentation/arch/arm64/sve.rst
@@ -0,0 +1,616 @@
+===================================================
+Scalable Vector Extension support for AArch64 Linux
+===================================================
+
+Author: Dave Martin <Dave.Martin@arm.com>
+
+Date: 4 August 2017
+
+This document outlines briefly the interface provided to userspace by Linux in
+order to support use of the ARM Scalable Vector Extension (SVE), including
+interactions with Streaming SVE mode added by the Scalable Matrix Extension
+(SME).
+
+This is an outline of the most important features and issues only and not
+intended to be exhaustive.
+
+This document does not aim to describe the SVE architecture or programmer's
+model. To aid understanding, a minimal description of relevant programmer's
+model features for SVE is included in Appendix A.
+
+
+1. General
+-----------
+
+* SVE registers Z0..Z31, P0..P15 and FFR and the current vector length VL, are
+ tracked per-thread.
+
+* In streaming mode FFR is not accessible unless HWCAP2_SME_FA64 is present
+ in the system, when it is not supported and these interfaces are used to
+ access streaming mode FFR is read and written as zero.
+
+* The presence of SVE is reported to userspace via HWCAP_SVE in the aux vector
+ AT_HWCAP entry. Presence of this flag implies the presence of the SVE
+ instructions and registers, and the Linux-specific system interfaces
+ described in this document. SVE is reported in /proc/cpuinfo as "sve".
+
+* Support for the execution of SVE instructions in userspace can also be
+ detected by reading the CPU ID register ID_AA64PFR0_EL1 using an MRS
+ instruction, and checking that the value of the SVE field is nonzero. [3]
+
+ It does not guarantee the presence of the system interfaces described in the
+ following sections: software that needs to verify that those interfaces are
+ present must check for HWCAP_SVE instead.
+
+* On hardware that supports the SVE2 extensions, HWCAP2_SVE2 will also
+ be reported in the AT_HWCAP2 aux vector entry. In addition to this,
+ optional extensions to SVE2 may be reported by the presence of:
+
+ HWCAP2_SVE2
+ HWCAP2_SVEAES
+ HWCAP2_SVEPMULL
+ HWCAP2_SVEBITPERM
+ HWCAP2_SVESHA3
+ HWCAP2_SVESM4
+ HWCAP2_SVE2P1
+
+ This list may be extended over time as the SVE architecture evolves.
+
+ These extensions are also reported via the CPU ID register ID_AA64ZFR0_EL1,
+ which userspace can read using an MRS instruction. See elf_hwcaps.txt and
+ cpu-feature-registers.txt for details.
+
+* On hardware that supports the SME extensions, HWCAP2_SME will also be
+ reported in the AT_HWCAP2 aux vector entry. Among other things SME adds
+ streaming mode which provides a subset of the SVE feature set using a
+ separate SME vector length and the same Z/V registers. See sme.rst
+ for more details.
+
+* Debuggers should restrict themselves to interacting with the target via the
+ NT_ARM_SVE regset. The recommended way of detecting support for this regset
+ is to connect to a target process first and then attempt a
+ ptrace(PTRACE_GETREGSET, pid, NT_ARM_SVE, &iov). Note that when SME is
+ present and streaming SVE mode is in use the FPSIMD subset of registers
+ will be read via NT_ARM_SVE and NT_ARM_SVE writes will exit streaming mode
+ in the target.
+
+* Whenever SVE scalable register values (Zn, Pn, FFR) are exchanged in memory
+ between userspace and the kernel, the register value is encoded in memory in
+ an endianness-invariant layout, with bits [(8 * i + 7) : (8 * i)] encoded at
+ byte offset i from the start of the memory representation. This affects for
+ example the signal frame (struct sve_context) and ptrace interface
+ (struct user_sve_header) and associated data.
+
+ Beware that on big-endian systems this results in a different byte order than
+ for the FPSIMD V-registers, which are stored as single host-endian 128-bit
+ values, with bits [(127 - 8 * i) : (120 - 8 * i)] of the register encoded at
+ byte offset i. (struct fpsimd_context, struct user_fpsimd_state).
+
+
+2. Vector length terminology
+-----------------------------
+
+The size of an SVE vector (Z) register is referred to as the "vector length".
+
+To avoid confusion about the units used to express vector length, the kernel
+adopts the following conventions:
+
+* Vector length (VL) = size of a Z-register in bytes
+
+* Vector quadwords (VQ) = size of a Z-register in units of 128 bits
+
+(So, VL = 16 * VQ.)
+
+The VQ convention is used where the underlying granularity is important, such
+as in data structure definitions. In most other situations, the VL convention
+is used. This is consistent with the meaning of the "VL" pseudo-register in
+the SVE instruction set architecture.
+
+
+3. System call behaviour
+-------------------------
+
+* On syscall, V0..V31 are preserved (as without SVE). Thus, bits [127:0] of
+ Z0..Z31 are preserved. All other bits of Z0..Z31, and all of P0..P15 and FFR
+ become zero on return from a syscall.
+
+* The SVE registers are not used to pass arguments to or receive results from
+ any syscall.
+
+* In practice the affected registers/bits will be preserved or will be replaced
+ with zeros on return from a syscall, but userspace should not make
+ assumptions about this. The kernel behaviour may vary on a case-by-case
+ basis.
+
+* All other SVE state of a thread, including the currently configured vector
+ length, the state of the PR_SVE_VL_INHERIT flag, and the deferred vector
+ length (if any), is preserved across all syscalls, subject to the specific
+ exceptions for execve() described in section 6.
+
+ In particular, on return from a fork() or clone(), the parent and new child
+ process or thread share identical SVE configuration, matching that of the
+ parent before the call.
+
+
+4. Signal handling
+-------------------
+
+* A new signal frame record sve_context encodes the SVE registers on signal
+ delivery. [1]
+
+* This record is supplementary to fpsimd_context. The FPSR and FPCR registers
+ are only present in fpsimd_context. For convenience, the content of V0..V31
+ is duplicated between sve_context and fpsimd_context.
+
+* The record contains a flag field which includes a flag SVE_SIG_FLAG_SM which
+ if set indicates that the thread is in streaming mode and the vector length
+ and register data (if present) describe the streaming SVE data and vector
+ length.
+
+* The signal frame record for SVE always contains basic metadata, in particular
+ the thread's vector length (in sve_context.vl).
+
+* The SVE registers may or may not be included in the record, depending on
+ whether the registers are live for the thread. The registers are present if
+ and only if:
+ sve_context.head.size >= SVE_SIG_CONTEXT_SIZE(sve_vq_from_vl(sve_context.vl)).
+
+* If the registers are present, the remainder of the record has a vl-dependent
+ size and layout. Macros SVE_SIG_* are defined [1] to facilitate access to
+ the members.
+
+* Each scalable register (Zn, Pn, FFR) is stored in an endianness-invariant
+ layout, with bits [(8 * i + 7) : (8 * i)] stored at byte offset i from the
+ start of the register's representation in memory.
+
+* If the SVE context is too big to fit in sigcontext.__reserved[], then extra
+ space is allocated on the stack, an extra_context record is written in
+ __reserved[] referencing this space. sve_context is then written in the
+ extra space. Refer to [1] for further details about this mechanism.
+
+
+5. Signal return
+-----------------
+
+When returning from a signal handler:
+
+* If there is no sve_context record in the signal frame, or if the record is
+ present but contains no register data as described in the previous section,
+ then the SVE registers/bits become non-live and take unspecified values.
+
+* If sve_context is present in the signal frame and contains full register
+ data, the SVE registers become live and are populated with the specified
+ data. However, for backward compatibility reasons, bits [127:0] of Z0..Z31
+ are always restored from the corresponding members of fpsimd_context.vregs[]
+ and not from sve_context. The remaining bits are restored from sve_context.
+
+* Inclusion of fpsimd_context in the signal frame remains mandatory,
+ irrespective of whether sve_context is present or not.
+
+* The vector length cannot be changed via signal return. If sve_context.vl in
+ the signal frame does not match the current vector length, the signal return
+ attempt is treated as illegal, resulting in a forced SIGSEGV.
+
+* It is permitted to enter or leave streaming mode by setting or clearing
+ the SVE_SIG_FLAG_SM flag but applications should take care to ensure that
+ when doing so sve_context.vl and any register data are appropriate for the
+ vector length in the new mode.
+
+
+6. prctl extensions
+--------------------
+
+Some new prctl() calls are added to allow programs to manage the SVE vector
+length:
+
+prctl(PR_SVE_SET_VL, unsigned long arg)
+
+ Sets the vector length of the calling thread and related flags, where
+ arg == vl | flags. Other threads of the calling process are unaffected.
+
+ vl is the desired vector length, where sve_vl_valid(vl) must be true.
+
+ flags:
+
+ PR_SVE_VL_INHERIT
+
+ Inherit the current vector length across execve(). Otherwise, the
+ vector length is reset to the system default at execve(). (See
+ Section 9.)
+
+ PR_SVE_SET_VL_ONEXEC
+
+ Defer the requested vector length change until the next execve()
+ performed by this thread.
+
+ The effect is equivalent to implicit execution of the following
+ call immediately after the next execve() (if any) by the thread:
+
+ prctl(PR_SVE_SET_VL, arg & ~PR_SVE_SET_VL_ONEXEC)
+
+ This allows launching of a new program with a different vector
+ length, while avoiding runtime side effects in the caller.
+
+
+ Without PR_SVE_SET_VL_ONEXEC, the requested change takes effect
+ immediately.
+
+
+ Return value: a nonnegative on success, or a negative value on error:
+ EINVAL: SVE not supported, invalid vector length requested, or
+ invalid flags.
+
+
+ On success:
+
+ * Either the calling thread's vector length or the deferred vector length
+ to be applied at the next execve() by the thread (dependent on whether
+ PR_SVE_SET_VL_ONEXEC is present in arg), is set to the largest value
+ supported by the system that is less than or equal to vl. If vl ==
+ SVE_VL_MAX, the value set will be the largest value supported by the
+ system.
+
+ * Any previously outstanding deferred vector length change in the calling
+ thread is cancelled.
+
+ * The returned value describes the resulting configuration, encoded as for
+ PR_SVE_GET_VL. The vector length reported in this value is the new
+ current vector length for this thread if PR_SVE_SET_VL_ONEXEC was not
+ present in arg; otherwise, the reported vector length is the deferred
+ vector length that will be applied at the next execve() by the calling
+ thread.
+
+ * Changing the vector length causes all of P0..P15, FFR and all bits of
+ Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
+ unspecified. Calling PR_SVE_SET_VL with vl equal to the thread's current
+ vector length, or calling PR_SVE_SET_VL with the PR_SVE_SET_VL_ONEXEC
+ flag, does not constitute a change to the vector length for this purpose.
+
+
+prctl(PR_SVE_GET_VL)
+
+ Gets the vector length of the calling thread.
+
+ The following flag may be OR-ed into the result:
+
+ PR_SVE_VL_INHERIT
+
+ Vector length will be inherited across execve().
+
+ There is no way to determine whether there is an outstanding deferred
+ vector length change (which would only normally be the case between a
+ fork() or vfork() and the corresponding execve() in typical use).
+
+ To extract the vector length from the result, bitwise and it with
+ PR_SVE_VL_LEN_MASK.
+
+ Return value: a nonnegative value on success, or a negative value on error:
+ EINVAL: SVE not supported.
+
+
+7. ptrace extensions
+---------------------
+
+* New regsets NT_ARM_SVE and NT_ARM_SSVE are defined for use with
+ PTRACE_GETREGSET and PTRACE_SETREGSET. NT_ARM_SSVE describes the
+ streaming mode SVE registers and NT_ARM_SVE describes the
+ non-streaming mode SVE registers.
+
+ In this description a register set is referred to as being "live" when
+ the target is in the appropriate streaming or non-streaming mode and is
+ using data beyond the subset shared with the FPSIMD Vn registers.
+
+ Refer to [2] for definitions.
+
+The regset data starts with struct user_sve_header, containing:
+
+ size
+
+ Size of the complete regset, in bytes.
+ This depends on vl and possibly on other things in the future.
+
+ If a call to PTRACE_GETREGSET requests less data than the value of
+ size, the caller can allocate a larger buffer and retry in order to
+ read the complete regset.
+
+ max_size
+
+ Maximum size in bytes that the regset can grow to for the target
+ thread. The regset won't grow bigger than this even if the target
+ thread changes its vector length etc.
+
+ vl
+
+ Target thread's current vector length, in bytes.
+
+ max_vl
+
+ Maximum possible vector length for the target thread.
+
+ flags
+
+ at most one of
+
+ SVE_PT_REGS_FPSIMD
+
+ SVE registers are not live (GETREGSET) or are to be made
+ non-live (SETREGSET).
+
+ The payload is of type struct user_fpsimd_state, with the same
+ meaning as for NT_PRFPREG, starting at offset
+ SVE_PT_FPSIMD_OFFSET from the start of user_sve_header.
+
+ Extra data might be appended in the future: the size of the
+ payload should be obtained using SVE_PT_FPSIMD_SIZE(vq, flags).
+
+ vq should be obtained using sve_vq_from_vl(vl).
+
+ or
+
+ SVE_PT_REGS_SVE
+
+ SVE registers are live (GETREGSET) or are to be made live
+ (SETREGSET).
+
+ The payload contains the SVE register data, starting at offset
+ SVE_PT_SVE_OFFSET from the start of user_sve_header, and with
+ size SVE_PT_SVE_SIZE(vq, flags);
+
+ ... OR-ed with zero or more of the following flags, which have the same
+ meaning and behaviour as the corresponding PR_SET_VL_* flags:
+
+ SVE_PT_VL_INHERIT
+
+ SVE_PT_VL_ONEXEC (SETREGSET only).
+
+ If neither FPSIMD nor SVE flags are provided then no register
+ payload is available, this is only possible when SME is implemented.
+
+
+* The effects of changing the vector length and/or flags are equivalent to
+ those documented for PR_SVE_SET_VL.
+
+ The caller must make a further GETREGSET call if it needs to know what VL is
+ actually set by SETREGSET, unless is it known in advance that the requested
+ VL is supported.
+
+* In the SVE_PT_REGS_SVE case, the size and layout of the payload depends on
+ the header fields. The SVE_PT_SVE_*() macros are provided to facilitate
+ access to the members.
+
+* In either case, for SETREGSET it is permissible to omit the payload, in which
+ case only the vector length and flags are changed (along with any
+ consequences of those changes).
+
+* In systems supporting SME when in streaming mode a GETREGSET for
+ NT_REG_SVE will return only the user_sve_header with no register data,
+ similarly a GETREGSET for NT_REG_SSVE will not return any register data
+ when not in streaming mode.
+
+* A GETREGSET for NT_ARM_SSVE will never return SVE_PT_REGS_FPSIMD.
+
+* For SETREGSET, if an SVE_PT_REGS_SVE payload is present and the
+ requested VL is not supported, the effect will be the same as if the
+ payload were omitted, except that an EIO error is reported. No
+ attempt is made to translate the payload data to the correct layout
+ for the vector length actually set. The thread's FPSIMD state is
+ preserved, but the remaining bits of the SVE registers become
+ unspecified. It is up to the caller to translate the payload layout
+ for the actual VL and retry.
+
+* Where SME is implemented it is not possible to GETREGSET the register
+ state for normal SVE when in streaming mode, nor the streaming mode
+ register state when in normal mode, regardless of the implementation defined
+ behaviour of the hardware for sharing data between the two modes.
+
+* Any SETREGSET of NT_ARM_SVE will exit streaming mode if the target was in
+ streaming mode and any SETREGSET of NT_ARM_SSVE will enter streaming mode
+ if the target was not in streaming mode.
+
+* The effect of writing a partial, incomplete payload is unspecified.
+
+
+8. ELF coredump extensions
+---------------------------
+
+* NT_ARM_SVE and NT_ARM_SSVE notes will be added to each coredump for
+ each thread of the dumped process. The contents will be equivalent to the
+ data that would have been read if a PTRACE_GETREGSET of the corresponding
+ type were executed for each thread when the coredump was generated.
+
+9. System runtime configuration
+--------------------------------
+
+* To mitigate the ABI impact of expansion of the signal frame, a policy
+ mechanism is provided for administrators, distro maintainers and developers
+ to set the default vector length for userspace processes:
+
+/proc/sys/abi/sve_default_vector_length
+
+ Writing the text representation of an integer to this file sets the system
+ default vector length to the specified value, unless the value is greater
+ than the maximum vector length supported by the system in which case the
+ default vector length is set to that maximum.
+
+ The result can be determined by reopening the file and reading its
+ contents.
+
+ At boot, the default vector length is initially set to 64 or the maximum
+ supported vector length, whichever is smaller. This determines the initial
+ vector length of the init process (PID 1).
+
+ Reading this file returns the current system default vector length.
+
+* At every execve() call, the new vector length of the new process is set to
+ the system default vector length, unless
+
+ * PR_SVE_VL_INHERIT (or equivalently SVE_PT_VL_INHERIT) is set for the
+ calling thread, or
+
+ * a deferred vector length change is pending, established via the
+ PR_SVE_SET_VL_ONEXEC flag (or SVE_PT_VL_ONEXEC).
+
+* Modifying the system default vector length does not affect the vector length
+ of any existing process or thread that does not make an execve() call.
+
+10. Perf extensions
+--------------------------------
+
+* The arm64 specific DWARF standard [5] added the VG (Vector Granule) register
+ at index 46. This register is used for DWARF unwinding when variable length
+ SVE registers are pushed onto the stack.
+
+* Its value is equivalent to the current SVE vector length (VL) in bits divided
+ by 64.
+
+* The value is included in Perf samples in the regs[46] field if
+ PERF_SAMPLE_REGS_USER is set and the sample_regs_user mask has bit 46 set.
+
+* The value is the current value at the time the sample was taken, and it can
+ change over time.
+
+* If the system doesn't support SVE when perf_event_open is called with these
+ settings, the event will fail to open.
+
+Appendix A. SVE programmer's model (informative)
+=================================================
+
+This section provides a minimal description of the additions made by SVE to the
+ARMv8-A programmer's model that are relevant to this document.
+
+Note: This section is for information only and not intended to be complete or
+to replace any architectural specification.
+
+A.1. Registers
+---------------
+
+In A64 state, SVE adds the following:
+
+* 32 8VL-bit vector registers Z0..Z31
+ For each Zn, Zn bits [127:0] alias the ARMv8-A vector register Vn.
+
+ A register write using a Vn register name zeros all bits of the corresponding
+ Zn except for bits [127:0].
+
+* 16 VL-bit predicate registers P0..P15
+
+* 1 VL-bit special-purpose predicate register FFR (the "first-fault register")
+
+* a VL "pseudo-register" that determines the size of each vector register
+
+ The SVE instruction set architecture provides no way to write VL directly.
+ Instead, it can be modified only by EL1 and above, by writing appropriate
+ system registers.
+
+* The value of VL can be configured at runtime by EL1 and above:
+ 16 <= VL <= VLmax, where VL must be a multiple of 16.
+
+* The maximum vector length is determined by the hardware:
+ 16 <= VLmax <= 256.
+
+ (The SVE architecture specifies 256, but permits future architecture
+ revisions to raise this limit.)
+
+* FPSR and FPCR are retained from ARMv8-A, and interact with SVE floating-point
+ operations in a similar way to the way in which they interact with ARMv8
+ floating-point operations::
+
+ 8VL-1 128 0 bit index
+ +---- //// -----------------+
+ Z0 | : V0 |
+ : :
+ Z7 | : V7 |
+ Z8 | : * V8 |
+ : : :
+ Z15 | : *V15 |
+ Z16 | : V16 |
+ : :
+ Z31 | : V31 |
+ +---- //// -----------------+
+ 31 0
+ VL-1 0 +-------+
+ +---- //// --+ FPSR | |
+ P0 | | +-------+
+ : | | *FPCR | |
+ P15 | | +-------+
+ +---- //// --+
+ FFR | | +-----+
+ +---- //// --+ VL | |
+ +-----+
+
+(*) callee-save:
+ This only applies to bits [63:0] of Z-/V-registers.
+ FPCR contains callee-save and caller-save bits. See [4] for details.
+
+
+A.2. Procedure call standard
+-----------------------------
+
+The ARMv8-A base procedure call standard is extended as follows with respect to
+the additional SVE register state:
+
+* All SVE register bits that are not shared with FP/SIMD are caller-save.
+
+* Z8 bits [63:0] .. Z15 bits [63:0] are callee-save.
+
+ This follows from the way these bits are mapped to V8..V15, which are caller-
+ save in the base procedure call standard.
+
+
+Appendix B. ARMv8-A FP/SIMD programmer's model
+===============================================
+
+Note: This section is for information only and not intended to be complete or
+to replace any architectural specification.
+
+Refer to [4] for more information.
+
+ARMv8-A defines the following floating-point / SIMD register state:
+
+* 32 128-bit vector registers V0..V31
+* 2 32-bit status/control registers FPSR, FPCR
+
+::
+
+ 127 0 bit index
+ +---------------+
+ V0 | |
+ : : :
+ V7 | |
+ * V8 | |
+ : : : :
+ *V15 | |
+ V16 | |
+ : : :
+ V31 | |
+ +---------------+
+
+ 31 0
+ +-------+
+ FPSR | |
+ +-------+
+ *FPCR | |
+ +-------+
+
+(*) callee-save:
+ This only applies to bits [63:0] of V-registers.
+ FPCR contains a mixture of callee-save and caller-save bits.
+
+
+References
+==========
+
+[1] arch/arm64/include/uapi/asm/sigcontext.h
+ AArch64 Linux signal ABI definitions
+
+[2] arch/arm64/include/uapi/asm/ptrace.h
+ AArch64 Linux ptrace ABI definitions
+
+[3] Documentation/arch/arm64/cpu-feature-registers.rst
+
+[4] ARM IHI0055C
+ http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf
+ http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html
+ Procedure Call Standard for the ARM 64-bit Architecture (AArch64)
+
+[5] https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst
diff --git a/Documentation/arch/arm64/tagged-address-abi.rst b/Documentation/arch/arm64/tagged-address-abi.rst
new file mode 100644
index 0000000..fe24a3f
--- /dev/null
+++ b/Documentation/arch/arm64/tagged-address-abi.rst
@@ -0,0 +1,179 @@
+==========================
+AArch64 TAGGED ADDRESS ABI
+==========================
+
+Authors: Vincenzo Frascino <vincenzo.frascino@arm.com>
+ Catalin Marinas <catalin.marinas@arm.com>
+
+Date: 21 August 2019
+
+This document describes the usage and semantics of the Tagged Address
+ABI on AArch64 Linux.
+
+1. Introduction
+---------------
+
+On AArch64 the ``TCR_EL1.TBI0`` bit is set by default, allowing
+userspace (EL0) to perform memory accesses through 64-bit pointers with
+a non-zero top byte. This document describes the relaxation of the
+syscall ABI that allows userspace to pass certain tagged pointers to
+kernel syscalls.
+
+2. AArch64 Tagged Address ABI
+-----------------------------
+
+From the kernel syscall interface perspective and for the purposes of
+this document, a "valid tagged pointer" is a pointer with a potentially
+non-zero top-byte that references an address in the user process address
+space obtained in one of the following ways:
+
+- ``mmap()`` syscall where either:
+
+ - flags have the ``MAP_ANONYMOUS`` bit set or
+ - the file descriptor refers to a regular file (including those
+ returned by ``memfd_create()``) or ``/dev/zero``
+
+- ``brk()`` syscall (i.e. the heap area between the initial location of
+ the program break at process creation and its current location).
+
+- any memory mapped by the kernel in the address space of the process
+ during creation and with the same restrictions as for ``mmap()`` above
+ (e.g. data, bss, stack).
+
+The AArch64 Tagged Address ABI has two stages of relaxation depending on
+how the user addresses are used by the kernel:
+
+1. User addresses not accessed by the kernel but used for address space
+ management (e.g. ``mprotect()``, ``madvise()``). The use of valid
+ tagged pointers in this context is allowed with these exceptions:
+
+ - ``brk()``, ``mmap()`` and the ``new_address`` argument to
+ ``mremap()`` as these have the potential to alias with existing
+ user addresses.
+
+ NOTE: This behaviour changed in v5.6 and so some earlier kernels may
+ incorrectly accept valid tagged pointers for the ``brk()``,
+ ``mmap()`` and ``mremap()`` system calls.
+
+ - The ``range.start``, ``start`` and ``dst`` arguments to the
+ ``UFFDIO_*`` ``ioctl()``s used on a file descriptor obtained from
+ ``userfaultfd()``, as fault addresses subsequently obtained by reading
+ the file descriptor will be untagged, which may otherwise confuse
+ tag-unaware programs.
+
+ NOTE: This behaviour changed in v5.14 and so some earlier kernels may
+ incorrectly accept valid tagged pointers for this system call.
+
+2. User addresses accessed by the kernel (e.g. ``write()``). This ABI
+ relaxation is disabled by default and the application thread needs to
+ explicitly enable it via ``prctl()`` as follows:
+
+ - ``PR_SET_TAGGED_ADDR_CTRL``: enable or disable the AArch64 Tagged
+ Address ABI for the calling thread.
+
+ The ``(unsigned int) arg2`` argument is a bit mask describing the
+ control mode used:
+
+ - ``PR_TAGGED_ADDR_ENABLE``: enable AArch64 Tagged Address ABI.
+ Default status is disabled.
+
+ Arguments ``arg3``, ``arg4``, and ``arg5`` must be 0.
+
+ - ``PR_GET_TAGGED_ADDR_CTRL``: get the status of the AArch64 Tagged
+ Address ABI for the calling thread.
+
+ Arguments ``arg2``, ``arg3``, ``arg4``, and ``arg5`` must be 0.
+
+ The ABI properties described above are thread-scoped, inherited on
+ clone() and fork() and cleared on exec().
+
+ Calling ``prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0)``
+ returns ``-EINVAL`` if the AArch64 Tagged Address ABI is globally
+ disabled by ``sysctl abi.tagged_addr_disabled=1``. The default
+ ``sysctl abi.tagged_addr_disabled`` configuration is 0.
+
+When the AArch64 Tagged Address ABI is enabled for a thread, the
+following behaviours are guaranteed:
+
+- All syscalls except the cases mentioned in section 3 can accept any
+ valid tagged pointer.
+
+- The syscall behaviour is undefined for invalid tagged pointers: it may
+ result in an error code being returned, a (fatal) signal being raised,
+ or other modes of failure.
+
+- The syscall behaviour for a valid tagged pointer is the same as for
+ the corresponding untagged pointer.
+
+
+A definition of the meaning of tagged pointers on AArch64 can be found
+in Documentation/arch/arm64/tagged-pointers.rst.
+
+3. AArch64 Tagged Address ABI Exceptions
+-----------------------------------------
+
+The following system call parameters must be untagged regardless of the
+ABI relaxation:
+
+- ``prctl()`` other than pointers to user data either passed directly or
+ indirectly as arguments to be accessed by the kernel.
+
+- ``ioctl()`` other than pointers to user data either passed directly or
+ indirectly as arguments to be accessed by the kernel.
+
+- ``shmat()`` and ``shmdt()``.
+
+- ``brk()`` (since kernel v5.6).
+
+- ``mmap()`` (since kernel v5.6).
+
+- ``mremap()``, the ``new_address`` argument (since kernel v5.6).
+
+Any attempt to use non-zero tagged pointers may result in an error code
+being returned, a (fatal) signal being raised, or other modes of
+failure.
+
+4. Example of correct usage
+---------------------------
+.. code-block:: c
+
+ #include <stdlib.h>
+ #include <string.h>
+ #include <unistd.h>
+ #include <sys/mman.h>
+ #include <sys/prctl.h>
+
+ #define PR_SET_TAGGED_ADDR_CTRL 55
+ #define PR_TAGGED_ADDR_ENABLE (1UL << 0)
+
+ #define TAG_SHIFT 56
+
+ int main(void)
+ {
+ int tbi_enabled = 0;
+ unsigned long tag = 0;
+ char *ptr;
+
+ /* check/enable the tagged address ABI */
+ if (!prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0))
+ tbi_enabled = 1;
+
+ /* memory allocation */
+ ptr = mmap(NULL, sysconf(_SC_PAGE_SIZE), PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ if (ptr == MAP_FAILED)
+ return 1;
+
+ /* set a non-zero tag if the ABI is available */
+ if (tbi_enabled)
+ tag = rand() & 0xff;
+ ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
+
+ /* memory access to a tagged address */
+ strcpy(ptr, "tagged pointer\n");
+
+ /* syscall with a tagged pointer */
+ write(1, ptr, strlen(ptr));
+
+ return 0;
+ }
diff --git a/Documentation/arch/arm64/tagged-pointers.rst b/Documentation/arch/arm64/tagged-pointers.rst
new file mode 100644
index 0000000..81b6c2a
--- /dev/null
+++ b/Documentation/arch/arm64/tagged-pointers.rst
@@ -0,0 +1,88 @@
+=========================================
+Tagged virtual addresses in AArch64 Linux
+=========================================
+
+Author: Will Deacon <will.deacon@arm.com>
+
+Date : 12 June 2013
+
+This document briefly describes the provision of tagged virtual
+addresses in the AArch64 translation system and their potential uses
+in AArch64 Linux.
+
+The kernel configures the translation tables so that translations made
+via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
+the virtual address ignored by the translation hardware. This frees up
+this byte for application use.
+
+
+Passing tagged addresses to the kernel
+--------------------------------------
+
+All interpretation of userspace memory addresses by the kernel assumes
+an address tag of 0x00, unless the application enables the AArch64
+Tagged Address ABI explicitly
+(Documentation/arch/arm64/tagged-address-abi.rst).
+
+This includes, but is not limited to, addresses found in:
+
+ - pointer arguments to system calls, including pointers in structures
+ passed to system calls,
+
+ - the stack pointer (sp), e.g. when interpreting it to deliver a
+ signal,
+
+ - the frame pointer (x29) and frame records, e.g. when interpreting
+ them to generate a backtrace or call graph.
+
+Using non-zero address tags in any of these locations when the
+userspace application did not enable the AArch64 Tagged Address ABI may
+result in an error code being returned, a (fatal) signal being raised,
+or other modes of failure.
+
+For these reasons, when the AArch64 Tagged Address ABI is disabled,
+passing non-zero address tags to the kernel via system calls is
+forbidden, and using a non-zero address tag for sp is strongly
+discouraged.
+
+Programs maintaining a frame pointer and frame records that use non-zero
+address tags may suffer impaired or inaccurate debug and profiling
+visibility.
+
+
+Preserving tags
+---------------
+
+When delivering signals, non-zero tags are not preserved in
+siginfo.si_addr unless the flag SA_EXPOSE_TAGBITS was set in
+sigaction.sa_flags when the signal handler was installed. This means
+that signal handlers in applications making use of tags cannot rely
+on the tag information for user virtual addresses being maintained
+in these fields unless the flag was set.
+
+Due to architecture limitations, bits 63:60 of the fault address
+are not preserved in response to synchronous tag check faults
+(SEGV_MTESERR) even if SA_EXPOSE_TAGBITS was set. Applications should
+treat the values of these bits as undefined in order to accommodate
+future architecture revisions which may preserve the bits.
+
+For signals raised in response to watchpoint debug exceptions, the
+tag information will be preserved regardless of the SA_EXPOSE_TAGBITS
+flag setting.
+
+Non-zero tags are never preserved in sigcontext.fault_address
+regardless of the SA_EXPOSE_TAGBITS flag setting.
+
+The architecture prevents the use of a tagged PC, so the upper byte will
+be set to a sign-extension of bit 55 on exception return.
+
+This behaviour is maintained when the AArch64 Tagged Address ABI is
+enabled.
+
+
+Other considerations
+--------------------
+
+Special care should be taken when using tagged pointers, since it is
+likely that C compilers will not hazard two virtual addresses differing
+only in the upper byte.
diff --git a/Documentation/arch/index.rst b/Documentation/arch/index.rst
index 80ee310..8458b88 100644
--- a/Documentation/arch/index.rst
+++ b/Documentation/arch/index.rst
@@ -10,8 +10,8 @@
:maxdepth: 2
arc/index
- ../arm/index
- ../arm64/index
+ arm/index
+ arm64/index
ia64/index
../loongarch/index
m68k/index
diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst
index 387ccbc..cb05d90 100644
--- a/Documentation/arch/x86/resctrl.rst
+++ b/Documentation/arch/x86/resctrl.rst
@@ -287,6 +287,13 @@
represents to the parent. Removing one of the created CTRL_MON groups
will automatically remove all MON groups below it.
+Moving MON group directories to a new parent CTRL_MON group is supported
+for the purpose of changing the resource allocations of a MON group
+without impacting its monitoring data or assigned tasks. This operation
+is not allowed for MON groups which monitor CPUs. No other move
+operation is currently allowed other than simply renaming a CTRL_MON or
+MON group.
+
All groups contain the following files:
"tasks":
diff --git a/Documentation/arm64/acpi_object_usage.rst b/Documentation/arm64/acpi_object_usage.rst
deleted file mode 100644
index 484ef96..0000000
--- a/Documentation/arm64/acpi_object_usage.rst
+++ /dev/null
@@ -1,738 +0,0 @@
-===========
-ACPI Tables
-===========
-
-The expectations of individual ACPI tables are discussed in the list that
-follows.
-
-If a section number is used, it refers to a section number in the ACPI
-specification where the object is defined. If "Signature Reserved" is used,
-the table signature (the first four bytes of the table) is the only portion
-of the table recognized by the specification, and the actual table is defined
-outside of the UEFI Forum (see Section 5.2.6 of the specification).
-
-For ACPI on arm64, tables also fall into the following categories:
-
- - Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
-
- - Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
-
- - Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IBFT,
- IORT, MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT,
- STAO, TCPA, TPM2, UEFI, XENV
-
- - Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT, MSDM, OEMx,
- PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
-
-====== ========================================================================
-Table Usage for ARMv8 Linux
-====== ========================================================================
-BERT Section 18.3 (signature == "BERT")
-
- **Boot Error Record Table**
-
- Must be supplied if RAS support is provided by the platform. It
- is recommended this table be supplied.
-
-BOOT Signature Reserved (signature == "BOOT")
-
- **simple BOOT flag table**
-
- Microsoft only table, will not be supported.
-
-BGRT Section 5.2.22 (signature == "BGRT")
-
- **Boot Graphics Resource Table**
-
- Optional, not currently supported, with no real use-case for an
- ARM server.
-
-CPEP Section 5.2.18 (signature == "CPEP")
-
- **Corrected Platform Error Polling table**
-
- Optional, not currently supported, and not recommended until such
- time as ARM-compatible hardware is available, and the specification
- suitably modified.
-
-CSRT Signature Reserved (signature == "CSRT")
-
- **Core System Resources Table**
-
- Optional, not currently supported.
-
-DBG2 Signature Reserved (signature == "DBG2")
-
- **DeBuG port table 2**
-
- License has changed and should be usable. Optional if used instead
- of earlycon=<device> on the command line.
-
-DBGP Signature Reserved (signature == "DBGP")
-
- **DeBuG Port table**
-
- Microsoft only table, will not be supported.
-
-DSDT Section 5.2.11.1 (signature == "DSDT")
-
- **Differentiated System Description Table**
-
- A DSDT is required; see also SSDT.
-
- ACPI tables contain only one DSDT but can contain one or more SSDTs,
- which are optional. Each SSDT can only add to the ACPI namespace,
- but cannot modify or replace anything in the DSDT.
-
-DMAR Signature Reserved (signature == "DMAR")
-
- **DMA Remapping table**
-
- x86 only table, will not be supported.
-
-DRTM Signature Reserved (signature == "DRTM")
-
- **Dynamic Root of Trust for Measurement table**
-
- Optional, not currently supported.
-
-ECDT Section 5.2.16 (signature == "ECDT")
-
- **Embedded Controller Description Table**
-
- Optional, not currently supported, but could be used on ARM if and
- only if one uses the GPE_BIT field to represent an IRQ number, since
- there are no GPE blocks defined in hardware reduced mode. This would
- need to be modified in the ACPI specification.
-
-EINJ Section 18.6 (signature == "EINJ")
-
- **Error Injection table**
-
- This table is very useful for testing platform response to error
- conditions; it allows one to inject an error into the system as
- if it had actually occurred. However, this table should not be
- shipped with a production system; it should be dynamically loaded
- and executed with the ACPICA tools only during testing.
-
-ERST Section 18.5 (signature == "ERST")
-
- **Error Record Serialization Table**
-
- On a platform supports RAS, this table must be supplied if it is not
- UEFI-based; if it is UEFI-based, this table may be supplied. When this
- table is not present, UEFI run time service will be utilized to save
- and retrieve hardware error information to and from a persistent store.
-
-ETDT Signature Reserved (signature == "ETDT")
-
- **Event Timer Description Table**
-
- Obsolete table, will not be supported.
-
-FACS Section 5.2.10 (signature == "FACS")
-
- **Firmware ACPI Control Structure**
-
- It is unlikely that this table will be terribly useful. If it is
- provided, the Global Lock will NOT be used since it is not part of
- the hardware reduced profile, and only 64-bit address fields will
- be considered valid.
-
-FADT Section 5.2.9 (signature == "FACP")
-
- **Fixed ACPI Description Table**
- Required for arm64.
-
-
- The HW_REDUCED_ACPI flag must be set. All of the fields that are
- to be ignored when HW_REDUCED_ACPI is set are expected to be set to
- zero.
-
- If an FACS table is provided, the X_FIRMWARE_CTRL field is to be
- used, not FIRMWARE_CTRL.
-
- If PSCI is used (as is recommended), make sure that ARM_BOOT_ARCH is
- filled in properly - that the PSCI_COMPLIANT flag is set and that
- PSCI_USE_HVC is set or unset as needed (see table 5-37).
-
- For the DSDT that is also required, the X_DSDT field is to be used,
- not the DSDT field.
-
-FPDT Section 5.2.23 (signature == "FPDT")
-
- **Firmware Performance Data Table**
-
- Optional, useful for boot performance profiling.
-
-GTDT Section 5.2.24 (signature == "GTDT")
-
- **Generic Timer Description Table**
-
- Required for arm64.
-
-HEST Section 18.3.2 (signature == "HEST")
-
- **Hardware Error Source Table**
-
- ARM-specific error sources have been defined; please use those or the
- PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER
- Bridge), or use type 9 (Generic Hardware Error Source). Firmware first
- error handling is possible if and only if Trusted Firmware is being
- used on arm64.
-
- Must be supplied if RAS support is provided by the platform. It
- is recommended this table be supplied.
-
-HPET Signature Reserved (signature == "HPET")
-
- **High Precision Event timer Table**
-
- x86 only table, will not be supported.
-
-IBFT Signature Reserved (signature == "IBFT")
-
- **iSCSI Boot Firmware Table**
-
- Microsoft defined table, support TBD.
-
-IORT Signature Reserved (signature == "IORT")
-
- **Input Output Remapping Table**
-
- arm64 only table, required in order to describe IO topology, SMMUs,
- and GIC ITSs, and how those various components are connected together,
- such as identifying which components are behind which SMMUs/ITSs.
- This table will only be required on certain SBSA platforms (e.g.,
- when using GICv3-ITS and an SMMU); on SBSA Level 0 platforms, it
- remains optional.
-
-IVRS Signature Reserved (signature == "IVRS")
-
- **I/O Virtualization Reporting Structure**
-
- x86_64 (AMD) only table, will not be supported.
-
-LPIT Signature Reserved (signature == "LPIT")
-
- **Low Power Idle Table**
-
- x86 only table as of ACPI 5.1; starting with ACPI 6.0, processor
- descriptions and power states on ARM platforms should use the DSDT
- and define processor container devices (_HID ACPI0010, Section 8.4,
- and more specifically 8.4.3 and 8.4.4).
-
-MADT Section 5.2.12 (signature == "APIC")
-
- **Multiple APIC Description Table**
-
- Required for arm64. Only the GIC interrupt controller structures
- should be used (types 0xA - 0xF).
-
-MCFG Signature Reserved (signature == "MCFG")
-
- **Memory-mapped ConFiGuration space**
-
- If the platform supports PCI/PCIe, an MCFG table is required.
-
-MCHI Signature Reserved (signature == "MCHI")
-
- **Management Controller Host Interface table**
-
- Optional, not currently supported.
-
-MPST Section 5.2.21 (signature == "MPST")
-
- **Memory Power State Table**
-
- Optional, not currently supported.
-
-MSCT Section 5.2.19 (signature == "MSCT")
-
- **Maximum System Characteristic Table**
-
- Optional, not currently supported.
-
-MSDM Signature Reserved (signature == "MSDM")
-
- **Microsoft Data Management table**
-
- Microsoft only table, will not be supported.
-
-NFIT Section 5.2.25 (signature == "NFIT")
-
- **NVDIMM Firmware Interface Table**
-
- Optional, not currently supported.
-
-OEMx Signature of "OEMx" only
-
- **OEM Specific Tables**
-
- All tables starting with a signature of "OEM" are reserved for OEM
- use. Since these are not meant to be of general use but are limited
- to very specific end users, they are not recommended for use and are
- not supported by the kernel for arm64.
-
-PCCT Section 14.1 (signature == "PCCT)
-
- **Platform Communications Channel Table**
-
- Recommend for use on arm64; use of PCC is recommended when using CPPC
- to control performance and power for platform processors.
-
-PMTT Section 5.2.21.12 (signature == "PMTT")
-
- **Platform Memory Topology Table**
-
- Optional, not currently supported.
-
-PSDT Section 5.2.11.3 (signature == "PSDT")
-
- **Persistent System Description Table**
-
- Obsolete table, will not be supported.
-
-RASF Section 5.2.20 (signature == "RASF")
-
- **RAS Feature table**
-
- Optional, not currently supported.
-
-RSDP Section 5.2.5 (signature == "RSD PTR")
-
- **Root System Description PoinTeR**
-
- Required for arm64.
-
-RSDT Section 5.2.7 (signature == "RSDT")
-
- **Root System Description Table**
-
- Since this table can only provide 32-bit addresses, it is deprecated
- on arm64, and will not be used. If provided, it will be ignored.
-
-SBST Section 5.2.14 (signature == "SBST")
-
- **Smart Battery Subsystem Table**
-
- Optional, not currently supported.
-
-SLIC Signature Reserved (signature == "SLIC")
-
- **Software LIcensing table**
-
- Microsoft only table, will not be supported.
-
-SLIT Section 5.2.17 (signature == "SLIT")
-
- **System Locality distance Information Table**
-
- Optional in general, but required for NUMA systems.
-
-SPCR Signature Reserved (signature == "SPCR")
-
- **Serial Port Console Redirection table**
-
- Required for arm64.
-
-SPMI Signature Reserved (signature == "SPMI")
-
- **Server Platform Management Interface table**
-
- Optional, not currently supported.
-
-SRAT Section 5.2.16 (signature == "SRAT")
-
- **System Resource Affinity Table**
-
- Optional, but if used, only the GICC Affinity structures are read.
- To support arm64 NUMA, this table is required.
-
-SSDT Section 5.2.11.2 (signature == "SSDT")
-
- **Secondary System Description Table**
-
- These tables are a continuation of the DSDT; these are recommended
- for use with devices that can be added to a running system, but can
- also serve the purpose of dividing up device descriptions into more
- manageable pieces.
-
- An SSDT can only ADD to the ACPI namespace. It cannot modify or
- replace existing device descriptions already in the namespace.
-
- These tables are optional, however. ACPI tables should contain only
- one DSDT but can contain many SSDTs.
-
-STAO Signature Reserved (signature == "STAO")
-
- **_STA Override table**
-
- Optional, but only necessary in virtualized environments in order to
- hide devices from guest OSs.
-
-TCPA Signature Reserved (signature == "TCPA")
-
- **Trusted Computing Platform Alliance table**
-
- Optional, not currently supported, and may need changes to fully
- interoperate with arm64.
-
-TPM2 Signature Reserved (signature == "TPM2")
-
- **Trusted Platform Module 2 table**
-
- Optional, not currently supported, and may need changes to fully
- interoperate with arm64.
-
-UEFI Signature Reserved (signature == "UEFI")
-
- **UEFI ACPI data table**
-
- Optional, not currently supported. No known use case for arm64,
- at present.
-
-WAET Signature Reserved (signature == "WAET")
-
- **Windows ACPI Emulated devices Table**
-
- Microsoft only table, will not be supported.
-
-WDAT Signature Reserved (signature == "WDAT")
-
- **Watch Dog Action Table**
-
- Microsoft only table, will not be supported.
-
-WDRT Signature Reserved (signature == "WDRT")
-
- **Watch Dog Resource Table**
-
- Microsoft only table, will not be supported.
-
-WPBT Signature Reserved (signature == "WPBT")
-
- **Windows Platform Binary Table**
-
- Microsoft only table, will not be supported.
-
-XENV Signature Reserved (signature == "XENV")
-
- **Xen project table**
-
- Optional, used only by Xen at present.
-
-XSDT Section 5.2.8 (signature == "XSDT")
-
- **eXtended System Description Table**
-
- Required for arm64.
-====== ========================================================================
-
-ACPI Objects
-------------
-The expectations on individual ACPI objects that are likely to be used are
-shown in the list that follows; any object not explicitly mentioned below
-should be used as needed for a particular platform or particular subsystem,
-such as power management or PCI.
-
-===== ================ ========================================================
-Name Section Usage for ARMv8 Linux
-===== ================ ========================================================
-_CCA 6.2.17 This method must be defined for all bus masters
- on arm64 - there are no assumptions made about
- whether such devices are cache coherent or not.
- The _CCA value is inherited by all descendants of
- these devices so it does not need to be repeated.
- Without _CCA on arm64, the kernel does not know what
- to do about setting up DMA for the device.
-
- NB: this method provides default cache coherency
- attributes; the presence of an SMMU can be used to
- modify that, however. For example, a master could
- default to non-coherent, but be made coherent with
- the appropriate SMMU configuration (see Table 17 of
- the IORT specification, ARM Document DEN 0049B).
-
-_CID 6.1.2 Use as needed, see also _HID.
-
-_CLS 6.1.3 Use as needed, see also _HID.
-
-_CPC 8.4.7.1 Use as needed, power management specific. CPPC is
- recommended on arm64.
-
-_CRS 6.2.2 Required on arm64.
-
-_CSD 8.4.2.2 Use as needed, used only in conjunction with _CST.
-
-_CST 8.4.2.1 Low power idle states (8.4.4) are recommended instead
- of C-states.
-
-_DDN 6.1.4 This field can be used for a device name. However,
- it is meant for DOS device names (e.g., COM1), so be
- careful of its use across OSes.
-
-_DSD 6.2.5 To be used with caution. If this object is used, try
- to use it within the constraints already defined by the
- Device Properties UUID. Only in rare circumstances
- should it be necessary to create a new _DSD UUID.
-
- In either case, submit the _DSD definition along with
- any driver patches for discussion, especially when
- device properties are used. A driver will not be
- considered complete without a corresponding _DSD
- description. Once approved by kernel maintainers,
- the UUID or device properties must then be registered
- with the UEFI Forum; this may cause some iteration as
- more than one OS will be registering entries.
-
-_DSM 9.1.1 Do not use this method. It is not standardized, the
- return values are not well documented, and it is
- currently a frequent source of error.
-
-\_GL 5.7.1 This object is not to be used in hardware reduced
- mode, and therefore should not be used on arm64.
-
-_GLK 6.5.7 This object requires a global lock be defined; there
- is no global lock on arm64 since it runs in hardware
- reduced mode. Hence, do not use this object on arm64.
-
-\_GPE 5.3.1 This namespace is for x86 use only. Do not use it
- on arm64.
-
-_HID 6.1.5 This is the primary object to use in device probing,
- though _CID and _CLS may also be used.
-
-_INI 6.5.1 Not required, but can be useful in setting up devices
- when UEFI leaves them in a state that may not be what
- the driver expects before it starts probing.
-
-_LPI 8.4.4.3 Recommended for use with processor definitions (_HID
- ACPI0010) on arm64. See also _RDI.
-
-_MLS 6.1.7 Highly recommended for use in internationalization.
-
-_OFF 7.2.2 It is recommended to define this method for any device
- that can be turned on or off.
-
-_ON 7.2.3 It is recommended to define this method for any device
- that can be turned on or off.
-
-\_OS 5.7.3 This method will return "Linux" by default (this is
- the value of the macro ACPI_OS_NAME on Linux). The
- command line parameter acpi_os=<string> can be used
- to set it to some other value.
-
-_OSC 6.2.11 This method can be a global method in ACPI (i.e.,
- \_SB._OSC), or it may be associated with a specific
- device (e.g., \_SB.DEV0._OSC), or both. When used
- as a global method, only capabilities published in
- the ACPI specification are allowed. When used as
- a device-specific method, the process described for
- using _DSD MUST be used to create an _OSC definition;
- out-of-process use of _OSC is not allowed. That is,
- submit the device-specific _OSC usage description as
- part of the kernel driver submission, get it approved
- by the kernel community, then register it with the
- UEFI Forum.
-
-\_OSI 5.7.2 Deprecated on ARM64. As far as ACPI firmware is
- concerned, _OSI is not to be used to determine what
- sort of system is being used or what functionality
- is provided. The _OSC method is to be used instead.
-
-_PDC 8.4.1 Deprecated, do not use on arm64.
-
-\_PIC 5.8.1 The method should not be used. On arm64, the only
- interrupt model available is GIC.
-
-\_PR 5.3.1 This namespace is for x86 use only on legacy systems.
- Do not use it on arm64.
-
-_PRT 6.2.13 Required as part of the definition of all PCI root
- devices.
-
-_PRx 7.3.8-11 Use as needed; power management specific. If _PR0 is
- defined, _PR3 must also be defined.
-
-_PSx 7.3.2-5 Use as needed; power management specific. If _PS0 is
- defined, _PS3 must also be defined. If clocks or
- regulators need adjusting to be consistent with power
- usage, change them in these methods.
-
-_RDI 8.4.4.4 Recommended for use with processor definitions (_HID
- ACPI0010) on arm64. This should only be used in
- conjunction with _LPI.
-
-\_REV 5.7.4 Always returns the latest version of ACPI supported.
-
-\_SB 5.3.1 Required on arm64; all devices must be defined in this
- namespace.
-
-_SLI 6.2.15 Use is recommended when SLIT table is in use.
-
-_STA 6.3.7, It is recommended to define this method for any device
- 7.2.4 that can be turned on or off. See also the STAO table
- that provides overrides to hide devices in virtualized
- environments.
-
-_SRS 6.2.16 Use as needed; see also _PRS.
-
-_STR 6.1.10 Recommended for conveying device names to end users;
- this is preferred over using _DDN.
-
-_SUB 6.1.9 Use as needed; _HID or _CID are preferred.
-
-_SUN 6.1.11 Use as needed, but recommended.
-
-_SWS 7.4.3 Use as needed; power management specific; this may
- require specification changes for use on arm64.
-
-_UID 6.1.12 Recommended for distinguishing devices of the same
- class; define it if at all possible.
-===== ================ ========================================================
-
-
-
-
-ACPI Event Model
-----------------
-Do not use GPE block devices; these are not supported in the hardware reduced
-profile used by arm64. Since there are no GPE blocks defined for use on ARM
-platforms, ACPI events must be signaled differently.
-
-There are two options: GPIO-signaled interrupts (Section 5.6.5), and
-interrupt-signaled events (Section 5.6.9). Interrupt-signaled events are a
-new feature in the ACPI 6.1 specification. Either - or both - can be used
-on a given platform, and which to use may be dependent of limitations in any
-given SoC. If possible, interrupt-signaled events are recommended.
-
-
-ACPI Processor Control
-----------------------
-Section 8 of the ACPI specification changed significantly in version 6.0.
-Processors should now be defined as Device objects with _HID ACPI0007; do
-not use the deprecated Processor statement in ASL. All multiprocessor systems
-should also define a hierarchy of processors, done with Processor Container
-Devices (see Section 8.4.3.1, _HID ACPI0010); do not use processor aggregator
-devices (Section 8.5) to describe processor topology. Section 8.4 of the
-specification describes the semantics of these object definitions and how
-they interrelate.
-
-Most importantly, the processor hierarchy defined also defines the low power
-idle states that are available to the platform, along with the rules for
-determining which processors can be turned on or off and the circumstances
-that control that. Without this information, the processors will run in
-whatever power state they were left in by UEFI.
-
-Note too, that the processor Device objects defined and the entries in the
-MADT for GICs are expected to be in synchronization. The _UID of the Device
-object must correspond to processor IDs used in the MADT.
-
-It is recommended that CPPC (8.4.5) be used as the primary model for processor
-performance control on arm64. C-states and P-states may become available at
-some point in the future, but most current design work appears to favor CPPC.
-
-Further, it is essential that the ARMv8 SoC provide a fully functional
-implementation of PSCI; this will be the only mechanism supported by ACPI
-to control CPU power state. Booting of secondary CPUs using the ACPI
-parking protocol is possible, but discouraged, since only PSCI is supported
-for ARM servers.
-
-
-ACPI System Address Map Interfaces
-----------------------------------
-In Section 15 of the ACPI specification, several methods are mentioned as
-possible mechanisms for conveying memory resource information to the kernel.
-For arm64, we will only support UEFI for booting with ACPI, hence the UEFI
-GetMemoryMap() boot service is the only mechanism that will be used.
-
-
-ACPI Platform Error Interfaces (APEI)
--------------------------------------
-The APEI tables supported are described above.
-
-APEI requires the equivalent of an SCI and an NMI on ARMv8. The SCI is used
-to notify the OSPM of errors that have occurred but can be corrected and the
-system can continue correct operation, even if possibly degraded. The NMI is
-used to indicate fatal errors that cannot be corrected, and require immediate
-attention.
-
-Since there is no direct equivalent of the x86 SCI or NMI, arm64 handles
-these slightly differently. The SCI is handled as a high priority interrupt;
-given that these are corrected (or correctable) errors being reported, this
-is sufficient. The NMI is emulated as the highest priority interrupt
-possible. This implies some caution must be used since there could be
-interrupts at higher privilege levels or even interrupts at the same priority
-as the emulated NMI. In Linux, this should not be the case but one should
-be aware it could happen.
-
-
-ACPI Objects Not Supported on ARM64
------------------------------------
-While this may change in the future, there are several classes of objects
-that can be defined, but are not currently of general interest to ARM servers.
-Some of these objects have x86 equivalents, and may actually make sense in ARM
-servers. However, there is either no hardware available at present, or there
-may not even be a non-ARM implementation yet. Hence, they are not currently
-supported.
-
-The following classes of objects are not supported:
-
- - Section 9.2: ambient light sensor devices
-
- - Section 9.3: battery devices
-
- - Section 9.4: lids (e.g., laptop lids)
-
- - Section 9.8.2: IDE controllers
-
- - Section 9.9: floppy controllers
-
- - Section 9.10: GPE block devices
-
- - Section 9.15: PC/AT RTC/CMOS devices
-
- - Section 9.16: user presence detection devices
-
- - Section 9.17: I/O APIC devices; all GICs must be enumerable via MADT
-
- - Section 9.18: time and alarm devices (see 9.15)
-
- - Section 10: power source and power meter devices
-
- - Section 11: thermal management
-
- - Section 12: embedded controllers interface
-
- - Section 13: SMBus interfaces
-
-
-This also means that there is no support for the following objects:
-
-==== =========================== ==== ==========
-Name Section Name Section
-==== =========================== ==== ==========
-_ALC 9.3.4 _FDM 9.10.3
-_ALI 9.3.2 _FIX 6.2.7
-_ALP 9.3.6 _GAI 10.4.5
-_ALR 9.3.5 _GHL 10.4.7
-_ALT 9.3.3 _GTM 9.9.2.1.1
-_BCT 10.2.2.10 _LID 9.5.1
-_BDN 6.5.3 _PAI 10.4.4
-_BIF 10.2.2.1 _PCL 10.3.2
-_BIX 10.2.2.1 _PIF 10.3.3
-_BLT 9.2.3 _PMC 10.4.1
-_BMA 10.2.2.4 _PMD 10.4.8
-_BMC 10.2.2.12 _PMM 10.4.3
-_BMD 10.2.2.11 _PRL 10.3.4
-_BMS 10.2.2.5 _PSR 10.3.1
-_BST 10.2.2.6 _PTP 10.4.2
-_BTH 10.2.2.7 _SBS 10.1.3
-_BTM 10.2.2.9 _SHL 10.4.6
-_BTP 10.2.2.8 _STM 9.9.2.1.1
-_DCK 6.5.2 _UPD 9.16.1
-_EC 12.12 _UPP 9.16.2
-_FDE 9.10.1 _WPC 10.5.2
-_FDI 9.10.2 _WPP 10.5.3
-==== =========================== ==== ==========
diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arm64/arm-acpi.rst
deleted file mode 100644
index 47ecb99..0000000
--- a/Documentation/arm64/arm-acpi.rst
+++ /dev/null
@@ -1,528 +0,0 @@
-=====================
-ACPI on ARMv8 Servers
-=====================
-
-ACPI can be used for ARMv8 general purpose servers designed to follow
-the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server
-Base Boot Requirements) [1] specifications. Please note that the SBBR
-can be retrieved simply by visiting [1], but the SBSA is currently only
-available to those with an ARM login due to ARM IP licensing concerns.
-
-The ARMv8 kernel implements the reduced hardware model of ACPI version
-5.1 or later. Links to the specification and all external documents
-it refers to are managed by the UEFI Forum. The specification is
-available at http://www.uefi.org/specifications and documents referenced
-by the specification can be found via http://www.uefi.org/acpi.
-
-If an ARMv8 system does not meet the requirements of the SBSA and SBBR,
-or cannot be described using the mechanisms defined in the required ACPI
-specifications, then ACPI may not be a good fit for the hardware.
-
-While the documents mentioned above set out the requirements for building
-industry-standard ARMv8 servers, they also apply to more than one operating
-system. The purpose of this document is to describe the interaction between
-ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of
-ACPI and what ACPI can expect of Linux.
-
-
-Why ACPI on ARM?
-----------------
-Before examining the details of the interface between ACPI and Linux, it is
-useful to understand why ACPI is being used. Several technologies already
-exist in Linux for describing non-enumerable hardware, after all. In this
-section we summarize a blog post [2] from Grant Likely that outlines the
-reasoning behind ACPI on ARMv8 servers. Actually, we snitch a good portion
-of the summary text almost directly, to be honest.
-
-The short form of the rationale for ACPI on ARM is:
-
-- ACPI’s byte code (AML) allows the platform to encode hardware behavior,
- while DT explicitly does not support this. For hardware vendors, being
- able to encode behavior is a key tool used in supporting operating
- system releases on new hardware.
-
-- ACPI’s OSPM defines a power management model that constrains what the
- platform is allowed to do into a specific model, while still providing
- flexibility in hardware design.
-
-- In the enterprise server environment, ACPI has established bindings (such
- as for RAS) which are currently used in production systems. DT does not.
- Such bindings could be defined in DT at some point, but doing so means ARM
- and x86 would end up using completely different code paths in both firmware
- and the kernel.
-
-- Choosing a single interface to describe the abstraction between a platform
- and an OS is important. Hardware vendors would not be required to implement
- both DT and ACPI if they want to support multiple operating systems. And,
- agreeing on a single interface instead of being fragmented into per OS
- interfaces makes for better interoperability overall.
-
-- The new ACPI governance process works well and Linux is now at the same
- table as hardware vendors and other OS vendors. In fact, there is no
- longer any reason to feel that ACPI only belongs to Windows or that
- Linux is in any way secondary to Microsoft in this arena. The move of
- ACPI governance into the UEFI forum has significantly opened up the
- specification development process, and currently, a large portion of the
- changes being made to ACPI are being driven by Linux.
-
-Key to the use of ACPI is the support model. For servers in general, the
-responsibility for hardware behaviour cannot solely be the domain of the
-kernel, but rather must be split between the platform and the kernel, in
-order to allow for orderly change over time. ACPI frees the OS from needing
-to understand all the minute details of the hardware so that the OS doesn’t
-need to be ported to each and every device individually. It allows the
-hardware vendors to take responsibility for power management behaviour without
-depending on an OS release cycle which is not under their control.
-
-ACPI is also important because hardware and OS vendors have already worked
-out the mechanisms for supporting a general purpose computing ecosystem. The
-infrastructure is in place, the bindings are in place, and the processes are
-in place. DT does exactly what Linux needs it to when working with vertically
-integrated devices, but there are no good processes for supporting what the
-server vendors need. Linux could potentially get there with DT, but doing so
-really just duplicates something that already works. ACPI already does what
-the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
-vendors would still end up providing two completely separate firmware
-interfaces -- one for Linux and one for Windows.
-
-
-Kernel Compatibility
---------------------
-One of the primary motivations for ACPI is standardization, and using that
-to provide backward compatibility for Linux kernels. In the server market,
-software and hardware are often used for long periods. ACPI allows the
-kernel and firmware to agree on a consistent abstraction that can be
-maintained over time, even as hardware or software change. As long as the
-abstraction is supported, systems can be updated without necessarily having
-to replace the kernel.
-
-When a Linux driver or subsystem is first implemented using ACPI, it by
-definition ends up requiring a specific version of the ACPI specification
--- it's baseline. ACPI firmware must continue to work, even though it may
-not be optimal, with the earliest kernel version that first provides support
-for that baseline version of ACPI. There may be a need for additional drivers,
-but adding new functionality (e.g., CPU power management) should not break
-older kernel versions. Further, ACPI firmware must also work with the most
-recent version of the kernel.
-
-
-Relationship with Device Tree
------------------------------
-ACPI support in drivers and subsystems for ARMv8 should never be mutually
-exclusive with DT support at compile time.
-
-At boot time the kernel will only use one description method depending on
-parameters passed from the boot loader (including kernel bootargs).
-
-Regardless of whether DT or ACPI is used, the kernel must always be capable
-of booting with either scheme (in kernels with both schemes enabled at compile
-time).
-
-
-Booting using ACPI tables
--------------------------
-The only defined method for passing ACPI tables to the kernel on ARMv8
-is via the UEFI system configuration table. Just so it is explicit, this
-means that ACPI is only supported on platforms that boot via UEFI.
-
-When an ARMv8 system boots, it can either have DT information, ACPI tables,
-or in some very unusual cases, both. If no command line parameters are used,
-the kernel will try to use DT for device enumeration; if there is no DT
-present, the kernel will try to use ACPI tables, but only if they are present.
-In neither is available, the kernel will not boot. If acpi=force is used
-on the command line, the kernel will attempt to use ACPI tables first, but
-fall back to DT if there are no ACPI tables present. The basic idea is that
-the kernel will not fail to boot unless it absolutely has no other choice.
-
-Processing of ACPI tables may be disabled by passing acpi=off on the kernel
-command line; this is the default behavior.
-
-In order for the kernel to load and use ACPI tables, the UEFI implementation
-MUST set the ACPI_20_TABLE_GUID to point to the RSDP table (the table with
-the ACPI signature "RSD PTR "). If this pointer is incorrect and acpi=force
-is used, the kernel will disable ACPI and try to use DT to boot instead; the
-kernel has, in effect, determined that ACPI tables are not present at that
-point.
-
-If the pointer to the RSDP table is correct, the table will be mapped into
-the kernel by the ACPI core, using the address provided by UEFI.
-
-The ACPI core will then locate and map in all other ACPI tables provided by
-using the addresses in the RSDP table to find the XSDT (eXtended System
-Description Table). The XSDT in turn provides the addresses to all other
-ACPI tables provided by the system firmware; the ACPI core will then traverse
-this table and map in the tables listed.
-
-The ACPI core will ignore any provided RSDT (Root System Description Table).
-RSDTs have been deprecated and are ignored on arm64 since they only allow
-for 32-bit addresses.
-
-Further, the ACPI core will only use the 64-bit address fields in the FADT
-(Fixed ACPI Description Table). Any 32-bit address fields in the FADT will
-be ignored on arm64.
-
-Hardware reduced mode (see Section 4.1 of the ACPI 6.1 specification) will
-be enforced by the ACPI core on arm64. Doing so allows the ACPI core to
-run less complex code since it no longer has to provide support for legacy
-hardware from other architectures. Any fields that are not to be used for
-hardware reduced mode must be set to zero.
-
-For the ACPI core to operate properly, and in turn provide the information
-the kernel needs to configure devices, it expects to find the following
-tables (all section numbers refer to the ACPI 6.1 specification):
-
- - RSDP (Root System Description Pointer), section 5.2.5
-
- - XSDT (eXtended System Description Table), section 5.2.8
-
- - FADT (Fixed ACPI Description Table), section 5.2.9
-
- - DSDT (Differentiated System Description Table), section
- 5.2.11.1
-
- - MADT (Multiple APIC Description Table), section 5.2.12
-
- - GTDT (Generic Timer Description Table), section 5.2.24
-
- - If PCI is supported, the MCFG (Memory mapped ConFiGuration
- Table), section 5.2.6, specifically Table 5-31.
-
- - If booting without a console=<device> kernel parameter is
- supported, the SPCR (Serial Port Console Redirection table),
- section 5.2.6, specifically Table 5-31.
-
- - If necessary to describe the I/O topology, SMMUs and GIC ITSs,
- the IORT (Input Output Remapping Table, section 5.2.6, specifically
- Table 5-31).
-
- - If NUMA is supported, the SRAT (System Resource Affinity Table)
- and SLIT (System Locality distance Information Table), sections
- 5.2.16 and 5.2.17, respectively.
-
-If the above tables are not all present, the kernel may or may not be
-able to boot properly since it may not be able to configure all of the
-devices available. This list of tables is not meant to be all inclusive;
-in some environments other tables may be needed (e.g., any of the APEI
-tables from section 18) to support specific functionality.
-
-
-ACPI Detection
---------------
-Drivers should determine their probe() type by checking for a null
-value for ACPI_HANDLE, or checking .of_node, or other information in
-the device structure. This is detailed further in the "Driver
-Recommendations" section.
-
-In non-driver code, if the presence of ACPI needs to be detected at
-run time, then check the value of acpi_disabled. If CONFIG_ACPI is not
-set, acpi_disabled will always be 1.
-
-
-Device Enumeration
-------------------
-Device descriptions in ACPI should use standard recognized ACPI interfaces.
-These may contain less information than is typically provided via a Device
-Tree description for the same device. This is also one of the reasons that
-ACPI can be useful -- the driver takes into account that it may have less
-detailed information about the device and uses sensible defaults instead.
-If done properly in the driver, the hardware can change and improve over
-time without the driver having to change at all.
-
-Clocks provide an excellent example. In DT, clocks need to be specified
-and the drivers need to take them into account. In ACPI, the assumption
-is that UEFI will leave the device in a reasonable default state, including
-any clock settings. If for some reason the driver needs to change a clock
-value, this can be done in an ACPI method; all the driver needs to do is
-invoke the method and not concern itself with what the method needs to do
-to change the clock. Changing the hardware can then take place over time
-by changing what the ACPI method does, and not the driver.
-
-In DT, the parameters needed by the driver to set up clocks as in the example
-above are known as "bindings"; in ACPI, these are known as "Device Properties"
-and provided to a driver via the _DSD object.
-
-ACPI tables are described with a formal language called ASL, the ACPI
-Source Language (section 19 of the specification). This means that there
-are always multiple ways to describe the same thing -- including device
-properties. For example, device properties could use an ASL construct
-that looks like this: Name(KEY0, "value0"). An ACPI device driver would
-then retrieve the value of the property by evaluating the KEY0 object.
-However, using Name() this way has multiple problems: (1) ACPI limits
-names ("KEY0") to four characters unlike DT; (2) there is no industry
-wide registry that maintains a list of names, minimizing re-use; (3)
-there is also no registry for the definition of property values ("value0"),
-again making re-use difficult; and (4) how does one maintain backward
-compatibility as new hardware comes out? The _DSD method was created
-to solve precisely these sorts of problems; Linux drivers should ALWAYS
-use the _DSD method for device properties and nothing else.
-
-The _DSM object (ACPI Section 9.14.1) could also be used for conveying
-device properties to a driver. Linux drivers should only expect it to
-be used if _DSD cannot represent the data required, and there is no way
-to create a new UUID for the _DSD object. Note that there is even less
-regulation of the use of _DSM than there is of _DSD. Drivers that depend
-on the contents of _DSM objects will be more difficult to maintain over
-time because of this; as of this writing, the use of _DSM is the cause
-of quite a few firmware problems and is not recommended.
-
-Drivers should look for device properties in the _DSD object ONLY; the _DSD
-object is described in the ACPI specification section 6.2.5, but this only
-describes how to define the structure of an object returned via _DSD, and
-how specific data structures are defined by specific UUIDs. Linux should
-only use the _DSD Device Properties UUID [5]:
-
- - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
-
- - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
-
-The UEFI Forum provides a mechanism for registering device properties [4]
-so that they may be used across all operating systems supporting ACPI.
-Device properties that have not been registered with the UEFI Forum should
-not be used.
-
-Before creating new device properties, check to be sure that they have not
-been defined before and either registered in the Linux kernel documentation
-as DT bindings, or the UEFI Forum as device properties. While we do not want
-to simply move all DT bindings into ACPI device properties, we can learn from
-what has been previously defined.
-
-If it is necessary to define a new device property, or if it makes sense to
-synthesize the definition of a binding so it can be used in any firmware,
-both DT bindings and ACPI device properties for device drivers have review
-processes. Use them both. When the driver itself is submitted for review
-to the Linux mailing lists, the device property definitions needed must be
-submitted at the same time. A driver that supports ACPI and uses device
-properties will not be considered complete without their definitions. Once
-the device property has been accepted by the Linux community, it must be
-registered with the UEFI Forum [4], which will review it again for consistency
-within the registry. This may require iteration. The UEFI Forum, though,
-will always be the canonical site for device property definitions.
-
-It may make sense to provide notice to the UEFI Forum that there is the
-intent to register a previously unused device property name as a means of
-reserving the name for later use. Other operating system vendors will
-also be submitting registration requests and this may help smooth the
-process.
-
-Once registration and review have been completed, the kernel provides an
-interface for looking up device properties in a manner independent of
-whether DT or ACPI is being used. This API should be used [6]; it can
-eliminate some duplication of code paths in driver probing functions and
-discourage divergence between DT bindings and ACPI device properties.
-
-
-Programmable Power Control Resources
-------------------------------------
-Programmable power control resources include such resources as voltage/current
-providers (regulators) and clock sources.
-
-With ACPI, the kernel clock and regulator framework is not expected to be used
-at all.
-
-The kernel assumes that power control of these resources is represented with
-Power Resource Objects (ACPI section 7.1). The ACPI core will then handle
-correctly enabling and disabling resources as they are needed. In order to
-get that to work, ACPI assumes each device has defined D-states and that these
-can be controlled through the optional ACPI methods _PS0, _PS1, _PS2, and _PS3;
-in ACPI, _PS0 is the method to invoke to turn a device full on, and _PS3 is for
-turning a device full off.
-
-There are two options for using those Power Resources. They can:
-
- - be managed in a _PSx method which gets called on entry to power
- state Dx.
-
- - be declared separately as power resources with their own _ON and _OFF
- methods. They are then tied back to D-states for a particular device
- via _PRx which specifies which power resources a device needs to be on
- while in Dx. Kernel then tracks number of devices using a power resource
- and calls _ON/_OFF as needed.
-
-The kernel ACPI code will also assume that the _PSx methods follow the normal
-ACPI rules for such methods:
-
- - If either _PS0 or _PS3 is implemented, then the other method must also
- be implemented.
-
- - If a device requires usage or setup of a power resource when on, the ASL
- should organize that it is allocated/enabled using the _PS0 method.
-
- - Resources allocated or enabled in the _PS0 method should be disabled
- or de-allocated in the _PS3 method.
-
- - Firmware will leave the resources in a reasonable state before handing
- over control to the kernel.
-
-Such code in _PSx methods will of course be very platform specific. But,
-this allows the driver to abstract out the interface for operating the device
-and avoid having to read special non-standard values from ACPI tables. Further,
-abstracting the use of these resources allows the hardware to change over time
-without requiring updates to the driver.
-
-
-Clocks
-------
-ACPI makes the assumption that clocks are initialized by the firmware --
-UEFI, in this case -- to some working value before control is handed over
-to the kernel. This has implications for devices such as UARTs, or SoC-driven
-LCD displays, for example.
-
-When the kernel boots, the clocks are assumed to be set to reasonable
-working values. If for some reason the frequency needs to change -- e.g.,
-throttling for power management -- the device driver should expect that
-process to be abstracted out into some ACPI method that can be invoked
-(please see the ACPI specification for further recommendations on standard
-methods to be expected). The only exceptions to this are CPU clocks where
-CPPC provides a much richer interface than ACPI methods. If the clocks
-are not set, there is no direct way for Linux to control them.
-
-If an SoC vendor wants to provide fine-grained control of the system clocks,
-they could do so by providing ACPI methods that could be invoked by Linux
-drivers. However, this is NOT recommended and Linux drivers should NOT use
-such methods, even if they are provided. Such methods are not currently
-standardized in the ACPI specification, and using them could tie a kernel
-to a very specific SoC, or tie an SoC to a very specific version of the
-kernel, both of which we are trying to avoid.
-
-
-Driver Recommendations
-----------------------
-DO NOT remove any DT handling when adding ACPI support for a driver. The
-same device may be used on many different systems.
-
-DO try to structure the driver so that it is data-driven. That is, set up
-a struct containing internal per-device state based on defaults and whatever
-else must be discovered by the driver probe function. Then, have the rest
-of the driver operate off of the contents of that struct. Doing so should
-allow most divergence between ACPI and DT functionality to be kept local to
-the probe function instead of being scattered throughout the driver. For
-example::
-
- static int device_probe_dt(struct platform_device *pdev)
- {
- /* DT specific functionality */
- ...
- }
-
- static int device_probe_acpi(struct platform_device *pdev)
- {
- /* ACPI specific functionality */
- ...
- }
-
- static int device_probe(struct platform_device *pdev)
- {
- ...
- struct device_node node = pdev->dev.of_node;
- ...
-
- if (node)
- ret = device_probe_dt(pdev);
- else if (ACPI_HANDLE(&pdev->dev))
- ret = device_probe_acpi(pdev);
- else
- /* other initialization */
- ...
- /* Continue with any generic probe operations */
- ...
- }
-
-DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it
-clear the different names the driver is probed for, both from DT and from
-ACPI::
-
- static struct of_device_id virtio_mmio_match[] = {
- { .compatible = "virtio,mmio", },
- { }
- };
- MODULE_DEVICE_TABLE(of, virtio_mmio_match);
-
- static const struct acpi_device_id virtio_mmio_acpi_match[] = {
- { "LNRO0005", },
- { }
- };
- MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
-
-
-ASWG
-----
-The ACPI specification changes regularly. During the year 2014, for instance,
-version 5.1 was released and version 6.0 substantially completed, with most of
-the changes being driven by ARM-specific requirements. Proposed changes are
-presented and discussed in the ASWG (ACPI Specification Working Group) which
-is a part of the UEFI Forum. The current version of the ACPI specification
-is 6.1 release in January 2016.
-
-Participation in this group is open to all UEFI members. Please see
-http://www.uefi.org/workinggroup for details on group membership.
-
-It is the intent of the ARMv8 ACPI kernel code to follow the ACPI specification
-as closely as possible, and to only implement functionality that complies with
-the released standards from UEFI ASWG. As a practical matter, there will be
-vendors that provide bad ACPI tables or violate the standards in some way.
-If this is because of errors, quirks and fix-ups may be necessary, but will
-be avoided if possible. If there are features missing from ACPI that preclude
-it from being used on a platform, ECRs (Engineering Change Requests) should be
-submitted to ASWG and go through the normal approval process; for those that
-are not UEFI members, many other members of the Linux community are and would
-likely be willing to assist in submitting ECRs.
-
-
-Linux Code
-----------
-Individual items specific to Linux on ARM, contained in the Linux
-source code, are in the list that follows:
-
-ACPI_OS_NAME
- This macro defines the string to be returned when
- an ACPI method invokes the _OS method. On ARM64
- systems, this macro will be "Linux" by default.
- The command line parameter acpi_os=<string>
- can be used to set it to some other value. The
- default value for other architectures is "Microsoft
- Windows NT", for example.
-
-ACPI Objects
-------------
-Detailed expectations for ACPI tables and object are listed in the file
-Documentation/arm64/acpi_object_usage.rst.
-
-
-References
-----------
-[0] http://silver.arm.com
- document ARM-DEN-0029, or newer:
- "Server Base System Architecture", version 2.3, dated 27 Mar 2014
-
-[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0044a/Server_Base_Boot_Requirements.pdf
- Document ARM-DEN-0044A, or newer: "Server Base Boot Requirements, System
- Software on ARM Platforms", dated 16 Aug 2014
-
-[2] http://www.secretlab.ca/archives/151,
- 10 Jan 2015, Copyright (c) 2015,
- Linaro Ltd., written by Grant Likely.
-
-[3] AMD ACPI for Seattle platform documentation
- http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_Guide.pdf
-
-
-[4] http://www.uefi.org/acpi
- please see the link for the "ACPI _DSD Device
- Property Registry Instructions"
-
-[5] http://www.uefi.org/acpi
- please see the link for the "_DSD (Device
- Specific Data) Implementation Guide"
-
-[6] Kernel code for the unified device
- property interface can be found in
- include/linux/property.h and drivers/base/property.c.
-
-
-Authors
--------
-- Al Stone <al.stone@linaro.org>
-- Graeme Gregory <graeme.gregory@linaro.org>
-- Hanjun Guo <hanjun.guo@linaro.org>
-
-- Grant Likely <grant.likely@linaro.org>, for the "Why ACPI on ARM?" section
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
deleted file mode 100644
index ffeccdd..0000000
--- a/Documentation/arm64/booting.rst
+++ /dev/null
@@ -1,431 +0,0 @@
-=====================
-Booting AArch64 Linux
-=====================
-
-Author: Will Deacon <will.deacon@arm.com>
-
-Date : 07 September 2012
-
-This document is based on the ARM booting document by Russell King and
-is relevant to all public releases of the AArch64 Linux kernel.
-
-The AArch64 exception model is made up of a number of exception levels
-(EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure
-counterpart. EL2 is the hypervisor level, EL3 is the highest priority
-level and exists only in secure mode. Both are architecturally optional.
-
-For the purposes of this document, we will use the term `boot loader`
-simply to define all software that executes on the CPU(s) before control
-is passed to the Linux kernel. This may include secure monitor and
-hypervisor code, or it may just be a handful of instructions for
-preparing a minimal boot environment.
-
-Essentially, the boot loader should provide (as a minimum) the
-following:
-
-1. Setup and initialise the RAM
-2. Setup the device tree
-3. Decompress the kernel image
-4. Call the kernel image
-
-
-1. Setup and initialise RAM
----------------------------
-
-Requirement: MANDATORY
-
-The boot loader is expected to find and initialise all RAM that the
-kernel will use for volatile data storage in the system. It performs
-this in a machine dependent manner. (It may use internal algorithms
-to automatically locate and size all RAM, or it may use knowledge of
-the RAM in the machine, or any other method the boot loader designer
-sees fit.)
-
-
-2. Setup the device tree
--------------------------
-
-Requirement: MANDATORY
-
-The device tree blob (dtb) must be placed on an 8-byte boundary and must
-not exceed 2 megabytes in size. Since the dtb will be mapped cacheable
-using blocks of up to 2 megabytes in size, it must not be placed within
-any 2M region which must be mapped with any specific attributes.
-
-NOTE: versions prior to v4.2 also require that the DTB be placed within
-the 512 MB region starting at text_offset bytes below the kernel Image.
-
-3. Decompress the kernel image
-------------------------------
-
-Requirement: OPTIONAL
-
-The AArch64 kernel does not currently provide a decompressor and
-therefore requires decompression (gzip etc.) to be performed by the boot
-loader if a compressed Image target (e.g. Image.gz) is used. For
-bootloaders that do not implement this requirement, the uncompressed
-Image target is available instead.
-
-
-4. Call the kernel image
-------------------------
-
-Requirement: MANDATORY
-
-The decompressed kernel image contains a 64-byte header as follows::
-
- u32 code0; /* Executable code */
- u32 code1; /* Executable code */
- u64 text_offset; /* Image load offset, little endian */
- u64 image_size; /* Effective Image size, little endian */
- u64 flags; /* kernel flags, little endian */
- u64 res2 = 0; /* reserved */
- u64 res3 = 0; /* reserved */
- u64 res4 = 0; /* reserved */
- u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
- u32 res5; /* reserved (used for PE COFF offset) */
-
-
-Header notes:
-
-- As of v3.17, all fields are little endian unless stated otherwise.
-
-- code0/code1 are responsible for branching to stext.
-
-- when booting through EFI, code0/code1 are initially skipped.
- res5 is an offset to the PE header and the PE header has the EFI
- entry point (efi_stub_entry). When the stub has done its work, it
- jumps to code0 to resume the normal boot process.
-
-- Prior to v3.17, the endianness of text_offset was not specified. In
- these cases image_size is zero and text_offset is 0x80000 in the
- endianness of the kernel. Where image_size is non-zero image_size is
- little-endian and must be respected. Where image_size is zero,
- text_offset can be assumed to be 0x80000.
-
-- The flags field (introduced in v3.17) is a little-endian 64-bit field
- composed as follows:
-
- ============= ===============================================================
- Bit 0 Kernel endianness. 1 if BE, 0 if LE.
- Bit 1-2 Kernel Page size.
-
- * 0 - Unspecified.
- * 1 - 4K
- * 2 - 16K
- * 3 - 64K
- Bit 3 Kernel physical placement
-
- 0
- 2MB aligned base should be as close as possible
- to the base of DRAM, since memory below it is not
- accessible via the linear mapping
- 1
- 2MB aligned base such that all image_size bytes
- counted from the start of the image are within
- the 48-bit addressable range of physical memory
- Bits 4-63 Reserved.
- ============= ===============================================================
-
-- When image_size is zero, a bootloader should attempt to keep as much
- memory as possible free for use by the kernel immediately after the
- end of the kernel image. The amount of space required will vary
- depending on selected features, and is effectively unbound.
-
-The Image must be placed text_offset bytes from a 2MB aligned base
-address anywhere in usable system RAM and called there. The region
-between the 2 MB aligned base address and the start of the image has no
-special significance to the kernel, and may be used for other purposes.
-At least image_size bytes from the start of the image must be free for
-use by the kernel.
-NOTE: versions prior to v4.6 cannot make use of memory below the
-physical offset of the Image so it is recommended that the Image be
-placed as close as possible to the start of system RAM.
-
-If an initrd/initramfs is passed to the kernel at boot, it must reside
-entirely within a 1 GB aligned physical memory window of up to 32 GB in
-size that fully covers the kernel Image as well.
-
-Any memory described to the kernel (even that below the start of the
-image) which is not marked as reserved from the kernel (e.g., with a
-memreserve region in the device tree) will be considered as available to
-the kernel.
-
-Before jumping into the kernel, the following conditions must be met:
-
-- Quiesce all DMA capable devices so that memory does not get
- corrupted by bogus network packets or disk data. This will save
- you many hours of debug.
-
-- Primary CPU general-purpose register settings:
-
- - x0 = physical address of device tree blob (dtb) in system RAM.
- - x1 = 0 (reserved for future use)
- - x2 = 0 (reserved for future use)
- - x3 = 0 (reserved for future use)
-
-- CPU mode
-
- All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
- IRQ and FIQ).
- The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order
- to have access to the virtualisation extensions), or in EL1.
-
-- Caches, MMUs
-
- The MMU must be off.
-
- The instruction cache may be on or off, and must not hold any stale
- entries corresponding to the loaded kernel image.
-
- The address range corresponding to the loaded kernel image must be
- cleaned to the PoC. In the presence of a system cache or other
- coherent masters with caches enabled, this will typically require
- cache maintenance by VA rather than set/way operations.
- System caches which respect the architected cache maintenance by VA
- operations must be configured and may be enabled.
- System caches which do not respect architected cache maintenance by VA
- operations (not recommended) must be configured and disabled.
-
-- Architected timers
-
- CNTFRQ must be programmed with the timer frequency and CNTVOFF must
- be programmed with a consistent value on all CPUs. If entering the
- kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where
- available.
-
-- Coherency
-
- All CPUs to be booted by the kernel must be part of the same coherency
- domain on entry to the kernel. This may require IMPLEMENTATION DEFINED
- initialisation to enable the receiving of maintenance operations on
- each CPU.
-
-- System registers
-
- All writable architected system registers at or below the exception
- level where the kernel image will be entered must be initialised by
- software at a higher exception level to prevent execution in an UNKNOWN
- state.
-
- For all systems:
- - If EL3 is present:
-
- - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
- executing on.
- - The value of SCR_EL3.FIQ must be the same as the one present at boot
- time whenever the kernel is executing.
-
- - If EL3 is present and the kernel is entered at EL2:
-
- - SCR_EL3.HCE (bit 8) must be initialised to 0b1.
-
- For systems with a GICv3 interrupt controller to be used in v3 mode:
- - If EL3 is present:
-
- - ICC_SRE_EL3.Enable (bit 3) must be initialised to 0b1.
- - ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
- - ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across
- all CPUs the kernel is executing on, and must stay constant
- for the lifetime of the kernel.
-
- - If the kernel is entered at EL1:
-
- - ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
- - ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
-
- - The DT or ACPI tables must describe a GICv3 interrupt controller.
-
- For systems with a GICv3 interrupt controller to be used in
- compatibility (v2) mode:
-
- - If EL3 is present:
-
- ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0.
-
- - If the kernel is entered at EL1:
-
- ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.
-
- - The DT or ACPI tables must describe a GICv2 interrupt controller.
-
- For CPUs with pointer authentication functionality:
-
- - If EL3 is present:
-
- - SCR_EL3.APK (bit 16) must be initialised to 0b1
- - SCR_EL3.API (bit 17) must be initialised to 0b1
-
- - If the kernel is entered at EL1:
-
- - HCR_EL2.APK (bit 40) must be initialised to 0b1
- - HCR_EL2.API (bit 41) must be initialised to 0b1
-
- For CPUs with Activity Monitors Unit v1 (AMUv1) extension present:
-
- - If EL3 is present:
-
- - CPTR_EL3.TAM (bit 30) must be initialised to 0b0
- - CPTR_EL2.TAM (bit 30) must be initialised to 0b0
- - AMCNTENSET0_EL0 must be initialised to 0b1111
- - AMCNTENSET1_EL0 must be initialised to a platform specific value
- having 0b1 set for the corresponding bit for each of the auxiliary
- counters present.
-
- - If the kernel is entered at EL1:
-
- - AMCNTENSET0_EL0 must be initialised to 0b1111
- - AMCNTENSET1_EL0 must be initialised to a platform specific value
- having 0b1 set for the corresponding bit for each of the auxiliary
- counters present.
-
- For CPUs with the Fine Grained Traps (FEAT_FGT) extension present:
-
- - If EL3 is present and the kernel is entered at EL2:
-
- - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
-
- For CPUs with support for HCRX_EL2 (FEAT_HCX) present:
-
- - If EL3 is present and the kernel is entered at EL2:
-
- - SCR_EL3.HXEn (bit 38) must be initialised to 0b1.
-
- For CPUs with Advanced SIMD and floating point support:
-
- - If EL3 is present:
-
- - CPTR_EL3.TFP (bit 10) must be initialised to 0b0.
-
- - If EL2 is present and the kernel is entered at EL1:
-
- - CPTR_EL2.TFP (bit 10) must be initialised to 0b0.
-
- For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
-
- - if EL3 is present:
-
- - CPTR_EL3.EZ (bit 8) must be initialised to 0b1.
-
- - ZCR_EL3.LEN must be initialised to the same value for all CPUs the
- kernel is executed on.
-
- - If the kernel is entered at EL1 and EL2 is present:
-
- - CPTR_EL2.TZ (bit 8) must be initialised to 0b0.
-
- - CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11.
-
- - ZCR_EL2.LEN must be initialised to the same value for all CPUs the
- kernel will execute on.
-
- For CPUs with the Scalable Matrix Extension (FEAT_SME):
-
- - If EL3 is present:
-
- - CPTR_EL3.ESM (bit 12) must be initialised to 0b1.
-
- - SCR_EL3.EnTP2 (bit 41) must be initialised to 0b1.
-
- - SMCR_EL3.LEN must be initialised to the same value for all CPUs the
- kernel will execute on.
-
- - If the kernel is entered at EL1 and EL2 is present:
-
- - CPTR_EL2.TSM (bit 12) must be initialised to 0b0.
-
- - CPTR_EL2.SMEN (bits 25:24) must be initialised to 0b11.
-
- - SCTLR_EL2.EnTP2 (bit 60) must be initialised to 0b1.
-
- - SMCR_EL2.LEN must be initialised to the same value for all CPUs the
- kernel will execute on.
-
- - HWFGRTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
-
- - HWFGWTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
-
- - HWFGRTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
-
- - HWFGWTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
-
- For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64):
-
- - If EL3 is present:
-
- - SMCR_EL3.FA64 (bit 31) must be initialised to 0b1.
-
- - If the kernel is entered at EL1 and EL2 is present:
-
- - SMCR_EL2.FA64 (bit 31) must be initialised to 0b1.
-
- For CPUs with the Memory Tagging Extension feature (FEAT_MTE2):
-
- - If EL3 is present:
-
- - SCR_EL3.ATA (bit 26) must be initialised to 0b1.
-
- - If the kernel is entered at EL1 and EL2 is present:
-
- - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
-
- For CPUs with the Scalable Matrix Extension version 2 (FEAT_SME2):
-
- - If EL3 is present:
-
- - SMCR_EL3.EZT0 (bit 30) must be initialised to 0b1.
-
- - If the kernel is entered at EL1 and EL2 is present:
-
- - SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1.
-
-The requirements described above for CPU mode, caches, MMUs, architected
-timers, coherency and system registers apply to all CPUs. All CPUs must
-enter the kernel in the same exception level. Where the values documented
-disable traps it is permissible for these traps to be enabled so long as
-those traps are handled transparently by higher exception levels as though
-the values documented were set.
-
-The boot loader is expected to enter the kernel on each CPU in the
-following manner:
-
-- The primary CPU must jump directly to the first instruction of the
- kernel image. The device tree blob passed by this CPU must contain
- an 'enable-method' property for each cpu node. The supported
- enable-methods are described below.
-
- It is expected that the bootloader will generate these device tree
- properties and insert them into the blob prior to kernel entry.
-
-- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr'
- property in their cpu node. This property identifies a
- naturally-aligned 64-bit zero-initalised memory location.
-
- These CPUs should spin outside of the kernel in a reserved area of
- memory (communicated to the kernel by a /memreserve/ region in the
- device tree) polling their cpu-release-addr location, which must be
- contained in the reserved region. A wfe instruction may be inserted
- to reduce the overhead of the busy-loop and a sev will be issued by
- the primary CPU. When a read of the location pointed to by the
- cpu-release-addr returns a non-zero value, the CPU must jump to this
- value. The value will be written as a single 64-bit little-endian
- value, so CPUs must convert the read value to their native endianness
- before jumping to it.
-
-- CPUs with a "psci" enable method should remain outside of
- the kernel (i.e. outside of the regions of memory described to the
- kernel in the memory node, or in a reserved area of memory described
- to the kernel by a /memreserve/ region in the device tree). The
- kernel will issue CPU_ON calls as described in ARM document number ARM
- DEN 0022A ("Power State Coordination Interface System Software on ARM
- processors") to bring CPUs into the kernel.
-
- The device tree should contain a 'psci' node, as described in
- Documentation/devicetree/bindings/arm/psci.yaml.
-
-- Secondary CPU general-purpose register settings
-
- - x0 = 0 (reserved for future use)
- - x1 = 0 (reserved for future use)
- - x2 = 0 (reserved for future use)
- - x3 = 0 (reserved for future use)
diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst
deleted file mode 100644
index c7adc78..0000000
--- a/Documentation/arm64/cpu-feature-registers.rst
+++ /dev/null
@@ -1,400 +0,0 @@
-===========================
-ARM64 CPU Feature Registers
-===========================
-
-Author: Suzuki K Poulose <suzuki.poulose@arm.com>
-
-
-This file describes the ABI for exporting the AArch64 CPU ID/feature
-registers to userspace. The availability of this ABI is advertised
-via the HWCAP_CPUID in HWCAPs.
-
-1. Motivation
--------------
-
-The ARM architecture defines a set of feature registers, which describe
-the capabilities of the CPU/system. Access to these system registers is
-restricted from EL0 and there is no reliable way for an application to
-extract this information to make better decisions at runtime. There is
-limited information available to the application via HWCAPs, however
-there are some issues with their usage.
-
- a) Any change to the HWCAPs requires an update to userspace (e.g libc)
- to detect the new changes, which can take a long time to appear in
- distributions. Exposing the registers allows applications to get the
- information without requiring updates to the toolchains.
-
- b) Access to HWCAPs is sometimes limited (e.g prior to libc, or
- when ld is initialised at startup time).
-
- c) HWCAPs cannot represent non-boolean information effectively. The
- architecture defines a canonical format for representing features
- in the ID registers; this is well defined and is capable of
- representing all valid architecture variations.
-
-
-2. Requirements
----------------
-
- a) Safety:
-
- Applications should be able to use the information provided by the
- infrastructure to run safely across the system. This has greater
- implications on a system with heterogeneous CPUs.
- The infrastructure exports a value that is safe across all the
- available CPU on the system.
-
- e.g, If at least one CPU doesn't implement CRC32 instructions, while
- others do, we should report that the CRC32 is not implemented.
- Otherwise an application could crash when scheduled on the CPU
- which doesn't support CRC32.
-
- b) Security:
-
- Applications should only be able to receive information that is
- relevant to the normal operation in userspace. Hence, some of the
- fields are masked out(i.e, made invisible) and their values are set to
- indicate the feature is 'not supported'. See Section 4 for the list
- of visible features. Also, the kernel may manipulate the fields
- based on what it supports. e.g, If FP is not supported by the
- kernel, the values could indicate that the FP is not available
- (even when the CPU provides it).
-
- c) Implementation Defined Features
-
- The infrastructure doesn't expose any register which is
- IMPLEMENTATION DEFINED as per ARMv8-A Architecture.
-
- d) CPU Identification:
-
- MIDR_EL1 is exposed to help identify the processor. On a
- heterogeneous system, this could be racy (just like getcpu()). The
- process could be migrated to another CPU by the time it uses the
- register value, unless the CPU affinity is set. Hence, there is no
- guarantee that the value reflects the processor that it is
- currently executing on. The REVIDR is not exposed due to this
- constraint, as REVIDR makes sense only in conjunction with the
- MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
- at::
-
- /sys/devices/system/cpu/cpu$ID/regs/identification/
- \- midr
- \- revidr
-
-3. Implementation
---------------------
-
-The infrastructure is built on the emulation of the 'MRS' instruction.
-Accessing a restricted system register from an application generates an
-exception and ends up in SIGILL being delivered to the process.
-The infrastructure hooks into the exception handler and emulates the
-operation if the source belongs to the supported system register space.
-
-The infrastructure emulates only the following system register space::
-
- Op0=3, Op1=0, CRn=0, CRm=0,2,3,4,5,6,7
-
-(See Table C5-6 'System instruction encodings for non-Debug System
-register accesses' in ARMv8 ARM DDI 0487A.h, for the list of
-registers).
-
-The following rules are applied to the value returned by the
-infrastructure:
-
- a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0.
- b) The value of a reserved field is populated with the reserved
- value as defined by the architecture.
- c) The value of a 'visible' field holds the system wide safe value
- for the particular feature (except for MIDR_EL1, see section 4).
- d) All other fields (i.e, invisible fields) are set to indicate
- the feature is missing (as defined by the architecture).
-
-4. List of registers with visible features
--------------------------------------------
-
- 1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | RNDR | [63-60] | y |
- +------------------------------+---------+---------+
- | TS | [55-52] | y |
- +------------------------------+---------+---------+
- | FHM | [51-48] | y |
- +------------------------------+---------+---------+
- | DP | [47-44] | y |
- +------------------------------+---------+---------+
- | SM4 | [43-40] | y |
- +------------------------------+---------+---------+
- | SM3 | [39-36] | y |
- +------------------------------+---------+---------+
- | SHA3 | [35-32] | y |
- +------------------------------+---------+---------+
- | RDM | [31-28] | y |
- +------------------------------+---------+---------+
- | ATOMICS | [23-20] | y |
- +------------------------------+---------+---------+
- | CRC32 | [19-16] | y |
- +------------------------------+---------+---------+
- | SHA2 | [15-12] | y |
- +------------------------------+---------+---------+
- | SHA1 | [11-8] | y |
- +------------------------------+---------+---------+
- | AES | [7-4] | y |
- +------------------------------+---------+---------+
-
-
- 2) ID_AA64PFR0_EL1 - Processor Feature Register 0
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | DIT | [51-48] | y |
- +------------------------------+---------+---------+
- | SVE | [35-32] | y |
- +------------------------------+---------+---------+
- | GIC | [27-24] | n |
- +------------------------------+---------+---------+
- | AdvSIMD | [23-20] | y |
- +------------------------------+---------+---------+
- | FP | [19-16] | y |
- +------------------------------+---------+---------+
- | EL3 | [15-12] | n |
- +------------------------------+---------+---------+
- | EL2 | [11-8] | n |
- +------------------------------+---------+---------+
- | EL1 | [7-4] | n |
- +------------------------------+---------+---------+
- | EL0 | [3-0] | n |
- +------------------------------+---------+---------+
-
-
- 3) ID_AA64PFR1_EL1 - Processor Feature Register 1
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | MTE | [11-8] | y |
- +------------------------------+---------+---------+
- | SSBS | [7-4] | y |
- +------------------------------+---------+---------+
- | BT | [3-0] | y |
- +------------------------------+---------+---------+
-
-
- 4) MIDR_EL1 - Main ID Register
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | Implementer | [31-24] | y |
- +------------------------------+---------+---------+
- | Variant | [23-20] | y |
- +------------------------------+---------+---------+
- | Architecture | [19-16] | y |
- +------------------------------+---------+---------+
- | PartNum | [15-4] | y |
- +------------------------------+---------+---------+
- | Revision | [3-0] | y |
- +------------------------------+---------+---------+
-
- NOTE: The 'visible' fields of MIDR_EL1 will contain the value
- as available on the CPU where it is fetched and is not a system
- wide safe value.
-
- 5) ID_AA64ISAR1_EL1 - Instruction set attribute register 1
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | I8MM | [55-52] | y |
- +------------------------------+---------+---------+
- | DGH | [51-48] | y |
- +------------------------------+---------+---------+
- | BF16 | [47-44] | y |
- +------------------------------+---------+---------+
- | SB | [39-36] | y |
- +------------------------------+---------+---------+
- | FRINTTS | [35-32] | y |
- +------------------------------+---------+---------+
- | GPI | [31-28] | y |
- +------------------------------+---------+---------+
- | GPA | [27-24] | y |
- +------------------------------+---------+---------+
- | LRCPC | [23-20] | y |
- +------------------------------+---------+---------+
- | FCMA | [19-16] | y |
- +------------------------------+---------+---------+
- | JSCVT | [15-12] | y |
- +------------------------------+---------+---------+
- | API | [11-8] | y |
- +------------------------------+---------+---------+
- | APA | [7-4] | y |
- +------------------------------+---------+---------+
- | DPB | [3-0] | y |
- +------------------------------+---------+---------+
-
- 6) ID_AA64MMFR0_EL1 - Memory model feature register 0
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | ECV | [63-60] | y |
- +------------------------------+---------+---------+
-
- 7) ID_AA64MMFR2_EL1 - Memory model feature register 2
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | AT | [35-32] | y |
- +------------------------------+---------+---------+
-
- 8) ID_AA64ZFR0_EL1 - SVE feature ID register 0
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | F64MM | [59-56] | y |
- +------------------------------+---------+---------+
- | F32MM | [55-52] | y |
- +------------------------------+---------+---------+
- | I8MM | [47-44] | y |
- +------------------------------+---------+---------+
- | SM4 | [43-40] | y |
- +------------------------------+---------+---------+
- | SHA3 | [35-32] | y |
- +------------------------------+---------+---------+
- | BF16 | [23-20] | y |
- +------------------------------+---------+---------+
- | BitPerm | [19-16] | y |
- +------------------------------+---------+---------+
- | AES | [7-4] | y |
- +------------------------------+---------+---------+
- | SVEVer | [3-0] | y |
- +------------------------------+---------+---------+
-
- 8) ID_AA64MMFR1_EL1 - Memory model feature register 1
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | AFP | [47-44] | y |
- +------------------------------+---------+---------+
-
- 9) ID_AA64ISAR2_EL1 - Instruction set attribute register 2
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | RPRES | [7-4] | y |
- +------------------------------+---------+---------+
- | WFXT | [3-0] | y |
- +------------------------------+---------+---------+
-
- 10) MVFR0_EL1 - AArch32 Media and VFP Feature Register 0
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | FPDP | [11-8] | y |
- +------------------------------+---------+---------+
-
- 11) MVFR1_EL1 - AArch32 Media and VFP Feature Register 1
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | SIMDFMAC | [31-28] | y |
- +------------------------------+---------+---------+
- | SIMDSP | [19-16] | y |
- +------------------------------+---------+---------+
- | SIMDInt | [15-12] | y |
- +------------------------------+---------+---------+
- | SIMDLS | [11-8] | y |
- +------------------------------+---------+---------+
-
- 12) ID_ISAR5_EL1 - AArch32 Instruction Set Attribute Register 5
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | CRC32 | [19-16] | y |
- +------------------------------+---------+---------+
- | SHA2 | [15-12] | y |
- +------------------------------+---------+---------+
- | SHA1 | [11-8] | y |
- +------------------------------+---------+---------+
- | AES | [7-4] | y |
- +------------------------------+---------+---------+
-
-
-Appendix I: Example
--------------------
-
-::
-
- /*
- * Sample program to demonstrate the MRS emulation ABI.
- *
- * Copyright (C) 2015-2016, ARM Ltd
- *
- * Author: Suzuki K Poulose <suzuki.poulose@arm.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
- #include <asm/hwcap.h>
- #include <stdio.h>
- #include <sys/auxv.h>
-
- #define get_cpu_ftr(id) ({ \
- unsigned long __val; \
- asm("mrs %0, "#id : "=r" (__val)); \
- printf("%-20s: 0x%016lx\n", #id, __val); \
- })
-
- int main(void)
- {
-
- if (!(getauxval(AT_HWCAP) & HWCAP_CPUID)) {
- fputs("CPUID registers unavailable\n", stderr);
- return 1;
- }
-
- get_cpu_ftr(ID_AA64ISAR0_EL1);
- get_cpu_ftr(ID_AA64ISAR1_EL1);
- get_cpu_ftr(ID_AA64MMFR0_EL1);
- get_cpu_ftr(ID_AA64MMFR1_EL1);
- get_cpu_ftr(ID_AA64PFR0_EL1);
- get_cpu_ftr(ID_AA64PFR1_EL1);
- get_cpu_ftr(ID_AA64DFR0_EL1);
- get_cpu_ftr(ID_AA64DFR1_EL1);
-
- get_cpu_ftr(MIDR_EL1);
- get_cpu_ftr(MPIDR_EL1);
- get_cpu_ftr(REVIDR_EL1);
-
- #if 0
- /* Unexposed register access causes SIGILL */
- get_cpu_ftr(ID_MMFR0_EL1);
- #endif
-
- return 0;
- }
diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst
deleted file mode 100644
index 83e57e4d..0000000
--- a/Documentation/arm64/elf_hwcaps.rst
+++ /dev/null
@@ -1,309 +0,0 @@
-.. _elf_hwcaps_index:
-
-================
-ARM64 ELF hwcaps
-================
-
-This document describes the usage and semantics of the arm64 ELF hwcaps.
-
-
-1. Introduction
----------------
-
-Some hardware or software features are only available on some CPU
-implementations, and/or with certain kernel configurations, but have no
-architected discovery mechanism available to userspace code at EL0. The
-kernel exposes the presence of these features to userspace through a set
-of flags called hwcaps, exposed in the auxiliary vector.
-
-Userspace software can test for features by acquiring the AT_HWCAP or
-AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
-flags are set, e.g.::
-
- bool floating_point_is_present(void)
- {
- unsigned long hwcaps = getauxval(AT_HWCAP);
- if (hwcaps & HWCAP_FP)
- return true;
-
- return false;
- }
-
-Where software relies on a feature described by a hwcap, it should check
-the relevant hwcap flag to verify that the feature is present before
-attempting to make use of the feature.
-
-Features cannot be probed reliably through other means. When a feature
-is not available, attempting to use it may result in unpredictable
-behaviour, and is not guaranteed to result in any reliable indication
-that the feature is unavailable, such as a SIGILL.
-
-
-2. Interpretation of hwcaps
----------------------------
-
-The majority of hwcaps are intended to indicate the presence of features
-which are described by architected ID registers inaccessible to
-userspace code at EL0. These hwcaps are defined in terms of ID register
-fields, and should be interpreted with reference to the definition of
-these fields in the ARM Architecture Reference Manual (ARM ARM).
-
-Such hwcaps are described below in the form::
-
- Functionality implied by idreg.field == val.
-
-Such hwcaps indicate the availability of functionality that the ARM ARM
-defines as being present when idreg.field has value val, but do not
-indicate that idreg.field is precisely equal to val, nor do they
-indicate the absence of functionality implied by other values of
-idreg.field.
-
-Other hwcaps may indicate the presence of features which cannot be
-described by ID registers alone. These may be described without
-reference to ID registers, and may refer to other documentation.
-
-
-3. The hwcaps exposed in AT_HWCAP
----------------------------------
-
-HWCAP_FP
- Functionality implied by ID_AA64PFR0_EL1.FP == 0b0000.
-
-HWCAP_ASIMD
- Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0000.
-
-HWCAP_EVTSTRM
- The generic timer is configured to generate events at a frequency of
- approximately 10KHz.
-
-HWCAP_AES
- Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001.
-
-HWCAP_PMULL
- Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0010.
-
-HWCAP_SHA1
- Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001.
-
-HWCAP_SHA2
- Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001.
-
-HWCAP_CRC32
- Functionality implied by ID_AA64ISAR0_EL1.CRC32 == 0b0001.
-
-HWCAP_ATOMICS
- Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0010.
-
-HWCAP_FPHP
- Functionality implied by ID_AA64PFR0_EL1.FP == 0b0001.
-
-HWCAP_ASIMDHP
- Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0001.
-
-HWCAP_CPUID
- EL0 access to certain ID registers is available, to the extent
- described by Documentation/arm64/cpu-feature-registers.rst.
-
- These ID registers may imply the availability of features.
-
-HWCAP_ASIMDRDM
- Functionality implied by ID_AA64ISAR0_EL1.RDM == 0b0001.
-
-HWCAP_JSCVT
- Functionality implied by ID_AA64ISAR1_EL1.JSCVT == 0b0001.
-
-HWCAP_FCMA
- Functionality implied by ID_AA64ISAR1_EL1.FCMA == 0b0001.
-
-HWCAP_LRCPC
- Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0001.
-
-HWCAP_DCPOP
- Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001.
-
-HWCAP_SHA3
- Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
-
-HWCAP_SM3
- Functionality implied by ID_AA64ISAR0_EL1.SM3 == 0b0001.
-
-HWCAP_SM4
- Functionality implied by ID_AA64ISAR0_EL1.SM4 == 0b0001.
-
-HWCAP_ASIMDDP
- Functionality implied by ID_AA64ISAR0_EL1.DP == 0b0001.
-
-HWCAP_SHA512
- Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010.
-
-HWCAP_SVE
- Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
-
-HWCAP_ASIMDFHM
- Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
-
-HWCAP_DIT
- Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001.
-
-HWCAP_USCAT
- Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001.
-
-HWCAP_ILRCPC
- Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0010.
-
-HWCAP_FLAGM
- Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001.
-
-HWCAP_SSBS
- Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010.
-
-HWCAP_SB
- Functionality implied by ID_AA64ISAR1_EL1.SB == 0b0001.
-
-HWCAP_PACA
- Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or
- ID_AA64ISAR1_EL1.API == 0b0001, as described by
- Documentation/arm64/pointer-authentication.rst.
-
-HWCAP_PACG
- Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
- ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
- Documentation/arm64/pointer-authentication.rst.
-
-HWCAP2_DCPODP
- Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
-
-HWCAP2_SVE2
- Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
-
-HWCAP2_SVEAES
- Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
-
-HWCAP2_SVEPMULL
- Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010.
-
-HWCAP2_SVEBITPERM
- Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001.
-
-HWCAP2_SVESHA3
- Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001.
-
-HWCAP2_SVESM4
- Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
-
-HWCAP2_FLAGM2
- Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
-
-HWCAP2_FRINT
- Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
-
-HWCAP2_SVEI8MM
- Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001.
-
-HWCAP2_SVEF32MM
- Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001.
-
-HWCAP2_SVEF64MM
- Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001.
-
-HWCAP2_SVEBF16
- Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001.
-
-HWCAP2_I8MM
- Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
-
-HWCAP2_BF16
- Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0001.
-
-HWCAP2_DGH
- Functionality implied by ID_AA64ISAR1_EL1.DGH == 0b0001.
-
-HWCAP2_RNG
- Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
-
-HWCAP2_BTI
- Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
-
-HWCAP2_MTE
- Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
- by Documentation/arm64/memory-tagging-extension.rst.
-
-HWCAP2_ECV
- Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
-
-HWCAP2_AFP
- Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
-
-HWCAP2_RPRES
- Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
-
-HWCAP2_MTE3
- Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
- by Documentation/arm64/memory-tagging-extension.rst.
-
-HWCAP2_SME
- Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described
- by Documentation/arm64/sme.rst.
-
-HWCAP2_SME_I16I64
- Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111.
-
-HWCAP2_SME_F64F64
- Functionality implied by ID_AA64SMFR0_EL1.F64F64 == 0b1.
-
-HWCAP2_SME_I8I32
- Functionality implied by ID_AA64SMFR0_EL1.I8I32 == 0b1111.
-
-HWCAP2_SME_F16F32
- Functionality implied by ID_AA64SMFR0_EL1.F16F32 == 0b1.
-
-HWCAP2_SME_B16F32
- Functionality implied by ID_AA64SMFR0_EL1.B16F32 == 0b1.
-
-HWCAP2_SME_F32F32
- Functionality implied by ID_AA64SMFR0_EL1.F32F32 == 0b1.
-
-HWCAP2_SME_FA64
- Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1.
-
-HWCAP2_WFXT
- Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
-
-HWCAP2_EBF16
- Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
-
-HWCAP2_SVE_EBF16
- Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0010.
-
-HWCAP2_CSSC
- Functionality implied by ID_AA64ISAR2_EL1.CSSC == 0b0001.
-
-HWCAP2_RPRFM
- Functionality implied by ID_AA64ISAR2_EL1.RPRFM == 0b0001.
-
-HWCAP2_SVE2P1
- Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0010.
-
-HWCAP2_SME2
- Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0001.
-
-HWCAP2_SME2P1
- Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0010.
-
-HWCAP2_SMEI16I32
- Functionality implied by ID_AA64SMFR0_EL1.I16I32 == 0b0101
-
-HWCAP2_SMEBI32I32
- Functionality implied by ID_AA64SMFR0_EL1.BI32I32 == 0b1
-
-HWCAP2_SMEB16B16
- Functionality implied by ID_AA64SMFR0_EL1.B16B16 == 0b1
-
-HWCAP2_SMEF16F16
- Functionality implied by ID_AA64SMFR0_EL1.F16F16 == 0b1
-
-4. Unused AT_HWCAP bits
------------------------
-
-For interoperation with userspace, the kernel guarantees that bits 62
-and 63 of AT_HWCAP will always be returned as 0.
diff --git a/Documentation/arm64/index.rst b/Documentation/arm64/index.rst
deleted file mode 100644
index ae21f81..0000000
--- a/Documentation/arm64/index.rst
+++ /dev/null
@@ -1,36 +0,0 @@
-.. _arm64_index:
-
-==================
-ARM64 Architecture
-==================
-
-.. toctree::
- :maxdepth: 1
-
- acpi_object_usage
- amu
- arm-acpi
- asymmetric-32bit
- booting
- cpu-feature-registers
- elf_hwcaps
- hugetlbpage
- legacy_instructions
- memory
- memory-tagging-extension
- perf
- pointer-authentication
- silicon-errata
- sme
- sve
- tagged-address-abi
- tagged-pointers
-
- features
-
-.. only:: subproject and html
-
- Indices
- =======
-
- * :ref:`genindex`
diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst
deleted file mode 100644
index dbae47b..0000000
--- a/Documentation/arm64/memory-tagging-extension.rst
+++ /dev/null
@@ -1,375 +0,0 @@
-===============================================
-Memory Tagging Extension (MTE) in AArch64 Linux
-===============================================
-
-Authors: Vincenzo Frascino <vincenzo.frascino@arm.com>
- Catalin Marinas <catalin.marinas@arm.com>
-
-Date: 2020-02-25
-
-This document describes the provision of the Memory Tagging Extension
-functionality in AArch64 Linux.
-
-Introduction
-============
-
-ARMv8.5 based processors introduce the Memory Tagging Extension (MTE)
-feature. MTE is built on top of the ARMv8.0 virtual address tagging TBI
-(Top Byte Ignore) feature and allows software to access a 4-bit
-allocation tag for each 16-byte granule in the physical address space.
-Such memory range must be mapped with the Normal-Tagged memory
-attribute. A logical tag is derived from bits 59-56 of the virtual
-address used for the memory access. A CPU with MTE enabled will compare
-the logical tag against the allocation tag and potentially raise an
-exception on mismatch, subject to system registers configuration.
-
-Userspace Support
-=================
-
-When ``CONFIG_ARM64_MTE`` is selected and Memory Tagging Extension is
-supported by the hardware, the kernel advertises the feature to
-userspace via ``HWCAP2_MTE``.
-
-PROT_MTE
---------
-
-To access the allocation tags, a user process must enable the Tagged
-memory attribute on an address range using a new ``prot`` flag for
-``mmap()`` and ``mprotect()``:
-
-``PROT_MTE`` - Pages allow access to the MTE allocation tags.
-
-The allocation tag is set to 0 when such pages are first mapped in the
-user address space and preserved on copy-on-write. ``MAP_SHARED`` is
-supported and the allocation tags can be shared between processes.
-
-**Note**: ``PROT_MTE`` is only supported on ``MAP_ANONYMOUS`` and
-RAM-based file mappings (``tmpfs``, ``memfd``). Passing it to other
-types of mapping will result in ``-EINVAL`` returned by these system
-calls.
-
-**Note**: The ``PROT_MTE`` flag (and corresponding memory type) cannot
-be cleared by ``mprotect()``.
-
-**Note**: ``madvise()`` memory ranges with ``MADV_DONTNEED`` and
-``MADV_FREE`` may have the allocation tags cleared (set to 0) at any
-point after the system call.
-
-Tag Check Faults
-----------------
-
-When ``PROT_MTE`` is enabled on an address range and a mismatch between
-the logical and allocation tags occurs on access, there are three
-configurable behaviours:
-
-- *Ignore* - This is the default mode. The CPU (and kernel) ignores the
- tag check fault.
-
-- *Synchronous* - The kernel raises a ``SIGSEGV`` synchronously, with
- ``.si_code = SEGV_MTESERR`` and ``.si_addr = <fault-address>``. The
- memory access is not performed. If ``SIGSEGV`` is ignored or blocked
- by the offending thread, the containing process is terminated with a
- ``coredump``.
-
-- *Asynchronous* - The kernel raises a ``SIGSEGV``, in the offending
- thread, asynchronously following one or multiple tag check faults,
- with ``.si_code = SEGV_MTEAERR`` and ``.si_addr = 0`` (the faulting
- address is unknown).
-
-- *Asymmetric* - Reads are handled as for synchronous mode while writes
- are handled as for asynchronous mode.
-
-The user can select the above modes, per thread, using the
-``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where ``flags``
-contains any number of the following values in the ``PR_MTE_TCF_MASK``
-bit-field:
-
-- ``PR_MTE_TCF_NONE`` - *Ignore* tag check faults
- (ignored if combined with other options)
-- ``PR_MTE_TCF_SYNC`` - *Synchronous* tag check fault mode
-- ``PR_MTE_TCF_ASYNC`` - *Asynchronous* tag check fault mode
-
-If no modes are specified, tag check faults are ignored. If a single
-mode is specified, the program will run in that mode. If multiple
-modes are specified, the mode is selected as described in the "Per-CPU
-preferred tag checking modes" section below.
-
-The current tag check fault configuration can be read using the
-``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call. If
-multiple modes were requested then all will be reported.
-
-Tag checking can also be disabled for a user thread by setting the
-``PSTATE.TCO`` bit with ``MSR TCO, #1``.
-
-**Note**: Signal handlers are always invoked with ``PSTATE.TCO = 0``,
-irrespective of the interrupted context. ``PSTATE.TCO`` is restored on
-``sigreturn()``.
-
-**Note**: There are no *match-all* logical tags available for user
-applications.
-
-**Note**: Kernel accesses to the user address space (e.g. ``read()``
-system call) are not checked if the user thread tag checking mode is
-``PR_MTE_TCF_NONE`` or ``PR_MTE_TCF_ASYNC``. If the tag checking mode is
-``PR_MTE_TCF_SYNC``, the kernel makes a best effort to check its user
-address accesses, however it cannot always guarantee it. Kernel accesses
-to user addresses are always performed with an effective ``PSTATE.TCO``
-value of zero, regardless of the user configuration.
-
-Excluding Tags in the ``IRG``, ``ADDG`` and ``SUBG`` instructions
------------------------------------------------------------------
-
-The architecture allows excluding certain tags to be randomly generated
-via the ``GCR_EL1.Exclude`` register bit-field. By default, Linux
-excludes all tags other than 0. A user thread can enable specific tags
-in the randomly generated set using the ``prctl(PR_SET_TAGGED_ADDR_CTRL,
-flags, 0, 0, 0)`` system call where ``flags`` contains the tags bitmap
-in the ``PR_MTE_TAG_MASK`` bit-field.
-
-**Note**: The hardware uses an exclude mask but the ``prctl()``
-interface provides an include mask. An include mask of ``0`` (exclusion
-mask ``0xffff``) results in the CPU always generating tag ``0``.
-
-Per-CPU preferred tag checking mode
------------------------------------
-
-On some CPUs the performance of MTE in stricter tag checking modes
-is similar to that of less strict tag checking modes. This makes it
-worthwhile to enable stricter checks on those CPUs when a less strict
-checking mode is requested, in order to gain the error detection
-benefits of the stricter checks without the performance downsides. To
-support this scenario, a privileged user may configure a stricter
-tag checking mode as the CPU's preferred tag checking mode.
-
-The preferred tag checking mode for each CPU is controlled by
-``/sys/devices/system/cpu/cpu<N>/mte_tcf_preferred``, to which a
-privileged user may write the value ``async``, ``sync`` or ``asymm``. The
-default preferred mode for each CPU is ``async``.
-
-To allow a program to potentially run in the CPU's preferred tag
-checking mode, the user program may set multiple tag check fault mode
-bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL,
-flags, 0, 0, 0)`` system call. If both synchronous and asynchronous
-modes are requested then asymmetric mode may also be selected by the
-kernel. If the CPU's preferred tag checking mode is in the task's set
-of provided tag checking modes, that mode will be selected. Otherwise,
-one of the modes in the task's mode will be selected by the kernel
-from the task's mode set using the preference order:
-
- 1. Asynchronous
- 2. Asymmetric
- 3. Synchronous
-
-Note that there is no way for userspace to request multiple modes and
-also disable asymmetric mode.
-
-Initial process state
----------------------
-
-On ``execve()``, the new process has the following configuration:
-
-- ``PR_TAGGED_ADDR_ENABLE`` set to 0 (disabled)
-- No tag checking modes are selected (tag check faults ignored)
-- ``PR_MTE_TAG_MASK`` set to 0 (all tags excluded)
-- ``PSTATE.TCO`` set to 0
-- ``PROT_MTE`` not set on any of the initial memory maps
-
-On ``fork()``, the new process inherits the parent's configuration and
-memory map attributes with the exception of the ``madvise()`` ranges
-with ``MADV_WIPEONFORK`` which will have the data and tags cleared (set
-to 0).
-
-The ``ptrace()`` interface
---------------------------
-
-``PTRACE_PEEKMTETAGS`` and ``PTRACE_POKEMTETAGS`` allow a tracer to read
-the tags from or set the tags to a tracee's address space. The
-``ptrace()`` system call is invoked as ``ptrace(request, pid, addr,
-data)`` where:
-
-- ``request`` - one of ``PTRACE_PEEKMTETAGS`` or ``PTRACE_POKEMTETAGS``.
-- ``pid`` - the tracee's PID.
-- ``addr`` - address in the tracee's address space.
-- ``data`` - pointer to a ``struct iovec`` where ``iov_base`` points to
- a buffer of ``iov_len`` length in the tracer's address space.
-
-The tags in the tracer's ``iov_base`` buffer are represented as one
-4-bit tag per byte and correspond to a 16-byte MTE tag granule in the
-tracee's address space.
-
-**Note**: If ``addr`` is not aligned to a 16-byte granule, the kernel
-will use the corresponding aligned address.
-
-``ptrace()`` return value:
-
-- 0 - tags were copied, the tracer's ``iov_len`` was updated to the
- number of tags transferred. This may be smaller than the requested
- ``iov_len`` if the requested address range in the tracee's or the
- tracer's space cannot be accessed or does not have valid tags.
-- ``-EPERM`` - the specified process cannot be traced.
-- ``-EIO`` - the tracee's address range cannot be accessed (e.g. invalid
- address) and no tags copied. ``iov_len`` not updated.
-- ``-EFAULT`` - fault on accessing the tracer's memory (``struct iovec``
- or ``iov_base`` buffer) and no tags copied. ``iov_len`` not updated.
-- ``-EOPNOTSUPP`` - the tracee's address does not have valid tags (never
- mapped with the ``PROT_MTE`` flag). ``iov_len`` not updated.
-
-**Note**: There are no transient errors for the requests above, so user
-programs should not retry in case of a non-zero system call return.
-
-``PTRACE_GETREGSET`` and ``PTRACE_SETREGSET`` with ``addr ==
-``NT_ARM_TAGGED_ADDR_CTRL`` allow ``ptrace()`` access to the tagged
-address ABI control and MTE configuration of a process as per the
-``prctl()`` options described in
-Documentation/arm64/tagged-address-abi.rst and above. The corresponding
-``regset`` is 1 element of 8 bytes (``sizeof(long))``).
-
-Core dump support
------------------
-
-The allocation tags for user memory mapped with ``PROT_MTE`` are dumped
-in the core file as additional ``PT_AARCH64_MEMTAG_MTE`` segments. The
-program header for such segment is defined as:
-
-:``p_type``: ``PT_AARCH64_MEMTAG_MTE``
-:``p_flags``: 0
-:``p_offset``: segment file offset
-:``p_vaddr``: segment virtual address, same as the corresponding
- ``PT_LOAD`` segment
-:``p_paddr``: 0
-:``p_filesz``: segment size in file, calculated as ``p_mem_sz / 32``
- (two 4-bit tags cover 32 bytes of memory)
-:``p_memsz``: segment size in memory, same as the corresponding
- ``PT_LOAD`` segment
-:``p_align``: 0
-
-The tags are stored in the core file at ``p_offset`` as two 4-bit tags
-in a byte. With the tag granule of 16 bytes, a 4K page requires 128
-bytes in the core file.
-
-Example of correct usage
-========================
-
-*MTE Example code*
-
-.. code-block:: c
-
- /*
- * To be compiled with -march=armv8.5-a+memtag
- */
- #include <errno.h>
- #include <stdint.h>
- #include <stdio.h>
- #include <stdlib.h>
- #include <unistd.h>
- #include <sys/auxv.h>
- #include <sys/mman.h>
- #include <sys/prctl.h>
-
- /*
- * From arch/arm64/include/uapi/asm/hwcap.h
- */
- #define HWCAP2_MTE (1 << 18)
-
- /*
- * From arch/arm64/include/uapi/asm/mman.h
- */
- #define PROT_MTE 0x20
-
- /*
- * From include/uapi/linux/prctl.h
- */
- #define PR_SET_TAGGED_ADDR_CTRL 55
- #define PR_GET_TAGGED_ADDR_CTRL 56
- # define PR_TAGGED_ADDR_ENABLE (1UL << 0)
- # define PR_MTE_TCF_SHIFT 1
- # define PR_MTE_TCF_NONE (0UL << PR_MTE_TCF_SHIFT)
- # define PR_MTE_TCF_SYNC (1UL << PR_MTE_TCF_SHIFT)
- # define PR_MTE_TCF_ASYNC (2UL << PR_MTE_TCF_SHIFT)
- # define PR_MTE_TCF_MASK (3UL << PR_MTE_TCF_SHIFT)
- # define PR_MTE_TAG_SHIFT 3
- # define PR_MTE_TAG_MASK (0xffffUL << PR_MTE_TAG_SHIFT)
-
- /*
- * Insert a random logical tag into the given pointer.
- */
- #define insert_random_tag(ptr) ({ \
- uint64_t __val; \
- asm("irg %0, %1" : "=r" (__val) : "r" (ptr)); \
- __val; \
- })
-
- /*
- * Set the allocation tag on the destination address.
- */
- #define set_tag(tagged_addr) do { \
- asm volatile("stg %0, [%0]" : : "r" (tagged_addr) : "memory"); \
- } while (0)
-
- int main()
- {
- unsigned char *a;
- unsigned long page_sz = sysconf(_SC_PAGESIZE);
- unsigned long hwcap2 = getauxval(AT_HWCAP2);
-
- /* check if MTE is present */
- if (!(hwcap2 & HWCAP2_MTE))
- return EXIT_FAILURE;
-
- /*
- * Enable the tagged address ABI, synchronous or asynchronous MTE
- * tag check faults (based on per-CPU preference) and allow all
- * non-zero tags in the randomly generated set.
- */
- if (prctl(PR_SET_TAGGED_ADDR_CTRL,
- PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC |
- (0xfffe << PR_MTE_TAG_SHIFT),
- 0, 0, 0)) {
- perror("prctl() failed");
- return EXIT_FAILURE;
- }
-
- a = mmap(0, page_sz, PROT_READ | PROT_WRITE,
- MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
- if (a == MAP_FAILED) {
- perror("mmap() failed");
- return EXIT_FAILURE;
- }
-
- /*
- * Enable MTE on the above anonymous mmap. The flag could be passed
- * directly to mmap() and skip this step.
- */
- if (mprotect(a, page_sz, PROT_READ | PROT_WRITE | PROT_MTE)) {
- perror("mprotect() failed");
- return EXIT_FAILURE;
- }
-
- /* access with the default tag (0) */
- a[0] = 1;
- a[1] = 2;
-
- printf("a[0] = %hhu a[1] = %hhu\n", a[0], a[1]);
-
- /* set the logical and allocation tags */
- a = (unsigned char *)insert_random_tag(a);
- set_tag(a);
-
- printf("%p\n", a);
-
- /* non-zero tag access */
- a[0] = 3;
- printf("a[0] = %hhu a[1] = %hhu\n", a[0], a[1]);
-
- /*
- * If MTE is enabled correctly the next instruction will generate an
- * exception.
- */
- printf("Expecting SIGSEGV...\n");
- a[16] = 0xdd;
-
- /* this should not be printed in the PR_MTE_TCF_SYNC mode */
- printf("...haven't got one\n");
-
- return EXIT_FAILURE;
- }
diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
deleted file mode 100644
index 2a641ba..0000000
--- a/Documentation/arm64/memory.rst
+++ /dev/null
@@ -1,167 +0,0 @@
-==============================
-Memory Layout on AArch64 Linux
-==============================
-
-Author: Catalin Marinas <catalin.marinas@arm.com>
-
-This document describes the virtual memory layout used by the AArch64
-Linux kernel. The architecture allows up to 4 levels of translation
-tables with a 4KB page size and up to 3 levels with a 64KB page size.
-
-AArch64 Linux uses either 3 levels or 4 levels of translation tables
-with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
-(256TB) virtual addresses, respectively, for both user and kernel. With
-64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
-virtual address, are used but the memory layout is the same.
-
-ARMv8.2 adds optional support for Large Virtual Address space. This is
-only available when running with a 64KB page size and expands the
-number of descriptors in the first level of translation.
-
-User addresses have bits 63:48 set to 0 while the kernel addresses have
-the same bits set to 1. TTBRx selection is given by bit 63 of the
-virtual address. The swapper_pg_dir contains only kernel (global)
-mappings while the user pgd contains only user (non-global) mappings.
-The swapper_pg_dir address is written to TTBR1 and never written to
-TTBR0.
-
-
-AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
-
- Start End Size Use
- -----------------------------------------------------------------------
- 0000000000000000 0000ffffffffffff 256TB user
- ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
- [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region]
- ffff800000000000 ffff800007ffffff 128MB modules
- ffff800008000000 fffffbffefffffff 124TB vmalloc
- fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
- fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
- fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
- fffffbffff800000 fffffbffffffffff 8MB [guard region]
- fffffc0000000000 fffffdffffffffff 2TB vmemmap
- fffffe0000000000 ffffffffffffffff 2TB [guard region]
-
-
-AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
-
- Start End Size Use
- -----------------------------------------------------------------------
- 0000000000000000 000fffffffffffff 4PB user
- fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map
- [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region]
- ffff800000000000 ffff800007ffffff 128MB modules
- ffff800008000000 fffffbffefffffff 124TB vmalloc
- fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
- fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
- fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
- fffffbffff800000 fffffbffffffffff 8MB [guard region]
- fffffc0000000000 ffffffdfffffffff ~4TB vmemmap
- ffffffe000000000 ffffffffffffffff 128GB [guard region]
-
-
-Translation table lookup with 4KB pages::
-
- +--------+--------+--------+--------+--------+--------+--------+--------+
- |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
- +--------+--------+--------+--------+--------+--------+--------+--------+
- | | | | | |
- | | | | | v
- | | | | | [11:0] in-page offset
- | | | | +-> [20:12] L3 index
- | | | +-----------> [29:21] L2 index
- | | +---------------------> [38:30] L1 index
- | +-------------------------------> [47:39] L0 index
- +-------------------------------------------------> [63] TTBR0/1
-
-
-Translation table lookup with 64KB pages::
-
- +--------+--------+--------+--------+--------+--------+--------+--------+
- |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
- +--------+--------+--------+--------+--------+--------+--------+--------+
- | | | | |
- | | | | v
- | | | | [15:0] in-page offset
- | | | +----------> [28:16] L3 index
- | | +--------------------------> [41:29] L2 index
- | +-------------------------------> [47:42] L1 index (48-bit)
- | [51:42] L1 index (52-bit)
- +-------------------------------------------------> [63] TTBR0/1
-
-
-When using KVM without the Virtualization Host Extensions, the
-hypervisor maps kernel pages in EL2 at a fixed (and potentially
-random) offset from the linear mapping. See the kern_hyp_va macro and
-kvm_update_va_mask function for more details. MMIO devices such as
-GICv2 gets mapped next to the HYP idmap page, as do vectors when
-ARM64_SPECTRE_V3A is enabled for particular CPUs.
-
-When using KVM with the Virtualization Host Extensions, no additional
-mappings are created, since the host kernel runs directly in EL2.
-
-52-bit VA support in the kernel
--------------------------------
-If the ARMv8.2-LVA optional feature is present, and we are running
-with a 64KB page size; then it is possible to use 52-bits of address
-space for both userspace and kernel addresses. However, any kernel
-binary that supports 52-bit must also be able to fall back to 48-bit
-at early boot time if the hardware feature is not present.
-
-This fallback mechanism necessitates the kernel .text to be in the
-higher addresses such that they are invariant to 48/52-bit VAs. Due
-to the kasan shadow being a fraction of the entire kernel VA space,
-the end of the kasan shadow must also be in the higher half of the
-kernel VA space for both 48/52-bit. (Switching from 48-bit to 52-bit,
-the end of the kasan shadow is invariant and dependent on ~0UL,
-whilst the start address will "grow" towards the lower addresses).
-
-In order to optimise phys_to_virt and virt_to_phys, the PAGE_OFFSET
-is kept constant at 0xFFF0000000000000 (corresponding to 52-bit),
-this obviates the need for an extra variable read. The physvirt
-offset and vmemmap offsets are computed at early boot to enable
-this logic.
-
-As a single binary will need to support both 48-bit and 52-bit VA
-spaces, the VMEMMAP must be sized large enough for 52-bit VAs and
-also must be sized large enough to accommodate a fixed PAGE_OFFSET.
-
-Most code in the kernel should not need to consider the VA_BITS, for
-code that does need to know the VA size the variables are
-defined as follows:
-
-VA_BITS constant the *maximum* VA space size
-
-VA_BITS_MIN constant the *minimum* VA space size
-
-vabits_actual variable the *actual* VA space size
-
-
-Maximum and minimum sizes can be useful to ensure that buffers are
-sized large enough or that addresses are positioned close enough for
-the "worst" case.
-
-52-bit userspace VAs
---------------------
-To maintain compatibility with software that relies on the ARMv8.0
-VA space maximum size of 48-bits, the kernel will, by default,
-return virtual addresses to userspace from a 48-bit range.
-
-Software can "opt-in" to receiving VAs from a 52-bit space by
-specifying an mmap hint parameter that is larger than 48-bit.
-
-For example:
-
-.. code-block:: c
-
- maybe_high_address = mmap(~0UL, size, prot, flags,...);
-
-It is also possible to build a debug kernel that returns addresses
-from a 52-bit space by enabling the following kernel config options:
-
-.. code-block:: sh
-
- CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y
-
-Note that this option is only intended for debugging applications
-and should not be used in production.
diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
deleted file mode 100644
index 9e311bc4..0000000
--- a/Documentation/arm64/silicon-errata.rst
+++ /dev/null
@@ -1,216 +0,0 @@
-=======================================
-Silicon Errata and Software Workarounds
-=======================================
-
-Author: Will Deacon <will.deacon@arm.com>
-
-Date : 27 November 2015
-
-It is an unfortunate fact of life that hardware is often produced with
-so-called "errata", which can cause it to deviate from the architecture
-under specific circumstances. For hardware produced by ARM, these
-errata are broadly classified into the following categories:
-
- ========== ========================================================
- Category A A critical error without a viable workaround.
- Category B A significant or critical error with an acceptable
- workaround.
- Category C A minor error that is not expected to occur under normal
- operation.
- ========== ========================================================
-
-For more information, consult one of the "Software Developers Errata
-Notice" documents available on infocenter.arm.com (registration
-required).
-
-As far as Linux is concerned, Category B errata may require some special
-treatment in the operating system. For example, avoiding a particular
-sequence of code, or configuring the processor in a particular way. A
-less common situation may require similar actions in order to declassify
-a Category A erratum into a Category C erratum. These are collectively
-known as "software workarounds" and are only required in the minority of
-cases (e.g. those cases that both require a non-secure workaround *and*
-can be triggered by Linux).
-
-For software workarounds that may adversely impact systems unaffected by
-the erratum in question, a Kconfig entry is added under "Kernel
-Features" -> "ARM errata workarounds via the alternatives framework".
-These are enabled by default and patched in at runtime when an affected
-CPU is detected. For less-intrusive workarounds, a Kconfig option is not
-available and the code is structured (preferably with a comment) in such
-a way that the erratum will not be hit.
-
-This approach can make it slightly onerous to determine exactly which
-errata are worked around in an arbitrary kernel source tree, so this
-file acts as a registry of software workarounds in the Linux Kernel and
-will be updated when new workarounds are committed and backported to
-stable kernels.
-
-+----------------+-----------------+-----------------+-----------------------------+
-| Implementor | Component | Erratum ID | Kconfig |
-+================+=================+=================+=============================+
-| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A55 | #1530923 | ARM64_ERRATUM_1530923 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A55 | #2441007 | ARM64_ERRATUM_2441007 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #852523 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #1319537 | ARM64_ERRATUM_1319367 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #1742098 | ARM64_ERRATUM_1742098 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A72 | #853709 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A72 | #1319367 | ARM64_ERRATUM_1319367 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A72 | #1655431 | ARM64_ERRATUM_1742098 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N1 | #1349291 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | MMU-500 | #841119,826419 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX GICv3 | #38539 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX SMMUv2 | #27704 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX2 SMMUv3| #74 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX2 SMMUv3| #126 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Marvell | ARM-MMU-500 | #582743 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
-+----------------+-----------------+-----------------+-----------------------------+
-| NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip0{6,7} | #161010701 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip0{6,7} | #161010803 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo/Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1463225 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1418040 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1530923 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1024718 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 |
-+----------------+-----------------+-----------------+-----------------------------+
-
-+----------------+-----------------+-----------------+-----------------------------+
-| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
-+----------------+-----------------+-----------------+-----------------------------+
diff --git a/Documentation/arm64/sme.rst b/Documentation/arm64/sme.rst
deleted file mode 100644
index 1c43ea1..0000000
--- a/Documentation/arm64/sme.rst
+++ /dev/null
@@ -1,468 +0,0 @@
-===================================================
-Scalable Matrix Extension support for AArch64 Linux
-===================================================
-
-This document outlines briefly the interface provided to userspace by Linux in
-order to support use of the ARM Scalable Matrix Extension (SME).
-
-This is an outline of the most important features and issues only and not
-intended to be exhaustive. It should be read in conjunction with the SVE
-documentation in sve.rst which provides details on the Streaming SVE mode
-included in SME.
-
-This document does not aim to describe the SME architecture or programmer's
-model. To aid understanding, a minimal description of relevant programmer's
-model features for SME is included in Appendix A.
-
-
-1. General
------------
-
-* PSTATE.SM, PSTATE.ZA, the streaming mode vector length, the ZA and (when
- present) ZTn register state and TPIDR2_EL0 are tracked per thread.
-
-* The presence of SME is reported to userspace via HWCAP2_SME in the aux vector
- AT_HWCAP2 entry. Presence of this flag implies the presence of the SME
- instructions and registers, and the Linux-specific system interfaces
- described in this document. SME is reported in /proc/cpuinfo as "sme".
-
-* The presence of SME2 is reported to userspace via HWCAP2_SME2 in the
- aux vector AT_HWCAP2 entry. Presence of this flag implies the presence of
- the SME2 instructions and ZT0, and the Linux-specific system interfaces
- described in this document. SME2 is reported in /proc/cpuinfo as "sme2".
-
-* Support for the execution of SME instructions in userspace can also be
- detected by reading the CPU ID register ID_AA64PFR1_EL1 using an MRS
- instruction, and checking that the value of the SME field is nonzero. [3]
-
- It does not guarantee the presence of the system interfaces described in the
- following sections: software that needs to verify that those interfaces are
- present must check for HWCAP2_SME instead.
-
-* There are a number of optional SME features, presence of these is reported
- through AT_HWCAP2 through:
-
- HWCAP2_SME_I16I64
- HWCAP2_SME_F64F64
- HWCAP2_SME_I8I32
- HWCAP2_SME_F16F32
- HWCAP2_SME_B16F32
- HWCAP2_SME_F32F32
- HWCAP2_SME_FA64
- HWCAP2_SME2
-
- This list may be extended over time as the SME architecture evolves.
-
- These extensions are also reported via the CPU ID register ID_AA64SMFR0_EL1,
- which userspace can read using an MRS instruction. See elf_hwcaps.txt and
- cpu-feature-registers.txt for details.
-
-* Debuggers should restrict themselves to interacting with the target via the
- NT_ARM_SVE, NT_ARM_SSVE, NT_ARM_ZA and NT_ARM_ZT regsets. The recommended
- way of detecting support for these regsets is to connect to a target process
- first and then attempt a
-
- ptrace(PTRACE_GETREGSET, pid, NT_ARM_<regset>, &iov).
-
-* Whenever ZA register values are exchanged in memory between userspace and
- the kernel, the register value is encoded in memory as a series of horizontal
- vectors from 0 to VL/8-1 stored in the same endianness invariant format as is
- used for SVE vectors.
-
-* On thread creation TPIDR2_EL0 is preserved unless CLONE_SETTLS is specified,
- in which case it is set to 0.
-
-2. Vector lengths
-------------------
-
-SME defines a second vector length similar to the SVE vector length which is
-controls the size of the streaming mode SVE vectors and the ZA matrix array.
-The ZA matrix is square with each side having as many bytes as a streaming
-mode SVE vector.
-
-
-3. Sharing of streaming and non-streaming mode SVE state
----------------------------------------------------------
-
-It is implementation defined which if any parts of the SVE state are shared
-between streaming and non-streaming modes. When switching between modes
-via software interfaces such as ptrace if no register content is provided as
-part of switching no state will be assumed to be shared and everything will
-be zeroed.
-
-
-4. System call behaviour
--------------------------
-
-* On syscall PSTATE.ZA is preserved, if PSTATE.ZA==1 then the contents of the
- ZA matrix and ZTn (if present) are preserved.
-
-* On syscall PSTATE.SM will be cleared and the SVE registers will be handled
- as per the standard SVE ABI.
-
-* None of the SVE registers, ZA or ZTn are used to pass arguments to
- or receive results from any syscall.
-
-* On process creation (eg, clone()) the newly created process will have
- PSTATE.SM cleared.
-
-* All other SME state of a thread, including the currently configured vector
- length, the state of the PR_SME_VL_INHERIT flag, and the deferred vector
- length (if any), is preserved across all syscalls, subject to the specific
- exceptions for execve() described in section 6.
-
-
-5. Signal handling
--------------------
-
-* Signal handlers are invoked with streaming mode and ZA disabled.
-
-* A new signal frame record TPIDR2_MAGIC is added formatted as a struct
- tpidr2_context to allow access to TPIDR2_EL0 from signal handlers.
-
-* A new signal frame record za_context encodes the ZA register contents on
- signal delivery. [1]
-
-* The signal frame record for ZA always contains basic metadata, in particular
- the thread's vector length (in za_context.vl).
-
-* The ZA matrix may or may not be included in the record, depending on
- the value of PSTATE.ZA. The registers are present if and only if:
- za_context.head.size >= ZA_SIG_CONTEXT_SIZE(sve_vq_from_vl(za_context.vl))
- in which case PSTATE.ZA == 1.
-
-* If matrix data is present, the remainder of the record has a vl-dependent
- size and layout. Macros ZA_SIG_* are defined [1] to facilitate access to
- them.
-
-* The matrix is stored as a series of horizontal vectors in the same format as
- is used for SVE vectors.
-
-* If the ZA context is too big to fit in sigcontext.__reserved[], then extra
- space is allocated on the stack, an extra_context record is written in
- __reserved[] referencing this space. za_context is then written in the
- extra space. Refer to [1] for further details about this mechanism.
-
-* If ZTn is supported and PSTATE.ZA==1 then a signal frame record for ZTn will
- be generated.
-
-* The signal record for ZTn has magic ZT_MAGIC (0x5a544e01) and consists of a
- standard signal frame header followed by a struct zt_context specifying
- the number of ZTn registers supported by the system, then zt_context.nregs
- blocks of 64 bytes of data per register.
-
-
-5. Signal return
------------------
-
-When returning from a signal handler:
-
-* If there is no za_context record in the signal frame, or if the record is
- present but contains no register data as described in the previous section,
- then ZA is disabled.
-
-* If za_context is present in the signal frame and contains matrix data then
- PSTATE.ZA is set to 1 and ZA is populated with the specified data.
-
-* The vector length cannot be changed via signal return. If za_context.vl in
- the signal frame does not match the current vector length, the signal return
- attempt is treated as illegal, resulting in a forced SIGSEGV.
-
-* If ZTn is not supported or PSTATE.ZA==0 then it is illegal to have a
- signal frame record for ZTn, resulting in a forced SIGSEGV.
-
-
-6. prctl extensions
---------------------
-
-Some new prctl() calls are added to allow programs to manage the SME vector
-length:
-
-prctl(PR_SME_SET_VL, unsigned long arg)
-
- Sets the vector length of the calling thread and related flags, where
- arg == vl | flags. Other threads of the calling process are unaffected.
-
- vl is the desired vector length, where sve_vl_valid(vl) must be true.
-
- flags:
-
- PR_SME_VL_INHERIT
-
- Inherit the current vector length across execve(). Otherwise, the
- vector length is reset to the system default at execve(). (See
- Section 9.)
-
- PR_SME_SET_VL_ONEXEC
-
- Defer the requested vector length change until the next execve()
- performed by this thread.
-
- The effect is equivalent to implicit execution of the following
- call immediately after the next execve() (if any) by the thread:
-
- prctl(PR_SME_SET_VL, arg & ~PR_SME_SET_VL_ONEXEC)
-
- This allows launching of a new program with a different vector
- length, while avoiding runtime side effects in the caller.
-
- Without PR_SME_SET_VL_ONEXEC, the requested change takes effect
- immediately.
-
-
- Return value: a nonnegative on success, or a negative value on error:
- EINVAL: SME not supported, invalid vector length requested, or
- invalid flags.
-
-
- On success:
-
- * Either the calling thread's vector length or the deferred vector length
- to be applied at the next execve() by the thread (dependent on whether
- PR_SME_SET_VL_ONEXEC is present in arg), is set to the largest value
- supported by the system that is less than or equal to vl. If vl ==
- SVE_VL_MAX, the value set will be the largest value supported by the
- system.
-
- * Any previously outstanding deferred vector length change in the calling
- thread is cancelled.
-
- * The returned value describes the resulting configuration, encoded as for
- PR_SME_GET_VL. The vector length reported in this value is the new
- current vector length for this thread if PR_SME_SET_VL_ONEXEC was not
- present in arg; otherwise, the reported vector length is the deferred
- vector length that will be applied at the next execve() by the calling
- thread.
-
- * Changing the vector length causes all of ZA, ZTn, P0..P15, FFR and all
- bits of Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
- unspecified, including both streaming and non-streaming SVE state.
- Calling PR_SME_SET_VL with vl equal to the thread's current vector
- length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag,
- does not constitute a change to the vector length for this purpose.
-
- * Changing the vector length causes PSTATE.ZA and PSTATE.SM to be cleared.
- Calling PR_SME_SET_VL with vl equal to the thread's current vector
- length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag,
- does not constitute a change to the vector length for this purpose.
-
-
-prctl(PR_SME_GET_VL)
-
- Gets the vector length of the calling thread.
-
- The following flag may be OR-ed into the result:
-
- PR_SME_VL_INHERIT
-
- Vector length will be inherited across execve().
-
- There is no way to determine whether there is an outstanding deferred
- vector length change (which would only normally be the case between a
- fork() or vfork() and the corresponding execve() in typical use).
-
- To extract the vector length from the result, bitwise and it with
- PR_SME_VL_LEN_MASK.
-
- Return value: a nonnegative value on success, or a negative value on error:
- EINVAL: SME not supported.
-
-
-7. ptrace extensions
----------------------
-
-* A new regset NT_ARM_SSVE is defined for access to streaming mode SVE
- state via PTRACE_GETREGSET and PTRACE_SETREGSET, this is documented in
- sve.rst.
-
-* A new regset NT_ARM_ZA is defined for ZA state for access to ZA state via
- PTRACE_GETREGSET and PTRACE_SETREGSET.
-
- Refer to [2] for definitions.
-
-The regset data starts with struct user_za_header, containing:
-
- size
-
- Size of the complete regset, in bytes.
- This depends on vl and possibly on other things in the future.
-
- If a call to PTRACE_GETREGSET requests less data than the value of
- size, the caller can allocate a larger buffer and retry in order to
- read the complete regset.
-
- max_size
-
- Maximum size in bytes that the regset can grow to for the target
- thread. The regset won't grow bigger than this even if the target
- thread changes its vector length etc.
-
- vl
-
- Target thread's current streaming vector length, in bytes.
-
- max_vl
-
- Maximum possible streaming vector length for the target thread.
-
- flags
-
- Zero or more of the following flags, which have the same
- meaning and behaviour as the corresponding PR_SET_VL_* flags:
-
- SME_PT_VL_INHERIT
-
- SME_PT_VL_ONEXEC (SETREGSET only).
-
-* The effects of changing the vector length and/or flags are equivalent to
- those documented for PR_SME_SET_VL.
-
- The caller must make a further GETREGSET call if it needs to know what VL is
- actually set by SETREGSET, unless is it known in advance that the requested
- VL is supported.
-
-* The size and layout of the payload depends on the header fields. The
- SME_PT_ZA_*() macros are provided to facilitate access to the data.
-
-* In either case, for SETREGSET it is permissible to omit the payload, in which
- case the vector length and flags are changed and PSTATE.ZA is set to 0
- (along with any consequences of those changes). If a payload is provided
- then PSTATE.ZA will be set to 1.
-
-* For SETREGSET, if the requested VL is not supported, the effect will be the
- same as if the payload were omitted, except that an EIO error is reported.
- No attempt is made to translate the payload data to the correct layout
- for the vector length actually set. It is up to the caller to translate the
- payload layout for the actual VL and retry.
-
-* The effect of writing a partial, incomplete payload is unspecified.
-
-* A new regset NT_ARM_ZT is defined for access to ZTn state via
- PTRACE_GETREGSET and PTRACE_SETREGSET.
-
-* The NT_ARM_ZT regset consists of a single 512 bit register.
-
-* When PSTATE.ZA==0 reads of NT_ARM_ZT will report all bits of ZTn as 0.
-
-* Writes to NT_ARM_ZT will set PSTATE.ZA to 1.
-
-
-8. ELF coredump extensions
----------------------------
-
-* NT_ARM_SSVE notes will be added to each coredump for
- each thread of the dumped process. The contents will be equivalent to the
- data that would have been read if a PTRACE_GETREGSET of the corresponding
- type were executed for each thread when the coredump was generated.
-
-* A NT_ARM_ZA note will be added to each coredump for each thread of the
- dumped process. The contents will be equivalent to the data that would have
- been read if a PTRACE_GETREGSET of NT_ARM_ZA were executed for each thread
- when the coredump was generated.
-
-* A NT_ARM_ZT note will be added to each coredump for each thread of the
- dumped process. The contents will be equivalent to the data that would have
- been read if a PTRACE_GETREGSET of NT_ARM_ZT were executed for each thread
- when the coredump was generated.
-
-* The NT_ARM_TLS note will be extended to two registers, the second register
- will contain TPIDR2_EL0 on systems that support SME and will be read as
- zero with writes ignored otherwise.
-
-9. System runtime configuration
---------------------------------
-
-* To mitigate the ABI impact of expansion of the signal frame, a policy
- mechanism is provided for administrators, distro maintainers and developers
- to set the default vector length for userspace processes:
-
-/proc/sys/abi/sme_default_vector_length
-
- Writing the text representation of an integer to this file sets the system
- default vector length to the specified value, unless the value is greater
- than the maximum vector length supported by the system in which case the
- default vector length is set to that maximum.
-
- The result can be determined by reopening the file and reading its
- contents.
-
- At boot, the default vector length is initially set to 32 or the maximum
- supported vector length, whichever is smaller and supported. This
- determines the initial vector length of the init process (PID 1).
-
- Reading this file returns the current system default vector length.
-
-* At every execve() call, the new vector length of the new process is set to
- the system default vector length, unless
-
- * PR_SME_VL_INHERIT (or equivalently SME_PT_VL_INHERIT) is set for the
- calling thread, or
-
- * a deferred vector length change is pending, established via the
- PR_SME_SET_VL_ONEXEC flag (or SME_PT_VL_ONEXEC).
-
-* Modifying the system default vector length does not affect the vector length
- of any existing process or thread that does not make an execve() call.
-
-
-Appendix A. SME programmer's model (informative)
-=================================================
-
-This section provides a minimal description of the additions made by SME to the
-ARMv8-A programmer's model that are relevant to this document.
-
-Note: This section is for information only and not intended to be complete or
-to replace any architectural specification.
-
-A.1. Registers
----------------
-
-In A64 state, SME adds the following:
-
-* A new mode, streaming mode, in which a subset of the normal FPSIMD and SVE
- features are available. When supported EL0 software may enter and leave
- streaming mode at any time.
-
- For best system performance it is strongly encouraged for software to enable
- streaming mode only when it is actively being used.
-
-* A new vector length controlling the size of ZA and the Z registers when in
- streaming mode, separately to the vector length used for SVE when not in
- streaming mode. There is no requirement that either the currently selected
- vector length or the set of vector lengths supported for the two modes in
- a given system have any relationship. The streaming mode vector length
- is referred to as SVL.
-
-* A new ZA matrix register. This is a square matrix of SVLxSVL bits. Most
- operations on ZA require that streaming mode be enabled but ZA can be
- enabled without streaming mode in order to load, save and retain data.
-
- For best system performance it is strongly encouraged for software to enable
- ZA only when it is actively being used.
-
-* A new ZT0 register is introduced when SME2 is present. This is a 512 bit
- register which is accessible when PSTATE.ZA is set, as ZA itself is.
-
-* Two new 1 bit fields in PSTATE which may be controlled via the SMSTART and
- SMSTOP instructions or by access to the SVCR system register:
-
- * PSTATE.ZA, if this is 1 then the ZA matrix is accessible and has valid
- data while if it is 0 then ZA can not be accessed. When PSTATE.ZA is
- changed from 0 to 1 all bits in ZA are cleared.
-
- * PSTATE.SM, if this is 1 then the PE is in streaming mode. When the value
- of PSTATE.SM is changed then it is implementation defined if the subset
- of the floating point register bits valid in both modes may be retained.
- Any other bits will be cleared.
-
-
-References
-==========
-
-[1] arch/arm64/include/uapi/asm/sigcontext.h
- AArch64 Linux signal ABI definitions
-
-[2] arch/arm64/include/uapi/asm/ptrace.h
- AArch64 Linux ptrace ABI definitions
-
-[3] Documentation/arm64/cpu-feature-registers.rst
diff --git a/Documentation/arm64/sve.rst b/Documentation/arm64/sve.rst
deleted file mode 100644
index 1b90a30..0000000
--- a/Documentation/arm64/sve.rst
+++ /dev/null
@@ -1,616 +0,0 @@
-===================================================
-Scalable Vector Extension support for AArch64 Linux
-===================================================
-
-Author: Dave Martin <Dave.Martin@arm.com>
-
-Date: 4 August 2017
-
-This document outlines briefly the interface provided to userspace by Linux in
-order to support use of the ARM Scalable Vector Extension (SVE), including
-interactions with Streaming SVE mode added by the Scalable Matrix Extension
-(SME).
-
-This is an outline of the most important features and issues only and not
-intended to be exhaustive.
-
-This document does not aim to describe the SVE architecture or programmer's
-model. To aid understanding, a minimal description of relevant programmer's
-model features for SVE is included in Appendix A.
-
-
-1. General
------------
-
-* SVE registers Z0..Z31, P0..P15 and FFR and the current vector length VL, are
- tracked per-thread.
-
-* In streaming mode FFR is not accessible unless HWCAP2_SME_FA64 is present
- in the system, when it is not supported and these interfaces are used to
- access streaming mode FFR is read and written as zero.
-
-* The presence of SVE is reported to userspace via HWCAP_SVE in the aux vector
- AT_HWCAP entry. Presence of this flag implies the presence of the SVE
- instructions and registers, and the Linux-specific system interfaces
- described in this document. SVE is reported in /proc/cpuinfo as "sve".
-
-* Support for the execution of SVE instructions in userspace can also be
- detected by reading the CPU ID register ID_AA64PFR0_EL1 using an MRS
- instruction, and checking that the value of the SVE field is nonzero. [3]
-
- It does not guarantee the presence of the system interfaces described in the
- following sections: software that needs to verify that those interfaces are
- present must check for HWCAP_SVE instead.
-
-* On hardware that supports the SVE2 extensions, HWCAP2_SVE2 will also
- be reported in the AT_HWCAP2 aux vector entry. In addition to this,
- optional extensions to SVE2 may be reported by the presence of:
-
- HWCAP2_SVE2
- HWCAP2_SVEAES
- HWCAP2_SVEPMULL
- HWCAP2_SVEBITPERM
- HWCAP2_SVESHA3
- HWCAP2_SVESM4
- HWCAP2_SVE2P1
-
- This list may be extended over time as the SVE architecture evolves.
-
- These extensions are also reported via the CPU ID register ID_AA64ZFR0_EL1,
- which userspace can read using an MRS instruction. See elf_hwcaps.txt and
- cpu-feature-registers.txt for details.
-
-* On hardware that supports the SME extensions, HWCAP2_SME will also be
- reported in the AT_HWCAP2 aux vector entry. Among other things SME adds
- streaming mode which provides a subset of the SVE feature set using a
- separate SME vector length and the same Z/V registers. See sme.rst
- for more details.
-
-* Debuggers should restrict themselves to interacting with the target via the
- NT_ARM_SVE regset. The recommended way of detecting support for this regset
- is to connect to a target process first and then attempt a
- ptrace(PTRACE_GETREGSET, pid, NT_ARM_SVE, &iov). Note that when SME is
- present and streaming SVE mode is in use the FPSIMD subset of registers
- will be read via NT_ARM_SVE and NT_ARM_SVE writes will exit streaming mode
- in the target.
-
-* Whenever SVE scalable register values (Zn, Pn, FFR) are exchanged in memory
- between userspace and the kernel, the register value is encoded in memory in
- an endianness-invariant layout, with bits [(8 * i + 7) : (8 * i)] encoded at
- byte offset i from the start of the memory representation. This affects for
- example the signal frame (struct sve_context) and ptrace interface
- (struct user_sve_header) and associated data.
-
- Beware that on big-endian systems this results in a different byte order than
- for the FPSIMD V-registers, which are stored as single host-endian 128-bit
- values, with bits [(127 - 8 * i) : (120 - 8 * i)] of the register encoded at
- byte offset i. (struct fpsimd_context, struct user_fpsimd_state).
-
-
-2. Vector length terminology
------------------------------
-
-The size of an SVE vector (Z) register is referred to as the "vector length".
-
-To avoid confusion about the units used to express vector length, the kernel
-adopts the following conventions:
-
-* Vector length (VL) = size of a Z-register in bytes
-
-* Vector quadwords (VQ) = size of a Z-register in units of 128 bits
-
-(So, VL = 16 * VQ.)
-
-The VQ convention is used where the underlying granularity is important, such
-as in data structure definitions. In most other situations, the VL convention
-is used. This is consistent with the meaning of the "VL" pseudo-register in
-the SVE instruction set architecture.
-
-
-3. System call behaviour
--------------------------
-
-* On syscall, V0..V31 are preserved (as without SVE). Thus, bits [127:0] of
- Z0..Z31 are preserved. All other bits of Z0..Z31, and all of P0..P15 and FFR
- become zero on return from a syscall.
-
-* The SVE registers are not used to pass arguments to or receive results from
- any syscall.
-
-* In practice the affected registers/bits will be preserved or will be replaced
- with zeros on return from a syscall, but userspace should not make
- assumptions about this. The kernel behaviour may vary on a case-by-case
- basis.
-
-* All other SVE state of a thread, including the currently configured vector
- length, the state of the PR_SVE_VL_INHERIT flag, and the deferred vector
- length (if any), is preserved across all syscalls, subject to the specific
- exceptions for execve() described in section 6.
-
- In particular, on return from a fork() or clone(), the parent and new child
- process or thread share identical SVE configuration, matching that of the
- parent before the call.
-
-
-4. Signal handling
--------------------
-
-* A new signal frame record sve_context encodes the SVE registers on signal
- delivery. [1]
-
-* This record is supplementary to fpsimd_context. The FPSR and FPCR registers
- are only present in fpsimd_context. For convenience, the content of V0..V31
- is duplicated between sve_context and fpsimd_context.
-
-* The record contains a flag field which includes a flag SVE_SIG_FLAG_SM which
- if set indicates that the thread is in streaming mode and the vector length
- and register data (if present) describe the streaming SVE data and vector
- length.
-
-* The signal frame record for SVE always contains basic metadata, in particular
- the thread's vector length (in sve_context.vl).
-
-* The SVE registers may or may not be included in the record, depending on
- whether the registers are live for the thread. The registers are present if
- and only if:
- sve_context.head.size >= SVE_SIG_CONTEXT_SIZE(sve_vq_from_vl(sve_context.vl)).
-
-* If the registers are present, the remainder of the record has a vl-dependent
- size and layout. Macros SVE_SIG_* are defined [1] to facilitate access to
- the members.
-
-* Each scalable register (Zn, Pn, FFR) is stored in an endianness-invariant
- layout, with bits [(8 * i + 7) : (8 * i)] stored at byte offset i from the
- start of the register's representation in memory.
-
-* If the SVE context is too big to fit in sigcontext.__reserved[], then extra
- space is allocated on the stack, an extra_context record is written in
- __reserved[] referencing this space. sve_context is then written in the
- extra space. Refer to [1] for further details about this mechanism.
-
-
-5. Signal return
------------------
-
-When returning from a signal handler:
-
-* If there is no sve_context record in the signal frame, or if the record is
- present but contains no register data as described in the previous section,
- then the SVE registers/bits become non-live and take unspecified values.
-
-* If sve_context is present in the signal frame and contains full register
- data, the SVE registers become live and are populated with the specified
- data. However, for backward compatibility reasons, bits [127:0] of Z0..Z31
- are always restored from the corresponding members of fpsimd_context.vregs[]
- and not from sve_context. The remaining bits are restored from sve_context.
-
-* Inclusion of fpsimd_context in the signal frame remains mandatory,
- irrespective of whether sve_context is present or not.
-
-* The vector length cannot be changed via signal return. If sve_context.vl in
- the signal frame does not match the current vector length, the signal return
- attempt is treated as illegal, resulting in a forced SIGSEGV.
-
-* It is permitted to enter or leave streaming mode by setting or clearing
- the SVE_SIG_FLAG_SM flag but applications should take care to ensure that
- when doing so sve_context.vl and any register data are appropriate for the
- vector length in the new mode.
-
-
-6. prctl extensions
---------------------
-
-Some new prctl() calls are added to allow programs to manage the SVE vector
-length:
-
-prctl(PR_SVE_SET_VL, unsigned long arg)
-
- Sets the vector length of the calling thread and related flags, where
- arg == vl | flags. Other threads of the calling process are unaffected.
-
- vl is the desired vector length, where sve_vl_valid(vl) must be true.
-
- flags:
-
- PR_SVE_VL_INHERIT
-
- Inherit the current vector length across execve(). Otherwise, the
- vector length is reset to the system default at execve(). (See
- Section 9.)
-
- PR_SVE_SET_VL_ONEXEC
-
- Defer the requested vector length change until the next execve()
- performed by this thread.
-
- The effect is equivalent to implicit execution of the following
- call immediately after the next execve() (if any) by the thread:
-
- prctl(PR_SVE_SET_VL, arg & ~PR_SVE_SET_VL_ONEXEC)
-
- This allows launching of a new program with a different vector
- length, while avoiding runtime side effects in the caller.
-
-
- Without PR_SVE_SET_VL_ONEXEC, the requested change takes effect
- immediately.
-
-
- Return value: a nonnegative on success, or a negative value on error:
- EINVAL: SVE not supported, invalid vector length requested, or
- invalid flags.
-
-
- On success:
-
- * Either the calling thread's vector length or the deferred vector length
- to be applied at the next execve() by the thread (dependent on whether
- PR_SVE_SET_VL_ONEXEC is present in arg), is set to the largest value
- supported by the system that is less than or equal to vl. If vl ==
- SVE_VL_MAX, the value set will be the largest value supported by the
- system.
-
- * Any previously outstanding deferred vector length change in the calling
- thread is cancelled.
-
- * The returned value describes the resulting configuration, encoded as for
- PR_SVE_GET_VL. The vector length reported in this value is the new
- current vector length for this thread if PR_SVE_SET_VL_ONEXEC was not
- present in arg; otherwise, the reported vector length is the deferred
- vector length that will be applied at the next execve() by the calling
- thread.
-
- * Changing the vector length causes all of P0..P15, FFR and all bits of
- Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
- unspecified. Calling PR_SVE_SET_VL with vl equal to the thread's current
- vector length, or calling PR_SVE_SET_VL with the PR_SVE_SET_VL_ONEXEC
- flag, does not constitute a change to the vector length for this purpose.
-
-
-prctl(PR_SVE_GET_VL)
-
- Gets the vector length of the calling thread.
-
- The following flag may be OR-ed into the result:
-
- PR_SVE_VL_INHERIT
-
- Vector length will be inherited across execve().
-
- There is no way to determine whether there is an outstanding deferred
- vector length change (which would only normally be the case between a
- fork() or vfork() and the corresponding execve() in typical use).
-
- To extract the vector length from the result, bitwise and it with
- PR_SVE_VL_LEN_MASK.
-
- Return value: a nonnegative value on success, or a negative value on error:
- EINVAL: SVE not supported.
-
-
-7. ptrace extensions
----------------------
-
-* New regsets NT_ARM_SVE and NT_ARM_SSVE are defined for use with
- PTRACE_GETREGSET and PTRACE_SETREGSET. NT_ARM_SSVE describes the
- streaming mode SVE registers and NT_ARM_SVE describes the
- non-streaming mode SVE registers.
-
- In this description a register set is referred to as being "live" when
- the target is in the appropriate streaming or non-streaming mode and is
- using data beyond the subset shared with the FPSIMD Vn registers.
-
- Refer to [2] for definitions.
-
-The regset data starts with struct user_sve_header, containing:
-
- size
-
- Size of the complete regset, in bytes.
- This depends on vl and possibly on other things in the future.
-
- If a call to PTRACE_GETREGSET requests less data than the value of
- size, the caller can allocate a larger buffer and retry in order to
- read the complete regset.
-
- max_size
-
- Maximum size in bytes that the regset can grow to for the target
- thread. The regset won't grow bigger than this even if the target
- thread changes its vector length etc.
-
- vl
-
- Target thread's current vector length, in bytes.
-
- max_vl
-
- Maximum possible vector length for the target thread.
-
- flags
-
- at most one of
-
- SVE_PT_REGS_FPSIMD
-
- SVE registers are not live (GETREGSET) or are to be made
- non-live (SETREGSET).
-
- The payload is of type struct user_fpsimd_state, with the same
- meaning as for NT_PRFPREG, starting at offset
- SVE_PT_FPSIMD_OFFSET from the start of user_sve_header.
-
- Extra data might be appended in the future: the size of the
- payload should be obtained using SVE_PT_FPSIMD_SIZE(vq, flags).
-
- vq should be obtained using sve_vq_from_vl(vl).
-
- or
-
- SVE_PT_REGS_SVE
-
- SVE registers are live (GETREGSET) or are to be made live
- (SETREGSET).
-
- The payload contains the SVE register data, starting at offset
- SVE_PT_SVE_OFFSET from the start of user_sve_header, and with
- size SVE_PT_SVE_SIZE(vq, flags);
-
- ... OR-ed with zero or more of the following flags, which have the same
- meaning and behaviour as the corresponding PR_SET_VL_* flags:
-
- SVE_PT_VL_INHERIT
-
- SVE_PT_VL_ONEXEC (SETREGSET only).
-
- If neither FPSIMD nor SVE flags are provided then no register
- payload is available, this is only possible when SME is implemented.
-
-
-* The effects of changing the vector length and/or flags are equivalent to
- those documented for PR_SVE_SET_VL.
-
- The caller must make a further GETREGSET call if it needs to know what VL is
- actually set by SETREGSET, unless is it known in advance that the requested
- VL is supported.
-
-* In the SVE_PT_REGS_SVE case, the size and layout of the payload depends on
- the header fields. The SVE_PT_SVE_*() macros are provided to facilitate
- access to the members.
-
-* In either case, for SETREGSET it is permissible to omit the payload, in which
- case only the vector length and flags are changed (along with any
- consequences of those changes).
-
-* In systems supporting SME when in streaming mode a GETREGSET for
- NT_REG_SVE will return only the user_sve_header with no register data,
- similarly a GETREGSET for NT_REG_SSVE will not return any register data
- when not in streaming mode.
-
-* A GETREGSET for NT_ARM_SSVE will never return SVE_PT_REGS_FPSIMD.
-
-* For SETREGSET, if an SVE_PT_REGS_SVE payload is present and the
- requested VL is not supported, the effect will be the same as if the
- payload were omitted, except that an EIO error is reported. No
- attempt is made to translate the payload data to the correct layout
- for the vector length actually set. The thread's FPSIMD state is
- preserved, but the remaining bits of the SVE registers become
- unspecified. It is up to the caller to translate the payload layout
- for the actual VL and retry.
-
-* Where SME is implemented it is not possible to GETREGSET the register
- state for normal SVE when in streaming mode, nor the streaming mode
- register state when in normal mode, regardless of the implementation defined
- behaviour of the hardware for sharing data between the two modes.
-
-* Any SETREGSET of NT_ARM_SVE will exit streaming mode if the target was in
- streaming mode and any SETREGSET of NT_ARM_SSVE will enter streaming mode
- if the target was not in streaming mode.
-
-* The effect of writing a partial, incomplete payload is unspecified.
-
-
-8. ELF coredump extensions
----------------------------
-
-* NT_ARM_SVE and NT_ARM_SSVE notes will be added to each coredump for
- each thread of the dumped process. The contents will be equivalent to the
- data that would have been read if a PTRACE_GETREGSET of the corresponding
- type were executed for each thread when the coredump was generated.
-
-9. System runtime configuration
---------------------------------
-
-* To mitigate the ABI impact of expansion of the signal frame, a policy
- mechanism is provided for administrators, distro maintainers and developers
- to set the default vector length for userspace processes:
-
-/proc/sys/abi/sve_default_vector_length
-
- Writing the text representation of an integer to this file sets the system
- default vector length to the specified value, unless the value is greater
- than the maximum vector length supported by the system in which case the
- default vector length is set to that maximum.
-
- The result can be determined by reopening the file and reading its
- contents.
-
- At boot, the default vector length is initially set to 64 or the maximum
- supported vector length, whichever is smaller. This determines the initial
- vector length of the init process (PID 1).
-
- Reading this file returns the current system default vector length.
-
-* At every execve() call, the new vector length of the new process is set to
- the system default vector length, unless
-
- * PR_SVE_VL_INHERIT (or equivalently SVE_PT_VL_INHERIT) is set for the
- calling thread, or
-
- * a deferred vector length change is pending, established via the
- PR_SVE_SET_VL_ONEXEC flag (or SVE_PT_VL_ONEXEC).
-
-* Modifying the system default vector length does not affect the vector length
- of any existing process or thread that does not make an execve() call.
-
-10. Perf extensions
---------------------------------
-
-* The arm64 specific DWARF standard [5] added the VG (Vector Granule) register
- at index 46. This register is used for DWARF unwinding when variable length
- SVE registers are pushed onto the stack.
-
-* Its value is equivalent to the current SVE vector length (VL) in bits divided
- by 64.
-
-* The value is included in Perf samples in the regs[46] field if
- PERF_SAMPLE_REGS_USER is set and the sample_regs_user mask has bit 46 set.
-
-* The value is the current value at the time the sample was taken, and it can
- change over time.
-
-* If the system doesn't support SVE when perf_event_open is called with these
- settings, the event will fail to open.
-
-Appendix A. SVE programmer's model (informative)
-=================================================
-
-This section provides a minimal description of the additions made by SVE to the
-ARMv8-A programmer's model that are relevant to this document.
-
-Note: This section is for information only and not intended to be complete or
-to replace any architectural specification.
-
-A.1. Registers
----------------
-
-In A64 state, SVE adds the following:
-
-* 32 8VL-bit vector registers Z0..Z31
- For each Zn, Zn bits [127:0] alias the ARMv8-A vector register Vn.
-
- A register write using a Vn register name zeros all bits of the corresponding
- Zn except for bits [127:0].
-
-* 16 VL-bit predicate registers P0..P15
-
-* 1 VL-bit special-purpose predicate register FFR (the "first-fault register")
-
-* a VL "pseudo-register" that determines the size of each vector register
-
- The SVE instruction set architecture provides no way to write VL directly.
- Instead, it can be modified only by EL1 and above, by writing appropriate
- system registers.
-
-* The value of VL can be configured at runtime by EL1 and above:
- 16 <= VL <= VLmax, where VL must be a multiple of 16.
-
-* The maximum vector length is determined by the hardware:
- 16 <= VLmax <= 256.
-
- (The SVE architecture specifies 256, but permits future architecture
- revisions to raise this limit.)
-
-* FPSR and FPCR are retained from ARMv8-A, and interact with SVE floating-point
- operations in a similar way to the way in which they interact with ARMv8
- floating-point operations::
-
- 8VL-1 128 0 bit index
- +---- //// -----------------+
- Z0 | : V0 |
- : :
- Z7 | : V7 |
- Z8 | : * V8 |
- : : :
- Z15 | : *V15 |
- Z16 | : V16 |
- : :
- Z31 | : V31 |
- +---- //// -----------------+
- 31 0
- VL-1 0 +-------+
- +---- //// --+ FPSR | |
- P0 | | +-------+
- : | | *FPCR | |
- P15 | | +-------+
- +---- //// --+
- FFR | | +-----+
- +---- //// --+ VL | |
- +-----+
-
-(*) callee-save:
- This only applies to bits [63:0] of Z-/V-registers.
- FPCR contains callee-save and caller-save bits. See [4] for details.
-
-
-A.2. Procedure call standard
------------------------------
-
-The ARMv8-A base procedure call standard is extended as follows with respect to
-the additional SVE register state:
-
-* All SVE register bits that are not shared with FP/SIMD are caller-save.
-
-* Z8 bits [63:0] .. Z15 bits [63:0] are callee-save.
-
- This follows from the way these bits are mapped to V8..V15, which are caller-
- save in the base procedure call standard.
-
-
-Appendix B. ARMv8-A FP/SIMD programmer's model
-===============================================
-
-Note: This section is for information only and not intended to be complete or
-to replace any architectural specification.
-
-Refer to [4] for more information.
-
-ARMv8-A defines the following floating-point / SIMD register state:
-
-* 32 128-bit vector registers V0..V31
-* 2 32-bit status/control registers FPSR, FPCR
-
-::
-
- 127 0 bit index
- +---------------+
- V0 | |
- : : :
- V7 | |
- * V8 | |
- : : : :
- *V15 | |
- V16 | |
- : : :
- V31 | |
- +---------------+
-
- 31 0
- +-------+
- FPSR | |
- +-------+
- *FPCR | |
- +-------+
-
-(*) callee-save:
- This only applies to bits [63:0] of V-registers.
- FPCR contains a mixture of callee-save and caller-save bits.
-
-
-References
-==========
-
-[1] arch/arm64/include/uapi/asm/sigcontext.h
- AArch64 Linux signal ABI definitions
-
-[2] arch/arm64/include/uapi/asm/ptrace.h
- AArch64 Linux ptrace ABI definitions
-
-[3] Documentation/arm64/cpu-feature-registers.rst
-
-[4] ARM IHI0055C
- http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf
- http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html
- Procedure Call Standard for the ARM 64-bit Architecture (AArch64)
-
-[5] https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst
diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst
deleted file mode 100644
index 540a1d4..0000000
--- a/Documentation/arm64/tagged-address-abi.rst
+++ /dev/null
@@ -1,179 +0,0 @@
-==========================
-AArch64 TAGGED ADDRESS ABI
-==========================
-
-Authors: Vincenzo Frascino <vincenzo.frascino@arm.com>
- Catalin Marinas <catalin.marinas@arm.com>
-
-Date: 21 August 2019
-
-This document describes the usage and semantics of the Tagged Address
-ABI on AArch64 Linux.
-
-1. Introduction
----------------
-
-On AArch64 the ``TCR_EL1.TBI0`` bit is set by default, allowing
-userspace (EL0) to perform memory accesses through 64-bit pointers with
-a non-zero top byte. This document describes the relaxation of the
-syscall ABI that allows userspace to pass certain tagged pointers to
-kernel syscalls.
-
-2. AArch64 Tagged Address ABI
------------------------------
-
-From the kernel syscall interface perspective and for the purposes of
-this document, a "valid tagged pointer" is a pointer with a potentially
-non-zero top-byte that references an address in the user process address
-space obtained in one of the following ways:
-
-- ``mmap()`` syscall where either:
-
- - flags have the ``MAP_ANONYMOUS`` bit set or
- - the file descriptor refers to a regular file (including those
- returned by ``memfd_create()``) or ``/dev/zero``
-
-- ``brk()`` syscall (i.e. the heap area between the initial location of
- the program break at process creation and its current location).
-
-- any memory mapped by the kernel in the address space of the process
- during creation and with the same restrictions as for ``mmap()`` above
- (e.g. data, bss, stack).
-
-The AArch64 Tagged Address ABI has two stages of relaxation depending on
-how the user addresses are used by the kernel:
-
-1. User addresses not accessed by the kernel but used for address space
- management (e.g. ``mprotect()``, ``madvise()``). The use of valid
- tagged pointers in this context is allowed with these exceptions:
-
- - ``brk()``, ``mmap()`` and the ``new_address`` argument to
- ``mremap()`` as these have the potential to alias with existing
- user addresses.
-
- NOTE: This behaviour changed in v5.6 and so some earlier kernels may
- incorrectly accept valid tagged pointers for the ``brk()``,
- ``mmap()`` and ``mremap()`` system calls.
-
- - The ``range.start``, ``start`` and ``dst`` arguments to the
- ``UFFDIO_*`` ``ioctl()``s used on a file descriptor obtained from
- ``userfaultfd()``, as fault addresses subsequently obtained by reading
- the file descriptor will be untagged, which may otherwise confuse
- tag-unaware programs.
-
- NOTE: This behaviour changed in v5.14 and so some earlier kernels may
- incorrectly accept valid tagged pointers for this system call.
-
-2. User addresses accessed by the kernel (e.g. ``write()``). This ABI
- relaxation is disabled by default and the application thread needs to
- explicitly enable it via ``prctl()`` as follows:
-
- - ``PR_SET_TAGGED_ADDR_CTRL``: enable or disable the AArch64 Tagged
- Address ABI for the calling thread.
-
- The ``(unsigned int) arg2`` argument is a bit mask describing the
- control mode used:
-
- - ``PR_TAGGED_ADDR_ENABLE``: enable AArch64 Tagged Address ABI.
- Default status is disabled.
-
- Arguments ``arg3``, ``arg4``, and ``arg5`` must be 0.
-
- - ``PR_GET_TAGGED_ADDR_CTRL``: get the status of the AArch64 Tagged
- Address ABI for the calling thread.
-
- Arguments ``arg2``, ``arg3``, ``arg4``, and ``arg5`` must be 0.
-
- The ABI properties described above are thread-scoped, inherited on
- clone() and fork() and cleared on exec().
-
- Calling ``prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0)``
- returns ``-EINVAL`` if the AArch64 Tagged Address ABI is globally
- disabled by ``sysctl abi.tagged_addr_disabled=1``. The default
- ``sysctl abi.tagged_addr_disabled`` configuration is 0.
-
-When the AArch64 Tagged Address ABI is enabled for a thread, the
-following behaviours are guaranteed:
-
-- All syscalls except the cases mentioned in section 3 can accept any
- valid tagged pointer.
-
-- The syscall behaviour is undefined for invalid tagged pointers: it may
- result in an error code being returned, a (fatal) signal being raised,
- or other modes of failure.
-
-- The syscall behaviour for a valid tagged pointer is the same as for
- the corresponding untagged pointer.
-
-
-A definition of the meaning of tagged pointers on AArch64 can be found
-in Documentation/arm64/tagged-pointers.rst.
-
-3. AArch64 Tagged Address ABI Exceptions
------------------------------------------
-
-The following system call parameters must be untagged regardless of the
-ABI relaxation:
-
-- ``prctl()`` other than pointers to user data either passed directly or
- indirectly as arguments to be accessed by the kernel.
-
-- ``ioctl()`` other than pointers to user data either passed directly or
- indirectly as arguments to be accessed by the kernel.
-
-- ``shmat()`` and ``shmdt()``.
-
-- ``brk()`` (since kernel v5.6).
-
-- ``mmap()`` (since kernel v5.6).
-
-- ``mremap()``, the ``new_address`` argument (since kernel v5.6).
-
-Any attempt to use non-zero tagged pointers may result in an error code
-being returned, a (fatal) signal being raised, or other modes of
-failure.
-
-4. Example of correct usage
----------------------------
-.. code-block:: c
-
- #include <stdlib.h>
- #include <string.h>
- #include <unistd.h>
- #include <sys/mman.h>
- #include <sys/prctl.h>
-
- #define PR_SET_TAGGED_ADDR_CTRL 55
- #define PR_TAGGED_ADDR_ENABLE (1UL << 0)
-
- #define TAG_SHIFT 56
-
- int main(void)
- {
- int tbi_enabled = 0;
- unsigned long tag = 0;
- char *ptr;
-
- /* check/enable the tagged address ABI */
- if (!prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0))
- tbi_enabled = 1;
-
- /* memory allocation */
- ptr = mmap(NULL, sysconf(_SC_PAGE_SIZE), PROT_READ | PROT_WRITE,
- MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
- if (ptr == MAP_FAILED)
- return 1;
-
- /* set a non-zero tag if the ABI is available */
- if (tbi_enabled)
- tag = rand() & 0xff;
- ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
-
- /* memory access to a tagged address */
- strcpy(ptr, "tagged pointer\n");
-
- /* syscall with a tagged pointer */
- write(1, ptr, strlen(ptr));
-
- return 0;
- }
diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
deleted file mode 100644
index 19d284b..0000000
--- a/Documentation/arm64/tagged-pointers.rst
+++ /dev/null
@@ -1,88 +0,0 @@
-=========================================
-Tagged virtual addresses in AArch64 Linux
-=========================================
-
-Author: Will Deacon <will.deacon@arm.com>
-
-Date : 12 June 2013
-
-This document briefly describes the provision of tagged virtual
-addresses in the AArch64 translation system and their potential uses
-in AArch64 Linux.
-
-The kernel configures the translation tables so that translations made
-via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
-the virtual address ignored by the translation hardware. This frees up
-this byte for application use.
-
-
-Passing tagged addresses to the kernel
---------------------------------------
-
-All interpretation of userspace memory addresses by the kernel assumes
-an address tag of 0x00, unless the application enables the AArch64
-Tagged Address ABI explicitly
-(Documentation/arm64/tagged-address-abi.rst).
-
-This includes, but is not limited to, addresses found in:
-
- - pointer arguments to system calls, including pointers in structures
- passed to system calls,
-
- - the stack pointer (sp), e.g. when interpreting it to deliver a
- signal,
-
- - the frame pointer (x29) and frame records, e.g. when interpreting
- them to generate a backtrace or call graph.
-
-Using non-zero address tags in any of these locations when the
-userspace application did not enable the AArch64 Tagged Address ABI may
-result in an error code being returned, a (fatal) signal being raised,
-or other modes of failure.
-
-For these reasons, when the AArch64 Tagged Address ABI is disabled,
-passing non-zero address tags to the kernel via system calls is
-forbidden, and using a non-zero address tag for sp is strongly
-discouraged.
-
-Programs maintaining a frame pointer and frame records that use non-zero
-address tags may suffer impaired or inaccurate debug and profiling
-visibility.
-
-
-Preserving tags
----------------
-
-When delivering signals, non-zero tags are not preserved in
-siginfo.si_addr unless the flag SA_EXPOSE_TAGBITS was set in
-sigaction.sa_flags when the signal handler was installed. This means
-that signal handlers in applications making use of tags cannot rely
-on the tag information for user virtual addresses being maintained
-in these fields unless the flag was set.
-
-Due to architecture limitations, bits 63:60 of the fault address
-are not preserved in response to synchronous tag check faults
-(SEGV_MTESERR) even if SA_EXPOSE_TAGBITS was set. Applications should
-treat the values of these bits as undefined in order to accommodate
-future architecture revisions which may preserve the bits.
-
-For signals raised in response to watchpoint debug exceptions, the
-tag information will be preserved regardless of the SA_EXPOSE_TAGBITS
-flag setting.
-
-Non-zero tags are never preserved in sigcontext.fault_address
-regardless of the SA_EXPOSE_TAGBITS flag setting.
-
-The architecture prevents the use of a tagged PC, so the upper byte will
-be set to a sign-extension of bit 55 on exception return.
-
-This behaviour is maintained when the AArch64 Tagged Address ABI is
-enabled.
-
-
-Other considerations
---------------------
-
-Special care should be taken when using tagged pointers, since it is
-likely that C compilers will not hazard two virtual addresses differing
-only in the upper byte.
diff --git a/Documentation/bpf/bpf_iterators.rst b/Documentation/bpf/bpf_iterators.rst
index 6d77707..0743391 100644
--- a/Documentation/bpf/bpf_iterators.rst
+++ b/Documentation/bpf/bpf_iterators.rst
@@ -238,11 +238,8 @@
that the kernel function cond_resched() is called to avoid other kernel
subsystem (e.g., rcu) misbehaving.
* - seq_info
- - Specifies certain action requests in the kernel BPF iterator
- infrastructure. Currently, only BPF_ITER_RESCHED is supported. This means
- that the kernel function cond_resched() is called to avoid other kernel
- subsystem (e.g., rcu) misbehaving.
-
+ - Specifies the set of seq operations for the BPF iterator and helpers to
+ initialize/free the private data for the corresponding ``seq_file``.
`Click here
<https://lore.kernel.org/bpf/20210212183107.50963-2-songliubraving@fb.com/>`_
diff --git a/Documentation/bpf/cpumasks.rst b/Documentation/bpf/cpumasks.rst
index 41efd88..3139c7c 100644
--- a/Documentation/bpf/cpumasks.rst
+++ b/Documentation/bpf/cpumasks.rst
@@ -351,14 +351,15 @@
can be used to query the contents of cpumasks.
.. kernel-doc:: kernel/bpf/cpumask.c
- :identifiers: bpf_cpumask_first bpf_cpumask_first_zero bpf_cpumask_test_cpu
+ :identifiers: bpf_cpumask_first bpf_cpumask_first_zero bpf_cpumask_first_and
+ bpf_cpumask_test_cpu
.. kernel-doc:: kernel/bpf/cpumask.c
:identifiers: bpf_cpumask_equal bpf_cpumask_intersects bpf_cpumask_subset
bpf_cpumask_empty bpf_cpumask_full
.. kernel-doc:: kernel/bpf/cpumask.c
- :identifiers: bpf_cpumask_any bpf_cpumask_any_and
+ :identifiers: bpf_cpumask_any_distribute bpf_cpumask_any_and_distribute
----
diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst
index 492980e..6644842 100644
--- a/Documentation/bpf/instruction-set.rst
+++ b/Documentation/bpf/instruction-set.rst
@@ -163,13 +163,13 @@
BPF_DIV 0x30 dst = (src != 0) ? (dst / src) : 0
BPF_OR 0x40 dst \|= src
BPF_AND 0x50 dst &= src
-BPF_LSH 0x60 dst <<= src
-BPF_RSH 0x70 dst >>= src
+BPF_LSH 0x60 dst <<= (src & mask)
+BPF_RSH 0x70 dst >>= (src & mask)
BPF_NEG 0x80 dst = ~src
BPF_MOD 0x90 dst = (src != 0) ? (dst % src) : dst
BPF_XOR 0xa0 dst ^= src
BPF_MOV 0xb0 dst = src
-BPF_ARSH 0xc0 sign extending shift right
+BPF_ARSH 0xc0 sign extending dst >>= (src & mask)
BPF_END 0xd0 byte swap operations (see `Byte swap instructions`_ below)
======== ===== ==========================================================
@@ -204,6 +204,9 @@
interpreted as an unsigned 64-bit value. There are no instructions for
signed division or modulo.
+Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31)
+for 32-bit operations.
+
Byte swap instructions
~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst
index ea2516374..0d2647f 100644
--- a/Documentation/bpf/kfuncs.rst
+++ b/Documentation/bpf/kfuncs.rst
@@ -100,7 +100,7 @@
size parameter, and the value of the constant matters for program safety, __k
suffix should be used.
-2.2.2 __uninit Annotation
+2.2.3 __uninit Annotation
-------------------------
This annotation is used to indicate that the argument will be treated as
@@ -117,6 +117,27 @@
annotation, the verifier will reject the program if the dynptr passed in is
not initialized.
+2.2.4 __opt Annotation
+-------------------------
+
+This annotation is used to indicate that the buffer associated with an __sz or __szk
+argument may be null. If the function is passed a nullptr in place of the buffer,
+the verifier will not check that length is appropriate for the buffer. The kfunc is
+responsible for checking if this buffer is null before using it.
+
+An example is given below::
+
+ __bpf_kfunc void *bpf_dynptr_slice(..., void *buffer__opt, u32 buffer__szk)
+ {
+ ...
+ }
+
+Here, the buffer may be null. If buffer is not null, it at least of size buffer_szk.
+Either way, the returned buffer is either NULL, or of size buffer_szk. Without this
+annotation, the verifier will reject the program if a null pointer is passed in with
+a nonzero size.
+
+
.. _BPF_kfunc_nodef:
2.3 Using an existing kernel function
@@ -206,23 +227,49 @@
As mentioned above, a nested pointer obtained from walking a trusted pointer is
no longer trusted, with one exception. If a struct type has a field that is
-guaranteed to be valid as long as its parent pointer is trusted, the
-``BTF_TYPE_SAFE_NESTED`` macro can be used to express that to the verifier as
-follows:
+guaranteed to be valid (trusted or rcu, as in KF_RCU description below) as long
+as its parent pointer is valid, the following macros can be used to express
+that to the verifier:
+
+* ``BTF_TYPE_SAFE_TRUSTED``
+* ``BTF_TYPE_SAFE_RCU``
+* ``BTF_TYPE_SAFE_RCU_OR_NULL``
+
+For example,
.. code-block:: c
- BTF_TYPE_SAFE_NESTED(struct task_struct) {
+ BTF_TYPE_SAFE_TRUSTED(struct socket) {
+ struct sock *sk;
+ };
+
+or
+
+.. code-block:: c
+
+ BTF_TYPE_SAFE_RCU(struct task_struct) {
const cpumask_t *cpus_ptr;
+ struct css_set __rcu *cgroups;
+ struct task_struct __rcu *real_parent;
+ struct task_struct *group_leader;
};
In other words, you must:
-1. Wrap the trusted pointer type in the ``BTF_TYPE_SAFE_NESTED`` macro.
+1. Wrap the valid pointer type in a ``BTF_TYPE_SAFE_*`` macro.
-2. Specify the type and name of the trusted nested field. This field must match
+2. Specify the type and name of the valid nested field. This field must match
the field in the original type definition exactly.
+A new type declared by a ``BTF_TYPE_SAFE_*`` macro also needs to be emitted so
+that it appears in BTF. For example, ``BTF_TYPE_SAFE_TRUSTED(struct socket)``
+is emitted in the ``type_is_trusted()`` function as follows:
+
+.. code-block:: c
+
+ BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct socket));
+
+
2.4.5 KF_SLEEPABLE flag
-----------------------
diff --git a/Documentation/bpf/llvm_reloc.rst b/Documentation/bpf/llvm_reloc.rst
index ca8957d..e4a777a 100644
--- a/Documentation/bpf/llvm_reloc.rst
+++ b/Documentation/bpf/llvm_reloc.rst
@@ -48,7 +48,7 @@
14: 0f 10 00 00 00 00 00 00 r0 += r1
15: 95 00 00 00 00 00 00 00 exit
-There are four relations in the above for four ``LD_imm64`` instructions.
+There are four relocations in the above for four ``LD_imm64`` instructions.
The following ``llvm-readelf -r test.o`` shows the binary values of the four
relocations::
@@ -79,14 +79,16 @@
The 6th entry is global variable ``g1`` with value 0.
Similarly, the second relocation is at ``.text`` offset ``0x18``, instruction 3,
-for global variable ``g2`` which has a symbol value 4, the offset
-from the start of ``.data`` section.
+has a type of ``R_BPF_64_64`` and refers to entry 7 in the symbol table.
+The second relocation resolves to global variable ``g2`` which has a symbol
+value 4. The symbol value represents the offset from the start of ``.data``
+section where the initial value of the global variable ``g2`` is stored.
-The third and fourth relocations refers to static variables ``l1``
-and ``l2``. From ``.rel.text`` section above, it is not clear
-which symbols they really refers to as they both refers to
+The third and fourth relocations refer to static variables ``l1``
+and ``l2``. From the ``.rel.text`` section above, it is not clear
+to which symbols they really refer as they both refer to
symbol table entry 4, symbol ``sec``, which has ``STT_SECTION`` type
-and represents a section. So for static variable or function,
+and represents a section. So for a static variable or function,
the section offset is written to the original insn
buffer, which is called ``A`` (addend). Looking at
above insn ``7`` and ``11``, they have section offset ``8`` and ``12``.
diff --git a/Documentation/bpf/map_hash.rst b/Documentation/bpf/map_hash.rst
index 8669426..d234395 100644
--- a/Documentation/bpf/map_hash.rst
+++ b/Documentation/bpf/map_hash.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0-only
.. Copyright (C) 2022 Red Hat, Inc.
+.. Copyright (C) 2022-2023 Isovalent, Inc.
===============================================
BPF_MAP_TYPE_HASH, with PERCPU and LRU Variants
@@ -29,7 +30,16 @@
table reaches capacity. An LRU hash maintains an internal LRU list that
is used to select elements for eviction. This internal LRU list is
shared across CPUs but it is possible to request a per CPU LRU list with
-the ``BPF_F_NO_COMMON_LRU`` flag when calling ``bpf_map_create``.
+the ``BPF_F_NO_COMMON_LRU`` flag when calling ``bpf_map_create``. The
+following table outlines the properties of LRU maps depending on the a
+map type and the flags used to create the map.
+
+======================== ========================= ================================
+Flag ``BPF_MAP_TYPE_LRU_HASH`` ``BPF_MAP_TYPE_LRU_PERCPU_HASH``
+======================== ========================= ================================
+**BPF_F_NO_COMMON_LRU** Per-CPU LRU, global map Per-CPU LRU, per-cpu map
+**!BPF_F_NO_COMMON_LRU** Global LRU, global map Global LRU, per-cpu map
+======================== ========================= ================================
Usage
=====
@@ -206,3 +216,44 @@
cur_key = &next_key;
}
}
+
+Internals
+=========
+
+This section of the document is targeted at Linux developers and describes
+aspects of the map implementations that are not considered stable ABI. The
+following details are subject to change in future versions of the kernel.
+
+``BPF_MAP_TYPE_LRU_HASH`` and variants
+--------------------------------------
+
+Updating elements in LRU maps may trigger eviction behaviour when the capacity
+of the map is reached. There are various steps that the update algorithm
+attempts in order to enforce the LRU property which have increasing impacts on
+other CPUs involved in the following operation attempts:
+
+- Attempt to use CPU-local state to batch operations
+- Attempt to fetch free nodes from global lists
+- Attempt to pull any node from a global list and remove it from the hashmap
+- Attempt to pull any node from any CPU's list and remove it from the hashmap
+
+This algorithm is described visually in the following diagram. See the
+description in commit 3a08c2fd7634 ("bpf: LRU List") for a full explanation of
+the corresponding operations:
+
+.. kernel-figure:: map_lru_hash_update.dot
+ :alt: Diagram outlining the LRU eviction steps taken during map update.
+
+ LRU hash eviction during map update for ``BPF_MAP_TYPE_LRU_HASH`` and
+ variants. See the dot file source for kernel function name code references.
+
+Map updates start from the oval in the top right "begin ``bpf_map_update()``"
+and progress through the graph towards the bottom where the result may be
+either a successful update or a failure with various error codes. The key in
+the top right provides indicators for which locks may be involved in specific
+operations. This is intended as a visual hint for reasoning about how map
+contention may impact update operations, though the map type and flags may
+impact the actual contention on those locks, based on the logic described in
+the table above. For instance, if the map is created with type
+``BPF_MAP_TYPE_LRU_PERCPU_HASH`` and flags ``BPF_F_NO_COMMON_LRU`` then all map
+properties would be per-cpu.
diff --git a/Documentation/bpf/map_lru_hash_update.dot b/Documentation/bpf/map_lru_hash_update.dot
new file mode 100644
index 0000000..a0fee34
--- /dev/null
+++ b/Documentation/bpf/map_lru_hash_update.dot
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (C) 2022-2023 Isovalent, Inc.
+digraph {
+ node [colorscheme=accent4,style=filled] # Apply colorscheme to all nodes
+ graph [splines=ortho, nodesep=1]
+
+ subgraph cluster_key {
+ label = "Key\n(locks held during operation)";
+ rankdir = TB;
+
+ remote_lock [shape=rectangle,fillcolor=4,label="remote CPU LRU lock"]
+ hash_lock [shape=rectangle,fillcolor=3,label="hashtab lock"]
+ lru_lock [shape=rectangle,fillcolor=2,label="LRU lock"]
+ local_lock [shape=rectangle,fillcolor=1,label="local CPU LRU lock"]
+ no_lock [shape=rectangle,label="no locks held"]
+ }
+
+ begin [shape=oval,label="begin\nbpf_map_update()"]
+
+ // Nodes below with an 'fn_' prefix are roughly labeled by the C function
+ // names that initiate the corresponding logic in kernel/bpf/bpf_lru_list.c.
+ // Number suffixes and errno suffixes handle subsections of the corresponding
+ // logic in the function as of the writing of this dot.
+
+ // cf. __local_list_pop_free() / bpf_percpu_lru_pop_free()
+ local_freelist_check [shape=diamond,fillcolor=1,
+ label="Local freelist\nnode available?"];
+ use_local_node [shape=rectangle,
+ label="Use node owned\nby this CPU"]
+
+ // cf. bpf_lru_pop_free()
+ common_lru_check [shape=diamond,
+ label="Map created with\ncommon LRU?\n(!BPF_F_NO_COMMON_LRU)"];
+
+ fn_bpf_lru_list_pop_free_to_local [shape=rectangle,fillcolor=2,
+ label="Flush local pending,
+ Rotate Global list, move
+ LOCAL_FREE_TARGET
+ from global -> local"]
+ // Also corresponds to:
+ // fn__local_list_flush()
+ // fn_bpf_lru_list_rotate()
+ fn___bpf_lru_node_move_to_free[shape=diamond,fillcolor=2,
+ label="Able to free\nLOCAL_FREE_TARGET\nnodes?"]
+
+ fn___bpf_lru_list_shrink_inactive [shape=rectangle,fillcolor=3,
+ label="Shrink inactive list
+ up to remaining
+ LOCAL_FREE_TARGET
+ (global LRU -> local)"]
+ fn___bpf_lru_list_shrink [shape=diamond,fillcolor=2,
+ label="> 0 entries in\nlocal free list?"]
+ fn___bpf_lru_list_shrink2 [shape=rectangle,fillcolor=2,
+ label="Steal one node from
+ inactive, or if empty,
+ from active global list"]
+ fn___bpf_lru_list_shrink3 [shape=rectangle,fillcolor=3,
+ label="Try to remove\nnode from hashtab"]
+
+ local_freelist_check2 [shape=diamond,label="Htab removal\nsuccessful?"]
+ common_lru_check2 [shape=diamond,
+ label="Map created with\ncommon LRU?\n(!BPF_F_NO_COMMON_LRU)"];
+
+ subgraph cluster_remote_lock {
+ label = "Iterate through CPUs\n(start from current)";
+ style = dashed;
+ rankdir=LR;
+
+ local_freelist_check5 [shape=diamond,fillcolor=4,
+ label="Steal a node from\nper-cpu freelist?"]
+ local_freelist_check6 [shape=rectangle,fillcolor=4,
+ label="Steal a node from
+ (1) Unreferenced pending, or
+ (2) Any pending node"]
+ local_freelist_check7 [shape=rectangle,fillcolor=3,
+ label="Try to remove\nnode from hashtab"]
+ fn_htab_lru_map_update_elem [shape=diamond,
+ label="Stole node\nfrom remote\nCPU?"]
+ fn_htab_lru_map_update_elem2 [shape=diamond,label="Iterated\nall CPUs?"]
+ // Also corresponds to:
+ // use_local_node()
+ // fn__local_list_pop_pending()
+ }
+
+ fn_bpf_lru_list_pop_free_to_local2 [shape=rectangle,
+ label="Use node that was\nnot recently referenced"]
+ local_freelist_check4 [shape=rectangle,
+ label="Use node that was\nactively referenced\nin global list"]
+ fn_htab_lru_map_update_elem_ENOMEM [shape=oval,label="return -ENOMEM"]
+ fn_htab_lru_map_update_elem3 [shape=rectangle,
+ label="Use node that was\nactively referenced\nin (another?) CPU's cache"]
+ fn_htab_lru_map_update_elem4 [shape=rectangle,fillcolor=3,
+ label="Update hashmap\nwith new element"]
+ fn_htab_lru_map_update_elem5 [shape=oval,label="return 0"]
+ fn_htab_lru_map_update_elem_EBUSY [shape=oval,label="return -EBUSY"]
+ fn_htab_lru_map_update_elem_EEXIST [shape=oval,label="return -EEXIST"]
+ fn_htab_lru_map_update_elem_ENOENT [shape=oval,label="return -ENOENT"]
+
+ begin -> local_freelist_check
+ local_freelist_check -> use_local_node [xlabel="Y"]
+ local_freelist_check -> common_lru_check [xlabel="N"]
+ common_lru_check -> fn_bpf_lru_list_pop_free_to_local [xlabel="Y"]
+ common_lru_check -> fn___bpf_lru_list_shrink_inactive [xlabel="N"]
+ fn_bpf_lru_list_pop_free_to_local -> fn___bpf_lru_node_move_to_free
+ fn___bpf_lru_node_move_to_free ->
+ fn_bpf_lru_list_pop_free_to_local2 [xlabel="Y"]
+ fn___bpf_lru_node_move_to_free ->
+ fn___bpf_lru_list_shrink_inactive [xlabel="N"]
+ fn___bpf_lru_list_shrink_inactive -> fn___bpf_lru_list_shrink
+ fn___bpf_lru_list_shrink -> fn_bpf_lru_list_pop_free_to_local2 [xlabel = "Y"]
+ fn___bpf_lru_list_shrink -> fn___bpf_lru_list_shrink2 [xlabel="N"]
+ fn___bpf_lru_list_shrink2 -> fn___bpf_lru_list_shrink3
+ fn___bpf_lru_list_shrink3 -> local_freelist_check2
+ local_freelist_check2 -> local_freelist_check4 [xlabel = "Y"]
+ local_freelist_check2 -> common_lru_check2 [xlabel = "N"]
+ common_lru_check2 -> local_freelist_check5 [xlabel = "Y"]
+ common_lru_check2 -> fn_htab_lru_map_update_elem_ENOMEM [xlabel = "N"]
+ local_freelist_check5 -> fn_htab_lru_map_update_elem [xlabel = "Y"]
+ local_freelist_check5 -> local_freelist_check6 [xlabel = "N"]
+ local_freelist_check6 -> local_freelist_check7
+ local_freelist_check7 -> fn_htab_lru_map_update_elem
+
+ fn_htab_lru_map_update_elem -> fn_htab_lru_map_update_elem3 [xlabel = "Y"]
+ fn_htab_lru_map_update_elem -> fn_htab_lru_map_update_elem2 [xlabel = "N"]
+ fn_htab_lru_map_update_elem2 ->
+ fn_htab_lru_map_update_elem_ENOMEM [xlabel = "Y"]
+ fn_htab_lru_map_update_elem2 -> local_freelist_check5 [xlabel = "N"]
+ fn_htab_lru_map_update_elem3 -> fn_htab_lru_map_update_elem4
+
+ use_local_node -> fn_htab_lru_map_update_elem4
+ fn_bpf_lru_list_pop_free_to_local2 -> fn_htab_lru_map_update_elem4
+ local_freelist_check4 -> fn_htab_lru_map_update_elem4
+
+ fn_htab_lru_map_update_elem4 -> fn_htab_lru_map_update_elem5 [headlabel="Success"]
+ fn_htab_lru_map_update_elem4 ->
+ fn_htab_lru_map_update_elem_EBUSY [xlabel="Hashtab lock failed"]
+ fn_htab_lru_map_update_elem4 ->
+ fn_htab_lru_map_update_elem_EEXIST [xlabel="BPF_EXIST set and\nkey already exists"]
+ fn_htab_lru_map_update_elem4 ->
+ fn_htab_lru_map_update_elem_ENOENT [headlabel="BPF_NOEXIST set\nand no such entry"]
+
+ // Create invisible pad nodes to line up various nodes
+ pad0 [style=invis]
+ pad1 [style=invis]
+ pad2 [style=invis]
+ pad3 [style=invis]
+ pad4 [style=invis]
+
+ // Line up the key with the top of the graph
+ no_lock -> local_lock [style=invis]
+ local_lock -> lru_lock [style=invis]
+ lru_lock -> hash_lock [style=invis]
+ hash_lock -> remote_lock [style=invis]
+ remote_lock -> local_freelist_check5 [style=invis]
+ remote_lock -> fn___bpf_lru_list_shrink [style=invis]
+
+ // Line up return code nodes at the bottom of the graph
+ fn_htab_lru_map_update_elem -> pad0 [style=invis]
+ pad0 -> pad1 [style=invis]
+ pad1 -> pad2 [style=invis]
+ //pad2-> fn_htab_lru_map_update_elem_ENOMEM [style=invis]
+ fn_htab_lru_map_update_elem4 -> pad3 [style=invis]
+ pad3 -> fn_htab_lru_map_update_elem5 [style=invis]
+ pad3 -> fn_htab_lru_map_update_elem_EBUSY [style=invis]
+ pad3 -> fn_htab_lru_map_update_elem_EEXIST [style=invis]
+ pad3 -> fn_htab_lru_map_update_elem_ENOENT [style=invis]
+
+ // Reduce diagram width by forcing some nodes to appear above others
+ local_freelist_check4 -> fn_htab_lru_map_update_elem3 [style=invis]
+ common_lru_check2 -> pad4 [style=invis]
+ pad4 -> local_freelist_check5 [style=invis]
+}
diff --git a/Documentation/bpf/map_sockmap.rst b/Documentation/bpf/map_sockmap.rst
index cc92047..2d63068 100644
--- a/Documentation/bpf/map_sockmap.rst
+++ b/Documentation/bpf/map_sockmap.rst
@@ -240,11 +240,11 @@
If a program of type ``BPF_PROG_TYPE_SK_MSG`` is run on a ``msg`` it can only
parse data that the (``data``, ``data_end``) pointers have already consumed.
For ``sendmsg()`` hooks this is likely the first scatterlist element. But for
-calls relying on the ``sendpage`` handler (e.g., ``sendfile()``) this will be
-the range (**0**, **0**) because the data is shared with user space and by
-default the objective is to avoid allowing user space to modify data while (or
-after) BPF verdict is being decided. This helper can be used to pull in data
-and to set the start and end pointers to given values. Data will be copied if
+calls relying on MSG_SPLICE_PAGES (e.g., ``sendfile()``) this will be the
+range (**0**, **0**) because the data is shared with user space and by default
+the objective is to avoid allowing user space to modify data while (or after)
+BPF verdict is being decided. This helper can be used to pull in data and to
+set the start and end pointers to given values. Data will be copied if
necessary (i.e., if data was not linear and if start and end pointers do not
point to the same chunk).
diff --git a/Documentation/bpf/prog_cgroup_sockopt.rst b/Documentation/bpf/prog_cgroup_sockopt.rst
index 172f957..1226a94 100644
--- a/Documentation/bpf/prog_cgroup_sockopt.rst
+++ b/Documentation/bpf/prog_cgroup_sockopt.rst
@@ -98,10 +98,65 @@
indicates that the kernel should use BPF's trimmed ``optval``.
When the BPF program returns with the ``optlen`` greater than
-``PAGE_SIZE``, the userspace will receive ``EFAULT`` errno.
+``PAGE_SIZE``, the userspace will receive original kernel
+buffers without any modifications that the BPF program might have
+applied.
Example
=======
+Recommended way to handle BPF programs is as follows:
+
+.. code-block:: c
+
+ SEC("cgroup/getsockopt")
+ int getsockopt(struct bpf_sockopt *ctx)
+ {
+ /* Custom socket option. */
+ if (ctx->level == MY_SOL && ctx->optname == MY_OPTNAME) {
+ ctx->retval = 0;
+ optval[0] = ...;
+ ctx->optlen = 1;
+ return 1;
+ }
+
+ /* Modify kernel's socket option. */
+ if (ctx->level == SOL_IP && ctx->optname == IP_FREEBIND) {
+ ctx->retval = 0;
+ optval[0] = ...;
+ ctx->optlen = 1;
+ return 1;
+ }
+
+ /* optval larger than PAGE_SIZE use kernel's buffer. */
+ if (ctx->optlen > PAGE_SIZE)
+ ctx->optlen = 0;
+
+ return 1;
+ }
+
+ SEC("cgroup/setsockopt")
+ int setsockopt(struct bpf_sockopt *ctx)
+ {
+ /* Custom socket option. */
+ if (ctx->level == MY_SOL && ctx->optname == MY_OPTNAME) {
+ /* do something */
+ ctx->optlen = -1;
+ return 1;
+ }
+
+ /* Modify kernel's socket option. */
+ if (ctx->level == SOL_IP && ctx->optname == IP_FREEBIND) {
+ optval[0] = ...;
+ return 1;
+ }
+
+ /* optval larger than PAGE_SIZE use kernel's buffer. */
+ if (ctx->optlen > PAGE_SIZE)
+ ctx->optlen = 0;
+
+ return 1;
+ }
+
See ``tools/testing/selftests/bpf/progs/sockopt_sk.c`` for an example
of BPF program that handles socket options.
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 37314af..d4fdf6a 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -74,6 +74,7 @@
"__percpu",
"__rcu",
"__user",
+ "__force",
# include/linux/compiler_attributes.h:
"__alias",
diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst
index f75778d..e6f5bc3 100644
--- a/Documentation/core-api/cpu_hotplug.rst
+++ b/Documentation/core-api/cpu_hotplug.rst
@@ -127,17 +127,8 @@
$ echo 1 > /sys/devices/system/cpu/cpu4/online
smpboot: Booting Node 0 Processor 4 APIC 0x1
-The CPU is usable again. This should work on all CPUs. CPU0 is often special
-and excluded from CPU hotplug. On X86 the kernel option
-*CONFIG_BOOTPARAM_HOTPLUG_CPU0* has to be enabled in order to be able to
-shutdown CPU0. Alternatively the kernel command option *cpu0_hotplug* can be
-used. Some known dependencies of CPU0:
-
-* Resume from hibernate/suspend. Hibernate/suspend will fail if CPU0 is offline.
-* PIC interrupts. CPU0 can't be removed if a PIC interrupt is detected.
-
-Please let Fenghua Yu <fenghua.yu@intel.com> know if you find any dependencies
-on CPU0.
+The CPU is usable again. This should work on all CPUs, but CPU0 is often special
+and excluded from CPU hotplug.
The CPU hotplug coordination
============================
diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst
index 9b3f3e5..f2bcc5a 100644
--- a/Documentation/core-api/kernel-api.rst
+++ b/Documentation/core-api/kernel-api.rst
@@ -96,6 +96,12 @@
.. kernel-doc:: lib/cmdline.c
:export:
+Error Pointers
+--------------
+
+.. kernel-doc:: include/linux/err.h
+ :internal:
+
Sorting
-------
@@ -412,3 +418,15 @@
.. kernel-doc:: include/linux/rcu_sync.h
.. kernel-doc:: kernel/rcu/sync.c
+
+.. kernel-doc:: kernel/rcu/tasks.h
+
+.. kernel-doc:: kernel/rcu/tree_stall.h
+
+.. kernel-doc:: include/linux/rcupdate_trace.h
+
+.. kernel-doc:: include/linux/rcupdate_wait.h
+
+.. kernel-doc:: include/linux/rcuref.h
+
+.. kernel-doc:: include/linux/rcutree.h
diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst
index 9fb0b10..d3c1f6d 100644
--- a/Documentation/core-api/pin_user_pages.rst
+++ b/Documentation/core-api/pin_user_pages.rst
@@ -112,6 +112,12 @@
This also leads to limitations: there are only 31-10==21 bits available for a
counter that increments 10 bits at a time.
+* Because of that limitation, special handling is applied to the zero pages
+ when using FOLL_PIN. We only pretend to pin a zero page - we don't alter its
+ refcount or pincount at all (it is permanent, so there's no need). The
+ unpinning functions also don't do anything to a zero page. This is
+ transparent to the caller.
+
* Callers must specifically request "dma-pinned tracking of pages". In other
words, just calling get_user_pages() will not suffice; a new set of functions,
pin_user_page() and related, must be used.
diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst
index 5cb8b88..91acbcf 100644
--- a/Documentation/core-api/this_cpu_ops.rst
+++ b/Documentation/core-api/this_cpu_ops.rst
@@ -53,7 +53,6 @@
this_cpu_add_return(pcp, val)
this_cpu_xchg(pcp, nval)
this_cpu_cmpxchg(pcp, oval, nval)
- this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, nval2)
this_cpu_sub(pcp, val)
this_cpu_inc(pcp)
this_cpu_dec(pcp)
@@ -242,7 +241,6 @@
__this_cpu_add_return(pcp, val)
__this_cpu_xchg(pcp, nval)
__this_cpu_cmpxchg(pcp, oval, nval)
- __this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, nval2)
__this_cpu_sub(pcp, val)
__this_cpu_inc(pcp)
__this_cpu_dec(pcp)
diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst
index 8ec4d62..a4c9b9d 100644
--- a/Documentation/core-api/workqueue.rst
+++ b/Documentation/core-api/workqueue.rst
@@ -348,6 +348,37 @@
level of locality in wq operations and work item execution.
+Monitoring
+==========
+
+Use tools/workqueue/wq_monitor.py to monitor workqueue operations: ::
+
+ $ tools/workqueue/wq_monitor.py events
+ total infl CPUtime CPUhog CMwake mayday rescued
+ events 18545 0 6.1 0 5 - -
+ events_highpri 8 0 0.0 0 0 - -
+ events_long 3 0 0.0 0 0 - -
+ events_unbound 38306 0 0.1 - - - -
+ events_freezable 0 0 0.0 0 0 - -
+ events_power_efficient 29598 0 0.2 0 0 - -
+ events_freezable_power_ 10 0 0.0 0 0 - -
+ sock_diag_events 0 0 0.0 0 0 - -
+
+ total infl CPUtime CPUhog CMwake mayday rescued
+ events 18548 0 6.1 0 5 - -
+ events_highpri 8 0 0.0 0 0 - -
+ events_long 3 0 0.0 0 0 - -
+ events_unbound 38322 0 0.1 - - - -
+ events_freezable 0 0 0.0 0 0 - -
+ events_power_efficient 29603 0 0.2 0 0 - -
+ events_freezable_power_ 10 0 0.0 0 0 - -
+ sock_diag_events 0 0 0.0 0 0 - -
+
+ ...
+
+See the command's help message for more info.
+
+
Debugging
=========
@@ -387,6 +418,7 @@
The work item's function should be trivially visible in the stack
trace.
+
Non-reentrance Conditions
=========================
diff --git a/Documentation/crypto/async-tx-api.rst b/Documentation/crypto/async-tx-api.rst
index bfc7739..27c146b 100644
--- a/Documentation/crypto/async-tx-api.rst
+++ b/Documentation/crypto/async-tx-api.rst
@@ -66,7 +66,7 @@
::
struct dma_async_tx_descriptor *
- async_<operation>(<op specific parameters>, struct async_submit ctl *submit)
+ async_<operation>(<op specific parameters>, struct async_submit_ctl *submit)
3.2 Supported operations
------------------------
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index e66916a..f4acf9c 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -107,9 +107,12 @@
Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` boot
parameter can be used to control panic and reporting behaviour:
-- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
- report or also panic the kernel (default: ``report``). The panic happens even
- if ``kasan_multi_shot`` is enabled.
+- ``kasan.fault=report``, ``=panic``, or ``=panic_on_write`` controls whether
+ to only print a KASAN report, panic the kernel, or panic the kernel on
+ invalid writes only (default: ``report``). The panic happens even if
+ ``kasan_multi_shot`` is enabled. Note that when using asynchronous mode of
+ Hardware Tag-Based KASAN, ``kasan.fault=panic_on_write`` always panics on
+ asynchronously checked accesses (including reads).
Software and Hardware Tag-Based KASAN modes (see the section about various
modes below) support altering stack trace collection behavior:
diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst
index 12b575b..deede97 100644
--- a/Documentation/dev-tools/kselftest.rst
+++ b/Documentation/dev-tools/kselftest.rst
@@ -36,6 +36,7 @@
To build the tests::
+ $ make headers
$ make -C tools/testing/selftests
To run the tests::
@@ -168,6 +169,28 @@
For other features see the script usage output, seen with the `-h` option.
+Timeout for selftests
+=====================
+
+Selftests are designed to be quick and so a default timeout is used of 45
+seconds for each test. Tests can override the default timeout by adding
+a settings file in their directory and set a timeout variable there to the
+configured a desired upper timeout for the test. Only a few tests override
+the timeout with a value higher than 45 seconds, selftests strives to keep
+it that way. Timeouts in selftests are not considered fatal because the
+system under which a test runs may change and this can also modify the
+expected time it takes to run a test. If you have control over the systems
+which will run the tests you can configure a test runner on those systems to
+use a greater or lower timeout on the command line as with the `-o` or
+the `--override-timeout` argument. For example to use 165 seconds instead
+one would use:
+
+ $ ./run_kselftest.sh --override-timeout 165
+
+You can look at the TAP output to see if you ran into the timeout. Test
+runners which know a test must run under a specific time can then optionally
+treat these timeouts then as fatal.
+
Packaging selftests
===================
diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst
index e95ab05..f335f88 100644
--- a/Documentation/dev-tools/kunit/architecture.rst
+++ b/Documentation/dev-tools/kunit/architecture.rst
@@ -119,9 +119,9 @@
terminated immediately.
- Assertions call the function:
- ``void __noreturn kunit_abort(struct kunit *)``.
+ ``void __noreturn __kunit_abort(struct kunit *)``.
- - ``kunit_abort`` calls the function:
+ - ``__kunit_abort`` calls the function:
``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``.
- ``kunit_try_catch_throw`` calls the function:
diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst
index c736613..a982353 100644
--- a/Documentation/dev-tools/kunit/start.rst
+++ b/Documentation/dev-tools/kunit/start.rst
@@ -250,15 +250,20 @@
};
kunit_test_suite(misc_example_test_suite);
+ MODULE_LICENSE("GPL");
+
2. Add the following lines to ``drivers/misc/Kconfig``:
.. code-block:: kconfig
config MISC_EXAMPLE_TEST
tristate "Test for my example" if !KUNIT_ALL_TESTS
- depends on MISC_EXAMPLE && KUNIT=y
+ depends on MISC_EXAMPLE && KUNIT
default KUNIT_ALL_TESTS
+Note: If your test does not support being built as a loadable module (which is
+discouraged), replace tristate by bool, and depend on KUNIT=y instead of KUNIT.
+
3. Add the following lines to ``drivers/misc/Makefile``:
.. code-block:: make
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index 9faf2b4..c27e164 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -121,6 +121,12 @@
``return`` so they only work from the test function. In KUnit, we stop the
current kthread on failure, so you can call them from anywhere.
+.. note::
+ Warning: There is an exception to the above rule. You shouldn't use assertions
+ in the suite's exit() function, or in the free function for a resource. These
+ run when a test is shutting down, and an assertion here prevents further
+ cleanup code from running, potentially leading to a memory leak.
+
Customizing error messages
--------------------------
@@ -160,7 +166,12 @@
tests, most unit testing frameworks (including KUnit) provide the concept of a
*test suite*. A test suite is a collection of test cases for a unit of code
with optional setup and teardown functions that run before/after the whole
-suite and/or every test case. For example:
+suite and/or every test case.
+
+.. note::
+ A test case will only run if it is associated with a test suite.
+
+For example:
.. code-block:: c
@@ -190,7 +201,10 @@
test suite with the KUnit test framework.
.. note::
- A test case will only run if it is associated with a test suite.
+ The ``exit`` and ``suite_exit`` functions will run even if ``init`` or
+ ``suite_init`` fail. Make sure that they can handle any inconsistent
+ state which may result from ``init`` or ``suite_init`` encountering errors
+ or exiting early.
``kunit_test_suite(...)`` is a macro which tells the linker to put the
specified test suite in a special linker section so that it can be run by KUnit
@@ -601,6 +615,57 @@
KUNIT_ASSERT_STREQ(test, buffer, "");
}
+Registering Cleanup Actions
+---------------------------
+
+If you need to perform some cleanup beyond simple use of ``kunit_kzalloc``,
+you can register a custom "deferred action", which is a cleanup function
+run when the test exits (whether cleanly, or via a failed assertion).
+
+Actions are simple functions with no return value, and a single ``void*``
+context argument, and fulfill the same role as "cleanup" functions in Python
+and Go tests, "defer" statements in languages which support them, and
+(in some cases) destructors in RAII languages.
+
+These are very useful for unregistering things from global lists, closing
+files or other resources, or freeing resources.
+
+For example:
+
+.. code-block:: C
+
+ static void cleanup_device(void *ctx)
+ {
+ struct device *dev = (struct device *)ctx;
+
+ device_unregister(dev);
+ }
+
+ void example_device_test(struct kunit *test)
+ {
+ struct my_device dev;
+
+ device_register(&dev);
+
+ kunit_add_action(test, &cleanup_device, &dev);
+ }
+
+Note that, for functions like device_unregister which only accept a single
+pointer-sized argument, it's possible to directly cast that function to
+a ``kunit_action_t`` rather than writing a wrapper function, for example:
+
+.. code-block:: C
+
+ kunit_add_action(test, (kunit_action_t *)&device_unregister, &dev);
+
+``kunit_add_action`` can fail if, for example, the system is out of memory.
+You can use ``kunit_add_action_or_reset`` instead which runs the action
+immediately if it cannot be deferred.
+
+If you need more control over when the cleanup function is called, you
+can trigger it early using ``kunit_release_action``, or cancel it entirely
+with ``kunit_remove_action``.
+
Testing Static Functions
------------------------
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 274ee08..08d5984 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/amlogic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Amlogic MesonX
+title: Amlogic SoC based Platforms
maintainers:
- Kevin Hilman <khilman@baylibre.com>
@@ -205,6 +205,13 @@
- amlogic,ad401
- const: amlogic,a1
+ - description: Boards with the Amlogic C3 C302X/C308L SoC
+ items:
+ - enum:
+ - amlogic,aw409
+ - amlogic,aw419
+ - const: amlogic,c3
+
- description: Boards with the Amlogic Meson S4 S805X2 SoC
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
index 0c5b875..d6c84b6 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
@@ -287,7 +287,7 @@
arm,trig-in-sigs = <0 1>;
arm,trig-in-types = <PE_DBGTRIGGER
PE_PMUIRQ>;
- arm,trig-out-sigs=<0 1 2 >;
+ arm,trig-out-sigs = <0 1 2 >;
arm,trig-out-types = <PE_EDBGREQ
PE_DBGRESTART
PE_CTIIRQ>;
@@ -309,24 +309,24 @@
trig-conns@0 {
reg = <0>;
- arm,trig-in-sigs=<0>;
- arm,trig-in-types=<GEN_INTREQ>;
- arm,trig-out-sigs=<0>;
- arm,trig-out-types=<GEN_HALTREQ>;
+ arm,trig-in-sigs = <0>;
+ arm,trig-in-types = <GEN_INTREQ>;
+ arm,trig-out-sigs = <0>;
+ arm,trig-out-types = <GEN_HALTREQ>;
arm,trig-conn-name = "sys_profiler";
};
trig-conns@1 {
reg = <1>;
- arm,trig-out-sigs=<2 3>;
- arm,trig-out-types=<GEN_HALTREQ GEN_RESTARTREQ>;
+ arm,trig-out-sigs = <2 3>;
+ arm,trig-out-types = <GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "watchdog";
};
trig-conns@2 {
reg = <2>;
- arm,trig-in-sigs=<1 6>;
- arm,trig-in-types=<GEN_HALTREQ GEN_RESTARTREQ>;
+ arm,trig-in-sigs = <1 6>;
+ arm,trig-in-types = <GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "g_counter";
};
};
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
new file mode 100644
index 0000000..cb78cfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,coresight-dummy-sink.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Coresight Dummy sink component
+
+description: |
+ CoreSight components are compliant with the ARM CoreSight architecture
+ specification and can be connected in various topologies to suit a particular
+ SoCs tracing needs. These trace components can generally be classified as
+ sinks, links and sources. Trace data produced by one or more sources flows
+ through the intermediate links connecting the source to the currently selected
+ sink.
+
+ The Coresight dummy sink component is for the specific coresight sink devices
+ kernel don't have permission to access or configure, e.g., CoreSight EUD on
+ Qualcomm platforms. It is a mini-USB hub implemented to support the USB-based
+ debug and trace capabilities. For this device, a dummy driver is needed to
+ register it as Coresight sink device in kernel side, so that path can be
+ created in the driver. Then the trace flow would be transferred to EUD via
+ coresight link of AP processor. It provides Coresight API for operations on
+ dummy source devices, such as enabling and disabling them. It also provides
+ the Coresight dummy source paths for debugging.
+
+ The primary use case of the coresight dummy sink is to build path in kernel
+ side for dummy sink component.
+
+maintainers:
+ - Mike Leach <mike.leach@linaro.org>
+ - Suzuki K Poulose <suzuki.poulose@arm.com>
+ - James Clark <james.clark@arm.com>
+ - Mao Jinlong <quic_jinlmao@quicinc.com>
+ - Hao Zhang <quic_hazha@quicinc.com>
+
+properties:
+ compatible:
+ enum:
+ - arm,coresight-dummy-sink
+
+ in-ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port:
+ description: Input connection from the Coresight Trace bus to
+ dummy sink, such as Embedded USB debugger(EUD).
+
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - in-ports
+
+additionalProperties: false
+
+examples:
+ # Minimum dummy sink definition. Dummy sink connect to coresight replicator.
+ - |
+ sink {
+ compatible = "arm,coresight-dummy-sink";
+
+ in-ports {
+ port {
+ eud_in_replicator_swao: endpoint {
+ remote-endpoint = <&replicator_swao_out_eud>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
new file mode 100644
index 0000000..5fedaed
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,coresight-dummy-source.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Coresight Dummy source component
+
+description: |
+ CoreSight components are compliant with the ARM CoreSight architecture
+ specification and can be connected in various topologies to suit a particular
+ SoCs tracing needs. These trace components can generally be classified as
+ sinks, links and sources. Trace data produced by one or more sources flows
+ through the intermediate links connecting the source to the currently selected
+ sink.
+
+ The Coresight dummy source component is for the specific coresight source
+ devices kernel don't have permission to access or configure. For some SOCs,
+ there would be Coresight source trace components on sub-processor which
+ are conneted to AP processor via debug bus. For these devices, a dummy driver
+ is needed to register them as Coresight source devices, so that paths can be
+ created in the driver. It provides Coresight API for operations on dummy
+ source devices, such as enabling and disabling them. It also provides the
+ Coresight dummy source paths for debugging.
+
+ The primary use case of the coresight dummy source is to build path in kernel
+ side for dummy source component.
+
+maintainers:
+ - Mike Leach <mike.leach@linaro.org>
+ - Suzuki K Poulose <suzuki.poulose@arm.com>
+ - James Clark <james.clark@arm.com>
+ - Mao Jinlong <quic_jinlmao@quicinc.com>
+ - Hao Zhang <quic_hazha@quicinc.com>
+
+properties:
+ compatible:
+ enum:
+ - arm,coresight-dummy-source
+
+ out-ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port:
+ description: Output connection from the source to Coresight
+ Trace bus.
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - out-ports
+
+additionalProperties: false
+
+examples:
+ # Minimum dummy source definition. Dummy source connect to coresight funnel.
+ - |
+ source {
+ compatible = "arm,coresight-dummy-source";
+
+ out-ports {
+ port {
+ dummy_riscv_out_funnel_swao: endpoint {
+ remote-endpoint = <&funnel_swao_in_dummy_riscv>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
index 09c319f..cdd6588 100644
--- a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
@@ -122,14 +122,14 @@
arm,vexpress,position:
description: When daughterboards are stacked on one site, their position
in the stack be be described this attribute.
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
arm,vexpress,dcc:
description: When describing tiles consisting of more than one DCC, its
number can be specified with this attribute.
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
@@ -180,13 +180,13 @@
- const: simple-bus
arm,v2m-memory-map:
description: This describes the memory map type.
- $ref: '/schemas/types.yaml#/definitions/string'
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- rs1
- rs2
arm,hbi:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: This indicates the ARM HBI (Hardware Board ID), this is
ARM's unique board model ID, visible on the PCB's silkscreen.
@@ -197,7 +197,7 @@
property, describing the physical location of the children nodes.
0 means motherboard site, while 1 and 2 are daughterboard sites, and
0xf means "sisterboard" which is the site containing the main CPU tile.
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
index ab1b352..67a66bf 100644
--- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
@@ -52,100 +52,6 @@
reg = <0xe3804000 0x1000>;
};
-SHDWC Shutdown Controller
-
-required properties:
-- compatible: Should be "atmel,<chip>-shdwc".
- <chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
-- reg: Should contain registers location and length
-- clocks: phandle to input clock.
-
-optional properties:
-- atmel,wakeup-mode: String, operation mode of the wakeup mode.
- Supported values are: "none", "high", "low", "any".
-- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf).
-
-optional at91sam9260 properties:
-- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
-
-optional at91sam9rl properties:
-- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
-- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
-
-optional at91sam9x5 properties:
-- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
-
-Example:
-
- shdwc@fffffd10 {
- compatible = "atmel,at91sam9260-shdwc";
- reg = <0xfffffd10 0x10>;
- clocks = <&clk32k>;
- };
-
-SHDWC SAMA5D2-Compatible Shutdown Controller
-
-1) shdwc node
-
-required properties:
-- compatible: should be "atmel,sama5d2-shdwc", "microchip,sam9x60-shdwc" or
- "microchip,sama7g5-shdwc"
-- reg: should contain registers location and length
-- clocks: phandle to input clock.
-- #address-cells: should be one. The cell is the wake-up input index.
-- #size-cells: should be zero.
-
-optional properties:
-
-- debounce-delay-us: minimum wake-up inputs debouncer period in
- microseconds. It's usually a board-related property.
-- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up.
-
-optional microchip,sam9x60-shdwc or microchip,sama7g5-shdwc properties:
-- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
-
-The node contains child nodes for each wake-up input that the platform uses.
-
-2) input nodes
-
-Wake-up input nodes are usually described in the "board" part of the Device
-Tree. Note also that input 0 is linked to the wake-up pin and is frequently
-used.
-
-Required properties:
-- reg: should contain the wake-up input index [0 - 15].
-
-Optional properties:
-- atmel,wakeup-active-high: boolean, the corresponding wake-up input described
- by the child, forces the wake-up of the core power supply on a high level.
- The default is to be active low.
-
-Example:
-
-On the SoC side:
- shdwc@f8048010 {
- compatible = "atmel,sama5d2-shdwc";
- reg = <0xf8048010 0x10>;
- clocks = <&clk32k>;
- #address-cells = <1>;
- #size-cells = <0>;
- atmel,wakeup-rtc-timer;
- };
-
-On the board side:
- shdwc@f8048010 {
- debounce-delay-us = <976>;
-
- input@0 {
- reg = <0>;
- };
-
- input@1 {
- reg = <1>;
- atmel,wakeup-active-high;
- };
- };
-
Special Function Registers (SFR)
Special Function Registers (SFR) manage specific aspects of the integrated
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
index 454b0e9..5c3ac97e 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
@@ -25,13 +25,15 @@
- enum:
- asus,rt-ac56u
- asus,rt-ac68u
+ - buffalo,wzr-1166dhp
+ - buffalo,wzr-1166dhp2
- buffalo,wzr-1750dhp
- linksys,ea6300-v1
- linksys,ea6500-v2
- - luxul,xap-1510v1
+ - luxul,xap-1510-v1
- luxul,xwc-1000
- - netgear,r6250v1
- - netgear,r6300v2
+ - netgear,r6250-v1
+ - netgear,r6300-v2
- smartrg,sr400ac
- brcm,bcm94708
- const: brcm,bcm4708
@@ -42,8 +44,8 @@
- asus,rt-n18u
- buffalo,wzr-600dhp2
- buffalo,wzr-900dhp
- - luxul,xap-1410v1
- - luxul,xwr-1200v1
+ - luxul,xap-1410-v1
+ - luxul,xwr-1200-v1
- tplink,archer-c5-v2
- const: brcm,bcm47081
- const: brcm,bcm4708
@@ -72,7 +74,7 @@
- luxul,xap-1610-v1
- luxul,xbr-4500-v1
- luxul,xwc-2000-v1
- - luxul,xwr-3100v1
+ - luxul,xwr-3100-v1
- luxul,xwr-3150-v1
- netgear,r8500
- phicomm,k3
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index ff272e5..9e6a45e 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -153,6 +153,7 @@
- arm,cortex-r4
- arm,cortex-r5
- arm,cortex-r7
+ - arm,cortex-r52
- arm,cortex-x1
- arm,cortex-x1c
- arm,cortex-x2
@@ -196,7 +197,7 @@
- qcom,scorpion
enable-method:
- $ref: '/schemas/types.yaml#/definitions/string'
+ $ref: /schemas/types.yaml#/definitions/string
oneOf:
# On ARM v8 64-bit this property is required
- enum:
@@ -245,8 +246,8 @@
cpu-release-addr:
oneOf:
- - $ref: '/schemas/types.yaml#/definitions/uint32'
- - $ref: '/schemas/types.yaml#/definitions/uint64'
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - $ref: /schemas/types.yaml#/definitions/uint64
description:
The DT specification defines this as 64-bit always, but some 32-bit Arm
systems have used a 32-bit value which must be supported.
@@ -254,7 +255,7 @@
property value of "spin-table".
cpu-idle-states:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
maxItems: 1
description: |
@@ -270,7 +271,7 @@
cci-control-port: true
dynamic-power-coefficient:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
A u32 value that represents the running time dynamic
power coefficient in units of uW/MHz/V^2. The
@@ -307,7 +308,7 @@
PM domain provider, must be "psci".
qcom,saw:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: |
Specifies the SAW* node associated with this CPU.
@@ -317,7 +318,7 @@
* arm/msm/qcom,saw2.txt
qcom,acc:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: |
Specifies the ACC* node associated with this CPU.
@@ -328,7 +329,7 @@
* arm/msm/qcom,kpss-acc.txt
rockchip,pmu:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: |
Specifies the syscon node controlling the cpu core power domains.
@@ -338,7 +339,7 @@
the cpu-core power-domains.
secondary-boot-reg:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Required for systems that have an "enable-method" property value of
"brcm,bcm11351-cpu-method", "brcm,bcm23550" or "brcm,bcm-nsp-smp".
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 15d4110..2510eaa 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -726,6 +726,12 @@
- const: dh,imx6ull-dhcor-som
- const: fsl,imx6ull
+ - description: i.MX6ULL DHCOR SoM based Boards
+ items:
+ - const: marantec,imx6ull-dhcor-maveo-box
+ - const: dh,imx6ull-dhcor-som
+ - const: fsl,imx6ull
+
- description: i.MX6ULL PHYTEC phyBOARD-Segin
items:
- enum:
@@ -901,6 +907,7 @@
- emtrion,emcon-mx8mm-avari # emCON-MX8MM SoM on Avari Base
- fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board
- fsl,imx8mm-evk # i.MX8MM EVK Board
+ - fsl,imx8mm-evkb # i.MX8MM EVKB Board
- gateworks,imx8mm-gw7904
- gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit
- gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit
@@ -918,6 +925,12 @@
- prt,prt8mm # i.MX8MM Protonic PRT8MM Board
- const: fsl,imx8mm
+ - description: Emtop i.MX8MM based Boards
+ items:
+ - const: ees,imx8mm-emtop-baseboard # i.MX8MM Emtop SoM on i.MX8M Mini Baseboard V1
+ - const: ees,imx8mm-emtop-som # i.MX8MM Emtop SOM-IMX8MMLPD4 module
+ - const: fsl,imx8mm
+
- description: Engicam i.Core MX8M Mini SoM based boards
items:
- enum:
@@ -1019,6 +1032,7 @@
- dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC
- fsl,imx8mp-evk # i.MX8MP EVK Board
- gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board
+ - gateworks,imx8mp-gw7905-2x # i.MX8MP Gateworks Board
- polyhex,imx8mp-debix # Polyhex Debix boards
- polyhex,imx8mp-debix-model-a # Polyhex Debix Model A Board
- toradex,verdin-imx8mp # Verdin iMX8M Plus Modules
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
index 91b9606..86b59de 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -96,8 +96,8 @@
compatible = "ti,k2g-sci";
ti,system-reboot-controller;
mbox-names = "rx", "tx";
- mboxes= <&msgmgr 5 2>,
- <&msgmgr 0 0>;
+ mboxes = <&msgmgr 5 2>,
+ <&msgmgr 0 0>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
};
@@ -107,8 +107,8 @@
compatible = "ti,k2g-sci";
ti,host-id = <12>;
mbox-names = "rx", "tx";
- mboxes= <&secure_proxy_main 11>,
- <&secure_proxy_main 13>;
+ mboxes = <&secure_proxy_main 11>,
+ <&secure_proxy_main 13>;
reg-names = "debug_messages";
reg = <0x44083000 0x1000>;
diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml
deleted file mode 100644
index 6871483..0000000
--- a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml
+++ /dev/null
@@ -1,36 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/arm/npcm/npcm.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: NPCM Platforms
-
-maintainers:
- - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
- - Tomer Maimon <tmaimon77@gmail.com>
-
-properties:
- $nodename:
- const: '/'
- compatible:
- oneOf:
- - description: WPCM450 based boards
- items:
- - enum:
- - supermicro,x9sci-ln4f-bmc # Supermicro X9SCI-LN4F server's BMC
- - const: nuvoton,wpcm450
-
- - description: NPCM750 based boards
- items:
- - enum:
- - nuvoton,npcm750-evb # NPCM750 evaluation board
- - const: nuvoton,npcm750
-
- - description: NPCM845 based boards
- items:
- - enum:
- - nuvoton,npcm845-evb # NPCM845 evaluation board
- - const: nuvoton,npcm845
-
-additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml b/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml
deleted file mode 100644
index 94e72f2..0000000
--- a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml
+++ /dev/null
@@ -1,50 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/arm/npcm/nuvoton,gcr.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Global Control Registers block in Nuvoton SoCs
-
-maintainers:
- - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
- - Tomer Maimon <tmaimon77@gmail.com>
-
-description:
- The Global Control Registers (GCR) are a block of registers in Nuvoton SoCs
- that expose misc functionality such as chip model and version information or
- pinmux settings.
-
-properties:
- compatible:
- items:
- - enum:
- - nuvoton,wpcm450-gcr
- - nuvoton,npcm750-gcr
- - nuvoton,npcm845-gcr
- - const: syscon
- - const: simple-mfd
-
- reg:
- maxItems: 1
-
-required:
- - compatible
- - reg
-
-additionalProperties:
- type: object
-
-examples:
- - |
- gcr: syscon@800000 {
- compatible = "nuvoton,npcm750-gcr", "syscon", "simple-mfd";
- reg = <0x800000 0x1000>;
-
- mux-controller {
- compatible = "mmio-mux";
- #mux-control-cells = <1>;
- mux-reg-masks = <0x38 0x07>;
- idle-states = <2>;
- };
- };
diff --git a/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml
new file mode 100644
index 0000000..fb190db
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/nuvoton/nuvoton,ma35d1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35 series SoC based platforms
+
+maintainers:
+ - Jacky Huang <ychuang3@nuvoton.com>
+
+description: |
+ Boards with an ARMv8 based Nuvoton MA35 series SoC shall have
+ the following properties.
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+
+ - description: MA35D1 based boards
+ items:
+ - enum:
+ - nuvoton,ma35d1-iot
+ - nuvoton,ma35d1-som
+ - const: nuvoton,ma35d1
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,npcm.yaml b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,npcm.yaml
new file mode 100644
index 0000000..d386744
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,npcm.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/nuvoton/nuvoton,npcm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NPCM Platforms
+
+maintainers:
+ - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
+ - Tomer Maimon <tmaimon77@gmail.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: WPCM450 based boards
+ items:
+ - enum:
+ - supermicro,x9sci-ln4f-bmc # Supermicro X9SCI-LN4F server's BMC
+ - const: nuvoton,wpcm450
+
+ - description: NPCM750 based boards
+ items:
+ - enum:
+ - nuvoton,npcm750-evb # NPCM750 evaluation board
+ - const: nuvoton,npcm750
+
+ - description: NPCM845 based boards
+ items:
+ - enum:
+ - nuvoton,npcm845-evb # NPCM845 evaluation board
+ - const: nuvoton,npcm845
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml
index 3a2c908..0c5381e 100644
--- a/Documentation/devicetree/bindings/arm/psci.yaml
+++ b/Documentation/devicetree/bindings/arm/psci.yaml
@@ -100,7 +100,7 @@
patternProperties:
"^power-domain-":
- $ref: "../power/power-domain.yaml#"
+ $ref: /schemas/power/power-domain.yaml#
type: object
description: |
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d9dd256..450f616 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -40,6 +40,7 @@
msm8939
msm8953
msm8956
+ msm8960
msm8974
msm8976
msm8992
@@ -69,6 +70,7 @@
sdm845
sdx55
sdx65
+ sdx75
sm4250
sm6115
sm6115p
@@ -85,9 +87,15 @@
The 'board' element must be one of the following strings:
adp
+ ap-al02-c2
+ ap-al02-c6
ap-al02-c7
+ ap-al02-c8
+ ap-al02-c9
ap-mi01.2
+ ap-mi01.3
ap-mi01.6
+ ap-mi01.9
cdp
cp01-c1
dragonboard
@@ -191,6 +199,7 @@
- items:
- enum:
- qcom,msm8960-cdp
+ - samsung,expressatt
- const: qcom,msm8960
- items:
@@ -333,7 +342,9 @@
- items:
- enum:
- qcom,ipq5332-ap-mi01.2
+ - qcom,ipq5332-ap-mi01.3
- qcom,ipq5332-ap-mi01.6
+ - qcom,ipq5332-ap-mi01.9
- const: qcom,ipq5332
- items:
@@ -351,7 +362,11 @@
- items:
- enum:
+ - qcom,ipq9574-ap-al02-c2
+ - qcom,ipq9574-ap-al02-c6
- qcom,ipq9574-ap-al02-c7
+ - qcom,ipq9574-ap-al02-c8
+ - qcom,ipq9574-ap-al02-c9
- const: qcom,ipq9574
- description: Sierra Wireless MangOH Green with WP8548 Module
@@ -380,9 +395,9 @@
- qcom,qru1000-idp
- const: qcom,qru1000
- - description: Qualcomm Technologies, Inc. SC7180 IDP
- items:
+ - items:
- enum:
+ - acer,aspire1
- qcom,sc7180-idp
- const: qcom,sc7180
@@ -821,6 +836,11 @@
- items:
- enum:
+ - qcom,sdx75-idp
+ - const: qcom,sdx75
+
+ - items:
+ - enum:
- qcom,ipq6018-cp01
- qcom,ipq6018-cp01-c1
- const: qcom,ipq6018
@@ -884,6 +904,11 @@
- items:
- enum:
+ - fxtec,pro1x
+ - const: qcom,sm6115
+
+ - items:
+ - enum:
- lenovo,j606f
- const: qcom,sm6115p
- const: qcom,sm6115
@@ -1042,6 +1067,7 @@
- qcom,sdm845
- qcom,sdx55
- qcom,sdx65
+ - qcom,sdx75
- qcom,sm4250
- qcom,sm6115
- qcom,sm6125
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ec141c9..ecdb72a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -40,6 +40,11 @@
- const: anbernic,rg353p
- const: rockchip,rk3566
+ - description: Anbernic RG353PS
+ items:
+ - const: anbernic,rg353ps
+ - const: rockchip,rk3566
+
- description: Anbernic RG353V
items:
- const: anbernic,rg353v
@@ -102,6 +107,12 @@
- const: edgeble,neural-compute-module-6a # Edgeble Neural Compute Module 6A SoM
- const: rockchip,rk3588
+ - description: Edgeble Neural Compute Module 6(Neu6) Model B SoM based boards
+ items:
+ - const: edgeble,neural-compute-module-6b-io # Edgeble Neural Compute Module 6B IO Board
+ - const: edgeble,neural-compute-module-6b # Edgeble Neural Compute Module 6B SoM
+ - const: rockchip,rk3588
+
- description: Elgin RV1108 R1
items:
- const: elgin,rv1108-r1
@@ -189,6 +200,7 @@
items:
- enum:
- friendlyarm,nanopi-r2c
+ - friendlyarm,nanopi-r2c-plus
- friendlyarm,nanopi-r2s
- const: rockchip,rk3328
@@ -534,6 +546,11 @@
- const: hugsun,x99
- const: rockchip,rk3399
+ - description: Indiedroid Nova SBC
+ items:
+ - const: indiedroid,nova
+ - const: rockchip,rk3588s
+
- description: Khadas Edge series boards
items:
- enum:
@@ -562,6 +579,13 @@
- const: leez,p710
- const: rockchip,rk3399
+ - description: Lunzn FastRhino R66S / R68S
+ items:
+ - enum:
+ - lunzn,fastrhino-r66s
+ - lunzn,fastrhino-r68s
+ - const: rockchip,rk3568
+
- description: mqmaker MiQi
items:
- const: mqmaker,miqi
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
index deb2cf9..e3ffd81 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
@@ -72,6 +72,16 @@
- const: samsung,exynos4210
- const: samsung,exynos4
+ - description: Samsung Galaxy Tab3 family boards
+ items:
+ - enum:
+ - samsung,t310 # Samsung Galaxy Tab 3 8.0 WiFi (SM-T310)
+ - samsung,t311 # Samsung Galaxy Tab 3 8.0 3G (SM-T311)
+ - samsung,t315 # Samsung Galaxy Tab 3 8.0 LTE (SM-T315)
+ - const: samsung,tab3
+ - const: samsung,exynos4212
+ - const: samsung,exynos4
+
- description: Exynos4412 based boards
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
new file mode 100644
index 0000000..72554a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/socionext/synquacer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext Synquacer platform
+
+maintainers:
+ - Masahisa Kojima <masahisa.kojima@linaro.org>
+ - Jassi Brar <jaswinder.singh@linaro.org>
+
+description:
+ Socionext SC2A11B (Synquacer) SoC based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - socionext,developer-box
+ - const: socionext,synquacer
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
index ad8e51a..b63ff59 100644
--- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
@@ -15,12 +15,13 @@
oneOf:
- items:
- enum:
- - st,stm32mp157-syscfg
- - st,stm32mp151-pwr-mcu
- - st,stm32-syscfg
- st,stm32-power-config
+ - st,stm32-syscfg
- st,stm32-tamp
- st,stm32f4-gcan
+ - st,stm32mp151-pwr-mcu
+ - st,stm32mp157-syscfg
+ - st,stm32mp25-syscfg
- const: syscon
- items:
- const: st,stm32-tamp
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
index 13e3424..4466b45 100644
--- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -155,6 +155,18 @@
- const: seeed,stm32mp157c-odyssey-som
- const: st,stm32mp157
+ - description: Phytec STM32MP1 SoM based Boards
+ items:
+ - const: phytec,phycore-stm32mp1-3
+ - const: phytec,phycore-stm32mp157c-som
+ - const: st,stm32mp157
+
+ - description: ST STM32MP257 based Boards
+ items:
+ - enum:
+ - st,stm32mp257f-ev1
+ - const: st,stm32mp257
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 013821f..ee8fdd2 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -305,6 +305,12 @@
- const: allwinner,i12-tvbox
- const: allwinner,sun7i-a20
+ - description: ICnova A20 ADB4006
+ items:
+ - const: incircuit,icnova-a20-adb4006
+ - const: incircuit,icnova-a20
+ - const: allwinner,sun7i-a20
+
- description: ICNova A20 SWAC
items:
- const: incircuit,icnova-a20-swac
diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
index 0df41f5..fcf95640 100644
--- a/Documentation/devicetree/bindings/arm/tegra.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra.yaml
@@ -167,6 +167,11 @@
- const: nvidia,p3737-0000+p3701-0000
- const: nvidia,p3701-0000
- const: nvidia,tegra234
+ - description: NVIDIA IGX Orin Development Kit
+ items:
+ - const: nvidia,p3740-0002+p3701-0008
+ - const: nvidia,p3701-0008
+ - const: nvidia,tegra234
- description: Jetson Orin NX
items:
- const: nvidia,p3767-0000
@@ -176,5 +181,14 @@
- const: nvidia,p3768-0000+p3767-0000
- const: nvidia,p3767-0000
- const: nvidia,tegra234
+ - description: Jetson Orin Nano
+ items:
+ - const: nvidia,p3767-0005
+ - const: nvidia,tegra234
+ - description: Jetson Orin Nano Developer Kit
+ items:
+ - const: nvidia,p3768-0000+p3767-0005
+ - const: nvidia,p3767-0005
+ - const: nvidia,tegra234
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index e1183f9..577eee9 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -25,6 +25,12 @@
- ti,am62a7-sk
- const: ti,am62a7
+ - description: K3 AM625 SoC PHYTEC phyBOARD-Lyra
+ items:
+ - const: phytec,am625-phyboard-lyra-rdk
+ - const: phytec,am62-phycore-som
+ - const: ti,am625
+
- description: K3 AM625 SoC
items:
- enum:
@@ -33,6 +39,26 @@
- ti,am62-lp-sk
- const: ti,am625
+ - description: K3 AM62x SoC Toradex Verdin Modules and Carrier Boards
+ items:
+ - enum:
+ - toradex,verdin-am62-nonwifi-dahlia # Verdin AM62 Module on Dahlia
+ - toradex,verdin-am62-nonwifi-dev # Verdin AM62 Module on Verdin Development Board
+ - toradex,verdin-am62-nonwifi-yavia # Verdin AM62 Module on Yavia
+ - const: toradex,verdin-am62-nonwifi # Verdin AM62 Module without Wi-Fi / BT
+ - const: toradex,verdin-am62 # Verdin AM62 Module
+ - const: ti,am625
+
+ - description: K3 AM62x SoC Toradex Verdin Modules and Carrier Boards with Wi-Fi / BT
+ items:
+ - enum:
+ - toradex,verdin-am62-wifi-dahlia # Verdin AM62 Wi-Fi / BT Module on Dahlia
+ - toradex,verdin-am62-wifi-dev # Verdin AM62 Wi-Fi / BT M. on Verdin Development B.
+ - toradex,verdin-am62-wifi-yavia # Verdin AM62 Wi-Fi / BT Module on Yavia
+ - const: toradex,verdin-am62-wifi # Verdin AM62 Wi-Fi / BT Module
+ - const: toradex,verdin-am62 # Verdin AM62 Module
+ - const: ti,am625
+
- description: K3 AM642 SoC
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 61d77ac..f925290 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -56,7 +56,7 @@
};
The format and meaning of the "xen,uefi-*" parameters are similar to those in
-Documentation/arm/uefi.rst, which are provided by the regular UEFI stub. However
+Documentation/arch/arm/uefi.rst, which are provided by the regular UEFI stub. However
they differ because they are provided by the Xen hypervisor, together with a set
of UEFI runtime services implemented via hypercalls, see
http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml b/Documentation/devicetree/bindings/arm/xilinx.yaml
index 969cfe6..f57ed03 100644
--- a/Documentation/devicetree/bindings/arm/xilinx.yaml
+++ b/Documentation/devicetree/bindings/arm/xilinx.yaml
@@ -7,7 +7,7 @@
title: Xilinx Zynq Platforms
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
description: |
Xilinx boards with Zynq-7000 SOC or Zynq UltraScale+ MPSoC
@@ -61,10 +61,10 @@
- const: xlnx,zynqmp-zc1254
- const: xlnx,zynqmp
- - description: Xilinx internal board zc1275
+ - description: Xilinx evaluation board zcu1275
items:
- - const: xlnx,zynqmp-zc1275-revA
- - const: xlnx,zynqmp-zc1275
+ - const: xlnx,zynqmp-zcu1275-revA
+ - const: xlnx,zynqmp-zcu1275
- const: xlnx,zynqmp
- description: Xilinx 96boards compatible board zcu100
diff --git a/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml
index 71364c60..b29ce59 100644
--- a/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml
+++ b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml
@@ -7,7 +7,7 @@
title: Ceva AHCI SATA Controller
maintainers:
- - Piyush Mehta <piyush.mehta@xilinx.com>
+ - Piyush Mehta <piyush.mehta@amd.com>
description: |
The Ceva SATA controller mostly conforms to the AHCI interface with some
diff --git a/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
new file mode 100644
index 0000000..b5e5767
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/rockchip,dwc-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DWC AHCI SATA controller for Rockchip devices
+
+maintainers:
+ - Serge Semin <fancer.lancer@gmail.com>
+
+description:
+ This document defines device tree bindings for the Synopsys DWC
+ implementation of the AHCI SATA controller found in Rockchip
+ devices.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3568-dwc-ahci
+ - rockchip,rk3588-dwc-ahci
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - rockchip,rk3568-dwc-ahci
+ - rockchip,rk3588-dwc-ahci
+ - const: snps,dwc-ahci
+
+ ports-implemented:
+ const: 1
+
+ sata-port@0:
+ $ref: /schemas/ata/snps,dwc-ahci-common.yaml#/$defs/dwc-ahci-port
+
+ properties:
+ reg:
+ const: 0
+
+ unevaluatedProperties: false
+
+patternProperties:
+ "^sata-port@[1-9a-e]$": false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ports-implemented
+
+allOf:
+ - $ref: snps,dwc-ahci-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3588-dwc-ahci
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ items:
+ - const: sata
+ - const: pmalive
+ - const: rxoob
+ - const: ref
+ - const: asic
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3568-dwc-ahci
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: sata
+ - const: pmalive
+ - const: rxoob
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/ata/ahci.h>
+ #include <dt-bindings/phy/phy.h>
+
+ sata@fe210000 {
+ compatible = "rockchip,rk3588-dwc-ahci", "snps,dwc-ahci";
+ reg = <0xfe210000 0x1000>;
+ clocks = <&cru ACLK_SATA0>, <&cru CLK_PMALIVE0>,
+ <&cru CLK_RXOOB0>, <&cru CLK_PIPEPHY0_REF>,
+ <&cru CLK_PIPEPHY0_PIPE_ASIC_G>;
+ clock-names = "sata", "pmalive", "rxoob", "ref", "asic";
+ interrupts = <GIC_SPI 273 IRQ_TYPE_LEVEL_HIGH 0>;
+ ports-implemented = <0x1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata-port@0 {
+ reg = <0>;
+ hba-port-cap = <HBA_PORT_FBSCP>;
+ phys = <&combphy0_ps PHY_TYPE_SATA>;
+ phy-names = "sata-phy";
+ snps,rx-ts-max = <32>;
+ snps,tx-ts-max = <32>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml b/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml
index c145791..34c5bf65 100644
--- a/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml
+++ b/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml
@@ -31,11 +31,11 @@
PM-alive clock, RxOOB detection clock, embedded PHYs reference (Rx/Tx)
clock, etc.
minItems: 1
- maxItems: 4
+ maxItems: 6
clock-names:
minItems: 1
- maxItems: 4
+ maxItems: 6
items:
oneOf:
- description: Application APB/AHB/AXI BIU clock
@@ -48,6 +48,10 @@
const: pmalive
- description: RxOOB detection clock
const: rxoob
+ - description: PHY Transmit Clock
+ const: asic
+ - description: PHY Receive Clock
+ const: rbc
- description: SATA Ports reference clock
const: ref
diff --git a/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
index 5afa4b5..4c848fc 100644
--- a/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
+++ b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
@@ -13,6 +13,15 @@
This document defines device tree bindings for the generic Synopsys DWC
implementation of the AHCI SATA controller.
+select:
+ properties:
+ compatible:
+ enum:
+ - snps,dwc-ahci
+ - snps,spear-ahci
+ required:
+ - compatible
+
allOf:
- $ref: snps,dwc-ahci-common.yaml#
@@ -23,10 +32,6 @@
const: snps,dwc-ahci
- description: SPEAr1340 AHCI SATA device
const: snps,spear-ahci
- - description: Rockhip RK3568 AHCI controller
- items:
- - const: rockchip,rk3568-dwc-ahci
- - const: snps,dwc-ahci
patternProperties:
"^sata-port@[0-9a-e]$":
diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
index 49304a1..be95f6b 100644
--- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
+++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
@@ -40,6 +40,7 @@
linux,keymap: true
linux,no-autorepeat:
+ type: boolean
description: Disable keyrepeat
default-brightness-level:
diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.yaml b/Documentation/devicetree/bindings/bus/ti-sysc.yaml
index f089634..6d7bca6 100644
--- a/Documentation/devicetree/bindings/bus/ti-sysc.yaml
+++ b/Documentation/devicetree/bindings/bus/ti-sysc.yaml
@@ -97,7 +97,7 @@
- enum: [ ick, fck, sys_clk ]
- items:
- const: fck
- - enum: [ ick. dbclk, osc, sys_clk, dss_clk, ahclkx ]
+ - enum: [ ick, dbclk, osc, sys_clk, dss_clk, ahclkx ]
- items:
- const: fck
- const: phy-clk
diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
new file mode 100644
index 0000000..6d84cee
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,a1-peripherals-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic A1 Peripherals Clock Control Unit
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Jerome Brunet <jbrunet@baylibre.com>
+ - Jian Hu <jian.hu@jian.hu.com>
+ - Dmitry Rokosov <ddrokosov@sberdevices.ru>
+
+properties:
+ compatible:
+ const: amlogic,a1-peripherals-clkc
+
+ '#clock-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: input fixed pll div2
+ - description: input fixed pll div3
+ - description: input fixed pll div5
+ - description: input fixed pll div7
+ - description: input hifi pll
+ - description: input oscillator (usually at 24MHz)
+
+ clock-names:
+ items:
+ - const: fclk_div2
+ - const: fclk_div3
+ - const: fclk_div5
+ - const: fclk_div7
+ - const: hifi_pll
+ - const: xtal
+
+required:
+ - compatible
+ - '#clock-cells'
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/amlogic,a1-pll-clkc.h>
+ apb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@800 {
+ compatible = "amlogic,a1-peripherals-clkc";
+ reg = <0 0x800 0 0x104>;
+ #clock-cells = <1>;
+ clocks = <&clkc_pll CLKID_FCLK_DIV2>,
+ <&clkc_pll CLKID_FCLK_DIV3>,
+ <&clkc_pll CLKID_FCLK_DIV5>,
+ <&clkc_pll CLKID_FCLK_DIV7>,
+ <&clkc_pll CLKID_HIFI_PLL>,
+ <&xtal>;
+ clock-names = "fclk_div2", "fclk_div3",
+ "fclk_div5", "fclk_div7",
+ "hifi_pll", "xtal";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
new file mode 100644
index 0000000..a59b188
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,a1-pll-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic A1 PLL Clock Control Unit
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Jerome Brunet <jbrunet@baylibre.com>
+ - Jian Hu <jian.hu@jian.hu.com>
+ - Dmitry Rokosov <ddrokosov@sberdevices.ru>
+
+properties:
+ compatible:
+ const: amlogic,a1-pll-clkc
+
+ '#clock-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: input fixpll_in
+ - description: input hifipll_in
+
+ clock-names:
+ items:
+ - const: fixpll_in
+ - const: hifipll_in
+
+required:
+ - compatible
+ - '#clock-cells'
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/amlogic,a1-peripherals-clkc.h>
+ apb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@7c80 {
+ compatible = "amlogic,a1-pll-clkc";
+ reg = <0 0x7c80 0 0x18c>;
+ #clock-cells = <1>;
+ clocks = <&clkc_periphs CLKID_FIXPLL_IN>,
+ <&clkc_periphs CLKID_HIFIPLL_IN>;
+ clock-names = "fixpll_in", "hifipll_in";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
deleted file mode 100644
index 13f45db..0000000
--- a/Documentation/devicetree/bindings/clock/at91-clock.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-Device Tree Clock bindings for arch-at91
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Slow Clock controller:
-
-Required properties:
-- compatible : shall be one of the following:
- "atmel,at91sam9x5-sckc",
- "atmel,sama5d3-sckc",
- "atmel,sama5d4-sckc" or
- "microchip,sam9x60-sckc":
- at91 SCKC (Slow Clock Controller)
-- #clock-cells : shall be 1 for "microchip,sam9x60-sckc" otherwise shall be 0.
-- clocks : shall be the input parent clock phandle for the clock.
-
-Optional properties:
-- atmel,osc-bypass : boolean property. Set this when a clock signal is directly
- provided on XIN.
-
-For example:
- sckc@fffffe50 {
- compatible = "atmel,at91sam9x5-sckc";
- reg = <0xfffffe50 0x4>;
- clocks = <&slow_xtal>;
- #clock-cells = <0>;
- };
-
-Power Management Controller (PMC):
-
-Required properties:
-- compatible : shall be "atmel,<chip>-pmc", "syscon" or
- "microchip,sam9x60-pmc"
- <chip> can be: at91rm9200, at91sam9260, at91sam9261,
- at91sam9263, at91sam9g45, at91sam9n12, at91sam9rl, at91sam9g15,
- at91sam9g25, at91sam9g35, at91sam9x25, at91sam9x35, at91sam9x5,
- sama5d2, sama5d3 or sama5d4.
-- #clock-cells : from common clock binding; shall be set to 2. The first entry
- is the type of the clock (core, system, peripheral or generated) and the
- second entry its index as provided by the datasheet
-- clocks : Must contain an entry for each entry in clock-names.
-- clock-names: Must include the following entries: "slow_clk", "main_xtal"
-
-Optional properties:
-- atmel,osc-bypass : boolean property. Set this when a clock signal is directly
- provided on XIN.
-
-For example:
- pmc: pmc@f0018000 {
- compatible = "atmel,sama5d4-pmc", "syscon";
- reg = <0xf0018000 0x120>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
- #clock-cells = <2>;
- clocks = <&clk32k>, <&main_xtal>;
- clock-names = "slow_clk", "main_xtal";
- };
diff --git a/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml
new file mode 100644
index 0000000..c1bdcd9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/atmel,at91rm9200-pmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Power Management Controller (PMC)
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description:
+ The power management controller optimizes power consumption by controlling all
+ system and user peripheral clocks. The PMC enables/disables the clock inputs
+ to many of the peripherals and to the processor.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: atmel,at91sam9g20-pmc
+ - const: atmel,at91sam9260-pmc
+ - const: syscon
+ - items:
+ - enum:
+ - atmel,at91sam9g15-pmc
+ - atmel,at91sam9g25-pmc
+ - atmel,at91sam9g35-pmc
+ - atmel,at91sam9x25-pmc
+ - atmel,at91sam9x35-pmc
+ - const: atmel,at91sam9x5-pmc
+ - const: syscon
+ - items:
+ - enum:
+ - atmel,at91rm9200-pmc
+ - atmel,at91sam9260-pmc
+ - atmel,at91sam9g45-pmc
+ - atmel,at91sam9n12-pmc
+ - atmel,at91sam9rl-pmc
+ - atmel,at91sam9x5-pmc
+ - atmel,sama5d2-pmc
+ - atmel,sama5d3-pmc
+ - atmel,sama5d4-pmc
+ - microchip,sam9x60-pmc
+ - microchip,sama7g5-pmc
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#clock-cells":
+ description: |
+ - 1st cell is the clock type, one of PMC_TYPE_CORE, PMC_TYPE_SYSTEM,
+ PMC_TYPE_PERIPHERAL, PMC_TYPE_GCK, PMC_TYPE_PROGRAMMABLE (as defined
+ in <dt-bindings/clock/at91.h>)
+ - 2nd cell is the clock identifier as defined in <dt-bindings/clock/at91.h
+ (for core clocks) or as defined in datasheet (for system, peripheral,
+ gck and programmable clocks).
+ const: 2
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ minItems: 2
+ maxItems: 3
+
+ atmel,osc-bypass:
+ description: set when a clock signal is directly provided on XIN
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#clock-cells"
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,sam9x60-pmc
+ - microchip,sama7g5-pmc
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: td_slck
+ - const: md_slck
+ - const: main_xtal
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - atmel,at91rm9200-pmc
+ - atmel,at91sam9260-pmc
+ - atmel,at91sam9g20-pmc
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: slow_xtal
+ - const: main_xtal
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - atmel,sama5d2-pmc
+ - atmel,sama5d3-pmc
+ - atmel,sama5d4-pmc
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: slow_clk
+ - const: main_xtal
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pmc: clock-controller@f0018000 {
+ compatible = "atmel,sama5d4-pmc", "syscon";
+ reg = <0xf0018000 0x120>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ #clock-cells = <2>;
+ clocks = <&clk32k>, <&main_xtal>;
+ clock-names = "slow_clk", "main_xtal";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml b/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml
new file mode 100644
index 0000000..7be2987
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/atmel,at91sam9x5-sckc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Slow Clock Controller (SCKC)
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - atmel,at91sam9x5-sckc
+ - atmel,sama5d3-sckc
+ - atmel,sama5d4-sckc
+ - microchip,sam9x60-sckc
+ - items:
+ - const: microchip,sama7g5-sckc
+ - const: microchip,sam9x60-sckc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ enum: [0, 1]
+
+ atmel,osc-bypass:
+ type: boolean
+ description: set when a clock signal is directly provided on XIN
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,sam9x60-sckc
+ then:
+ properties:
+ "#clock-cells":
+ const: 1
+ else:
+ properties:
+ "#clock-cells":
+ const: 0
+
+additionalProperties: false
+
+examples:
+ - |
+ clk32k: clock-controller@fffffe50 {
+ compatible = "microchip,sam9x60-sckc";
+ reg = <0xfffffe50 0x4>;
+ clocks = <&slow_xtal>;
+ #clock-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml
index 199818b..cd0d763 100644
--- a/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/brcm,bcm63268-timer-clocks.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM63268 Timer Clock and Reset Device Tree Bindings
+title: Broadcom BCM63268 Timer Clock and Reset
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
index 0dbc143..80539f8 100644
--- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
@@ -24,6 +24,9 @@
reg:
maxItems: 1
+ interrupts:
+ maxItems: 2
+
clocks:
minItems: 6
maxItems: 7
diff --git a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml
index ff96004..0a6dc1a 100644
--- a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx8mp-audiomix.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX8MP AudioMIX Block Control Binding
+title: NXP i.MX8MP AudioMIX Block Control
maintainers:
- Marek Vasut <marex@denx.de>
diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
index 9e733b1..509df06 100644
--- a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
+++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
@@ -98,9 +98,9 @@
patternProperties:
"^usb-phy@[a-f0-9]+$":
- allOf: [ $ref: "../phy/ingenic,phy-usb.yaml#" ]
+ $ref: /schemas/phy/ingenic,phy-usb.yaml#
"^mac-phy-ctrl@[a-f0-9]+$":
- allOf: [ $ref: "../net/ingenic,mac.yaml#" ]
+ $ref: /schemas/net/ingenic,mac.yaml#
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml
new file mode 100644
index 0000000..ba7ffc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mtmips-sysc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MTMIPS SoCs System Controller
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+description: |
+ MediaTek MIPS and Ralink SoCs provides a system controller to allow
+ to access to system control registers. These registers include clock
+ and reset related ones so this node is both clock and reset provider
+ for the rest of the world.
+
+ These SoCs have an XTAL from where the cpu clock is
+ provided as well as derived clocks for the bus and the peripherals.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - ralink,mt7620-sysc
+ - ralink,mt7628-sysc
+ - ralink,mt7688-sysc
+ - ralink,rt2880-sysc
+ - ralink,rt3050-sysc
+ - ralink,rt3052-sysc
+ - ralink,rt3352-sysc
+ - ralink,rt3883-sysc
+ - ralink,rt5350-sysc
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ description:
+ The first cell indicates the clock number.
+ const: 1
+
+ '#reset-cells':
+ description:
+ The first cell indicates the reset bit within the register.
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@0 {
+ compatible = "ralink,rt5350-sysc", "syscon";
+ reg = <0x0 0x100>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml b/Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml
new file mode 100644
index 0000000..8f0c4368
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nuvoton,ma35d1-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 Clock Controller Module
+
+maintainers:
+ - Chi-Fang Li <cfli0@nuvoton.com>
+ - Jacky Huang <ychuang3@nuvoton.com>
+
+description: |
+ The MA35D1 clock controller generates clocks for the whole chip,
+ including system clocks and all peripheral clocks.
+
+ See also:
+ include/dt-bindings/clock/ma35d1-clk.h
+
+properties:
+ compatible:
+ items:
+ - const: nuvoton,ma35d1-clk
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ nuvoton,pll-mode:
+ description:
+ A list of PLL operation mode corresponding to CAPLL, DDRPLL, APLL,
+ EPLL, and VPLL in sequential.
+ maxItems: 5
+ items:
+ enum:
+ - integer
+ - fractional
+ - spread-spectrum
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+
+ clock-controller@40460200 {
+ compatible = "nuvoton,ma35d1-clk";
+ reg = <0x40460200 0x100>;
+ #clock-cells = <1>;
+ clocks = <&clk_hxt>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
index 659669b..9436266 100644
--- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
@@ -19,6 +19,7 @@
- qcom,ipq5332-a53pll
- qcom,ipq6018-a53pll
- qcom,ipq8074-a53pll
+ - qcom,ipq9574-a73pll
- qcom,msm8916-a53pll
- qcom,msm8939-a53pll
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
new file mode 100644
index 0000000..fe9fd4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8953.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on MSM8953
+
+maintainers:
+ - Adam Skladowski <a_skl39@protonmail.com>
+ - Sireesh Kodali <sireeshkodali@protonmail.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on MSM8953.
+
+ See also: include/dt-bindings/clock/qcom,gcc-msm8953.h
+
+properties:
+ compatible:
+ const: qcom,gcc-msm8953
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: Byte clock from DSI PHY0
+ - description: Pixel clock from DSI PHY0
+ - description: Byte clock from DSI PHY1
+ - description: Pixel clock from DSI PHY1
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: dsi1pll
+ - const: dsi1pllbyte
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+
+ clock-controller@1800000 {
+ compatible = "qcom,gcc-msm8953";
+ reg = <0x01800000 0x80000>;
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&sleep_clk>,
+ <&dsi0_phy 1>,
+ <&dsi0_phy 0>,
+ <&dsi1_phy 1>,
+ <&dsi1_phy 0>;
+ clock-names = "xo",
+ "sleep",
+ "dsi0pll",
+ "dsi0pllbyte",
+ "dsi1pll",
+ "dsi1pllbyte";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml
index ae01e77..ba969e7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml
@@ -30,7 +30,6 @@
enum:
- qcom,gcc-ipq6018
- qcom,gcc-mdm9607
- - qcom,gcc-msm8953
- qcom,gcc-mdm9615
required:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
index 06dce0c..8bf9b6f4 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
@@ -32,6 +32,10 @@
- const: bi_tcxo_ao
- const: sleep_clk
+ power-domains:
+ items:
+ - description: CX domain
+
required:
- compatible
- clocks
@@ -45,6 +49,8 @@
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
clock-controller@100000 {
compatible = "qcom,gcc-sc7180";
reg = <0x00100000 0x1f0000>;
@@ -52,6 +58,7 @@
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
+ power-domains = <&rpmhpd SC7180_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml
index 947b471..ff0b18bb 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml
@@ -43,6 +43,10 @@
- const: ufs_phy_tx_symbol_0_clk
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk
+ power-domains:
+ items:
+ - description: CX domain
+
required:
- compatible
- clocks
@@ -56,6 +60,8 @@
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
clock-controller@100000 {
compatible = "qcom,gcc-sc7280";
reg = <0x00100000 0x1f0000>;
@@ -71,6 +77,7 @@
"pcie_1_pipe_clk", "ufs_phy_rx_symbol_0_clk",
"ufs_phy_rx_symbol_1_clk", "ufs_phy_tx_symbol_0_clk",
"usb3_phy_wrapper_gcc_usb30_pipe_clk";
+ power-domains = <&rpmhpd SC7280_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
index b752542..ead6665 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
@@ -23,11 +23,13 @@
clocks:
items:
- description: Board XO source
+ - description: Board active XO source
- description: Sleep clock source
clock-names:
items:
- const: bi_tcxo
+ - const: bi_tcxo_ao
- const: sleep_clk
required:
@@ -47,8 +49,9 @@
compatible = "qcom,gcc-sm8250";
reg = <0x00100000 0x1f0000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
- clock-names = "bi_tcxo", "sleep_clk";
+ clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index 1e3dc9d..a00216b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -50,6 +50,9 @@
- const: gcc_gpu_gpll0_clk_src
- const: gcc_gpu_gpll0_div_clk_src
+ power-domains:
+ maxItems: 1
+
'#clock-cells':
const: 1
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
index afc68eb..944a0ea 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
@@ -7,6 +7,7 @@
title: Qualcomm Global Clock & Reset Controller on IPQ9574
maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
- Anusha Rao <quic_anusha@quicinc.com>
description: |
diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
index acf0c92..422f577 100644
--- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
@@ -31,11 +31,11 @@
- qcom,mmcc-sdm660
clocks:
- minItems: 8
+ minItems: 7
maxItems: 13
clock-names:
- minItems: 8
+ minItems: 7
maxItems: 13
'#clock-cells':
@@ -104,6 +104,34 @@
compatible:
contains:
enum:
+ - qcom,mmcc-msm8226
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: MMSS GPLL0 voted clock
+ - description: GPLL0 voted clock
+ - description: GPLL1 voted clock
+ - description: GFX3D clock source
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: mmss_gpll0_vote
+ - const: gpll0_vote
+ - const: gpll1_vote
+ - const: gfx3d_clk_src
+ - const: dsi0pll
+ - const: dsi0pllbyte
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,mmcc-msm8974
then:
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
index d5a250b..267cf8c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
@@ -27,6 +27,7 @@
- qcom,sdm845-rpmh-clk
- qcom,sdx55-rpmh-clk
- qcom,sdx65-rpmh-clk
+ - qcom,sdx75-rpmh-clk
- qcom,sm6350-rpmh-clk
- qcom,sm8150-rpmh-clk
- qcom,sm8250-rpmh-clk
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
new file mode 100644
index 0000000..3326dcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sc8280xp-lpasscc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm LPASS Core & Audio Clock Controller on SC8280XP
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ Qualcomm LPASS core and audio clock control module provides the clocks,
+ and reset on SC8280XP.
+
+ See also::
+ include/dt-bindings/clock/qcom,lpasscc-sc8280xp.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-lpassaudiocc
+ - qcom,sc8280xp-lpasscc
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sc8280xp-lpasscc.h>
+ lpass_audiocc: clock-controller@32a9000 {
+ compatible = "qcom,sc8280xp-lpassaudiocc";
+ reg = <0x032a9000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ - |
+ #include <dt-bindings/clock/qcom,sc8280xp-lpasscc.h>
+ lpasscc: clock-controller@33e0000 {
+ compatible = "qcom,sc8280xp-lpasscc";
+ reg = <0x033e0000 0x12000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml
new file mode 100644
index 0000000..98921fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sdx75-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on SDX75
+
+maintainers:
+ - Imran Shaik <quic_imrashai@quicinc.com>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SDX75
+
+ See also:: include/dt-bindings/clock/qcom,sdx75-gcc.h
+
+properties:
+ compatible:
+ const: qcom,sdx75-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: EMAC0 sgmiiphy mac rclk source
+ - description: EMAC0 sgmiiphy mac tclk source
+ - description: EMAC0 sgmiiphy rclk source
+ - description: EMAC0 sgmiiphy tclk source
+ - description: EMAC1 sgmiiphy mac rclk source
+ - description: EMAC1 sgmiiphy mac tclk source
+ - description: EMAC1 sgmiiphy rclk source
+ - description: EMAC1 sgmiiphy tclk source
+ - description: PCIE20 phy aux clock source
+ - description: PCIE_1 Pipe clock source
+ - description: PCIE_2 Pipe clock source
+ - description: PCIE Pipe clock source
+ - description: USB3 phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@80000 {
+ compatible = "qcom,sdx75-gcc";
+ reg = <0x80000 0x1f7400>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>, <&emac0_sgmiiphy_mac_rclk>,
+ <&emac0_sgmiiphy_mac_tclk>, <&emac0_sgmiiphy_rclk>, <&emac0_sgmiiphy_tclk>,
+ <&emac1_sgmiiphy_mac_rclk>, <&emac1_sgmiiphy_mac_tclk>, <&emac1_sgmiiphy_rclk>,
+ <&emac1_sgmiiphy_tclk>, <&pcie20_phy_aux_clk>, <&pcie_1_pipe_clk>,
+ <&pcie_2_pipe_clk>, <&pcie_pipe_clk>, <&usb3_phy_wrapper_gcc_usb30_pipe_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml
index b480ead..cf4cad7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml
@@ -27,9 +27,21 @@
- description: GPLL0 div branch source
- description: SNoC DVM GFX source
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the VDD_GX power rail
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing required VDD_GX performance point.
+ maxItems: 1
+
required:
- compatible
- clocks
+ - power-domains
+ - required-opps
allOf:
- $ref: qcom,gcc.yaml#
@@ -40,6 +52,7 @@
- |
#include <dt-bindings/clock/qcom,sm6375-gcc.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
soc {
#address-cells = <2>;
@@ -52,6 +65,8 @@
<&gcc GCC_GPU_GPLL0_CLK_SRC>,
<&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>,
<&gcc GCC_GPU_SNOC_DVM_GFX_CLK>;
+ power-domains = <&rpmpd SM6375_VDDGX>;
+ required-opps = <&rpmpd_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
new file mode 100644
index 0000000..23505c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8350-videocc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350 Video Clock & Reset Controller
+
+maintainers:
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+
+description: |
+ Qualcomm video clock control module provides the clocks, resets and power
+ domains on Qualcomm SoCs.
+
+ See also::
+ include/dt-bindings/clock/qcom,videocc-sm8350.h
+ include/dt-bindings/reset/qcom,videocc-sm8350.h
+
+properties:
+ compatible:
+ const: qcom,sm8350-videocc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Board sleep clock
+
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the MMCX power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing required MMCX performance point.
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - required-opps
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ clock-controller@abf0000 {
+ compatible = "qcom,sm8350-videocc";
+ reg = <0x0abf0000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>;
+ power-domains = <&rpmhpd SM8350_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
new file mode 100644
index 0000000..2320be9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8450-gpucc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Clock & Reset Controller on SM8450
+
+maintainers:
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+
+description: |
+ Qualcomm graphics clock control module provides the clocks, resets and power
+ domains on Qualcomm SoCs.
+
+ See also::
+ include/dt-bindings/clock/qcom,sm8450-gpucc.h
+ include/dt-bindings/clock/qcom,sm8550-gpucc.h
+ include/dt-bindings/reset/qcom,sm8450-gpucc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8450-gpucc
+ - qcom,sm8550-gpucc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: GPLL0 main branch source
+ - description: GPLL0 div branch source
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ '#power-domain-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@3d90000 {
+ compatible = "qcom,sm8450-gpucc";
+ reg = <0 0x03d90000 0 0xa000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_GPU_GPLL0_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
new file mode 100644
index 0000000..f1c6dd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8450-videocc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Video Clock & Reset Controller on SM8450
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm video clock control module provides the clocks, resets and power
+ domains on SM8450.
+
+ See also:: include/dt-bindings/clock/qcom,videocc-sm8450.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8450-videocc
+ - qcom,sm8550-videocc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Video AHB clock from GCC
+
+ power-domains:
+ maxItems: 1
+ description:
+ MMCX power domain.
+
+ required-opps:
+ maxItems: 1
+ description:
+ A phandle to an OPP node describing required MMCX performance point.
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - power-domains
+ - required-opps
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ videocc: clock-controller@aaf0000 {
+ compatible = "qcom,sm8450-videocc";
+ reg = <0x0aaf0000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_VIDEO_AHB_CLK>;
+ power-domains = <&rpmhpd SM8450_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
index 9968608..26d94ce 100644
--- a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
@@ -48,7 +48,7 @@
patternProperties:
"^dma-router@[a-f0-9]+$":
type: object
- $ref: "../dma/renesas,rzn1-dmamux.yaml#"
+ $ref: /schemas/dma/renesas,rzn1-dmamux.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml
index 0589a63..a36781a 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml
@@ -24,6 +24,7 @@
- samsung,exynos3250-cmu-dmc
- samsung,exynos3250-cmu-isp
- samsung,exynos4210-clock
+ - samsung,exynos4212-clock
- samsung,exynos4412-clock
- samsung,exynos5250-clock
- items:
diff --git a/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
new file mode 100644
index 0000000..b2e40bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti,am62-audio-refclk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Audio Reference Clock
+
+maintainers:
+ - Jai Luthra <j-luthra@ti.com>
+
+properties:
+ compatible:
+ items:
+ - const: ti,am62-audio-refclk
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ audio_refclk0: clock@82e0 {
+ compatible = "ti,am62-audio-refclk";
+ reg = <0x82e0 0x4>;
+ clocks = <&k3_clks 157 0>;
+ assigned-clocks = <&k3_clks 157 0>;
+ assigned-clock-parents = <&k3_clks 157 8>;
+ #clock-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml
index 6676511..64b8bce59 100644
--- a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml
+++ b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml
@@ -16,7 +16,6 @@
- ti,am654-ehrpwm-tbclk
- ti,am64-epwm-tbclk
- ti,am62-epwm-tbclk
- - const: syscon
"#clock-cells":
const: 1
@@ -33,8 +32,8 @@
examples:
- |
- ehrpwm_tbclk: syscon@4140 {
- compatible = "ti,am654-ehrpwm-tbclk", "syscon";
+ ehrpwm_tbclk: clock@4140 {
+ compatible = "ti,am654-ehrpwm-tbclk";
reg = <0x4140 0x18>;
#clock-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
index c1f0483..02bd556 100644
--- a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
+++ b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
@@ -7,7 +7,7 @@
title: Xilinx clocking wizard
maintainers:
- - Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
description:
The clocking wizard is a soft ip clocking block of Xilinx versal. It
diff --git a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
index 229af98..5cbb34d 100644
--- a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
@@ -7,9 +7,7 @@
title: Xilinx Versal clock controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
- - Jolly Shah <jolly.shah@xilinx.com>
- - Rajan Vaja <rajan.vaja@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
description: |
The clock controller is a hardware block of Xilinx versal clock tree. It
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index ae51565..1c4d3eb 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -168,6 +168,13 @@
offer the power, Capability Mismatch is set. Required for power sink and
power dual role.
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OF graph bindings modeling a data bus to the connector, e.g.
+ there is a single High Speed (HS) port present in this connector. If there
+ is more than one bus (several port, with 'reg' property), they can be grouped
+ under 'ports'.
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
description: OF graph bindings modeling any data bus to the connector
@@ -322,6 +329,19 @@
};
};
+ # USB-C connector attached to SoC with a single High-Speed controller
+ - |
+ connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+
+ port {
+ high_speed_ep: endpoint {
+ remote-endpoint = <&usb_hs_ep>;
+ };
+ };
+ };
+
# USB-C connector attached to SoC and USB3 typec port controller(hd3ss3220)
# with SS 2:1 MUX. HS lines routed to SoC, SS lines routed to the MUX and
# the output of MUX is connected to the SoC.
diff --git a/Documentation/devicetree/bindings/cpu/idle-states.yaml b/Documentation/devicetree/bindings/cpu/idle-states.yaml
index b8cc826..b3a5356 100644
--- a/Documentation/devicetree/bindings/cpu/idle-states.yaml
+++ b/Documentation/devicetree/bindings/cpu/idle-states.yaml
@@ -259,7 +259,7 @@
http://infocenter.arm.com/help/index.jsp
[5] ARM Linux Kernel documentation - Booting AArch64 Linux
- Documentation/arm64/booting.rst
+ Documentation/arch/arm64/booting.rst
[6] RISC-V Linux Kernel documentation - CPUs bindings
Documentation/devicetree/bindings/riscv/cpus.yaml
diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
index 6f5e790..7e1bb99 100644
--- a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
@@ -28,6 +28,7 @@
- qcom,apq8064
- qcom,apq8096
- qcom,ipq8064
+ - qcom,ipq8074
- qcom,msm8939
- qcom,msm8960
- qcom,msm8974
diff --git a/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml b/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml
index ecf98a9..948e11e 100644
--- a/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml
+++ b/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml
@@ -19,8 +19,8 @@
interrupts:
items:
- - description: "Interrupt for flow 0"
- - description: "Interrupt for flow 1"
+ - description: Interrupt for flow 0
+ - description: Interrupt for flow 1
clocks:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml
index 286dffa..e879bc0b 100644
--- a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml
+++ b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml
@@ -103,6 +103,12 @@
wakeup-source: true
linux,keycode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 116
+ deprecated: true
+
+ linux,keycodes:
+ maxItems: 1
default: 116
required:
diff --git a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml
index 99be015..8dd36c2 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml
+++ b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml
@@ -11,9 +11,15 @@
properties:
compatible:
- enum:
- - fsl,imx23-dcp
- - fsl,imx28-dcp
+ oneOf:
+ - enum:
+ - fsl,imx23-dcp
+ - fsl,imx28-dcp
+ - items:
+ - enum:
+ - fsl,imx6sl-dcp
+ - fsl,imx6ull-dcp
+ - const: fsl,imx28-dcp
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml
index e0fe639..a400623 100644
--- a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml
+++ b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml
@@ -2,8 +2,8 @@
# Copyright 2018 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/crypto/intel,ixp4xx-crypto.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/crypto/intel,ixp4xx-crypto.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx cryptographic engine
@@ -21,7 +21,7 @@
const: intel,ixp4xx-crypto
intel,npe-handle:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the NPE this crypto engine
diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
index e375bd9..bb82806 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -26,10 +26,18 @@
- items:
- enum:
+ - qcom,ipq4019-qce
+ - qcom,sm8150-qce
+ - const: qcom,qce
+
+ - items:
+ - enum:
- qcom,ipq6018-qce
- qcom,ipq8074-qce
- qcom,msm8996-qce
+ - qcom,qcm2290-qce
- qcom,sdm845-qce
+ - qcom,sm6115-qce
- const: qcom,ipq4019-qce
- const: qcom,qce
@@ -46,16 +54,12 @@
maxItems: 1
clocks:
- items:
- - description: iface clocks register interface.
- - description: bus clocks data transfer interface.
- - description: core clocks rest of the crypto block.
+ minItems: 1
+ maxItems: 3
clock-names:
- items:
- - const: iface
- - const: bus
- - const: core
+ minItems: 1
+ maxItems: 3
iommus:
minItems: 1
@@ -89,9 +93,37 @@
enum:
- qcom,crypto-v5.1
- qcom,crypto-v5.4
- - qcom,ipq4019-qce
-
+ - qcom,ipq6018-qce
+ - qcom,ipq8074-qce
+ - qcom,msm8996-qce
+ - qcom,sdm845-qce
then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+ required:
+ - clocks
+ - clock-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcm2290-qce
+ - qcom,sm6115-qce
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: core
required:
- clocks
- clock-names
diff --git a/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml b/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml
new file mode 100644
index 0000000..71a2876
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/starfive,jh7110-crypto.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive Cryptographic Module
+
+maintainers:
+ - Jia Jie Ho <jiajie.ho@starfivetech.com>
+ - William Qiu <william.qiu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-crypto
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Hardware reference clock
+ - description: AHB reference clock
+
+ clock-names:
+ items:
+ - const: hclk
+ - const: ahb
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ dmas:
+ items:
+ - description: TX DMA channel
+ - description: RX DMA channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+ crypto: crypto@16000000 {
+ compatible = "starfive,jh7110-crypto";
+ reg = <0x16000000 0x4000>;
+ clocks = <&clk 15>, <&clk 16>;
+ clock-names = "hclk", "ahb";
+ interrupts = <28>;
+ resets = <&reset 3>;
+ dmas = <&dma 1 2>,
+ <&dma 0 2>;
+ dma-names = "tx", "rx";
+ };
+...
diff --git a/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml b/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml
index 9e8fbd0..8aead97 100644
--- a/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml
+++ b/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml
@@ -7,8 +7,8 @@
title: Xilinx ZynqMP AES-GCM Hardware Accelerator
maintainers:
- - Kalyani Akula <kalyani.akula@xilinx.com>
- - Michal Simek <michal.simek@xilinx.com>
+ - Kalyani Akula <kalyani.akula@amd.com>
+ - Michal Simek <michal.simek@amd.com>
description: |
The ZynqMP AES-GCM hardened cryptographic accelerator is used to
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml
new file mode 100644
index 0000000..a3428f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 BayLibre, SAS
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/amlogic,meson-g12a-dw-mipi-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic specific extensions to the Synopsys Designware MIPI DSI Host Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ The Amlogic Meson Synopsys Designware Integration is composed of
+ - A Synopsys DesignWare MIPI DSI Host Controller IP
+ - A TOP control block controlling the Clocks & Resets of the IP
+
+allOf:
+ - $ref: dsi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-dw-mipi-dsi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 4
+
+ clock-names:
+ minItems: 3
+ items:
+ - const: pclk
+ - const: bit
+ - const: px
+ - const: meas
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: top
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ items:
+ - const: dphy
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input node to receive pixel data.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DSI output node to panel.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - phys
+ - phy-names
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ dsi@6000 {
+ compatible = "amlogic,meson-g12a-dw-mipi-dsi";
+ reg = <0x6000 0x400>;
+ resets = <&reset_top>;
+ reset-names = "top";
+ clocks = <&clk_pclk>, <&bit_clk>, <&clk_px>;
+ clock-names = "pclk", "bit", "px";
+ phys = <&mipi_dphy>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VPU VENC Input */
+ mipi_dsi_venc_port: port@0 {
+ reg = <0>;
+
+ mipi_dsi_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ /* DSI Output */
+ mipi_dsi_panel_port: port@1 {
+ reg = <1>;
+
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&mipi_in_panel>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
index 0c72120..cb0a90f 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
@@ -96,6 +96,11 @@
description:
A port node pointing to the HDMI-TX port node.
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node pointing to the DPI port node (e.g. DSI or LVDS transceiver).
+
"#address-cells":
const: 1
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
index c9b0688..62f0521 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
@@ -26,6 +26,7 @@
const: dp
force-hpd:
+ type: boolean
description:
Indicate driver need force hpd when hpd detect failed, this
is used for some eDP screen which don not have a hpd signal.
diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
index 6e0e3ba..07388bf 100644
--- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
@@ -17,6 +17,7 @@
properties:
compatible:
enum:
+ - fsl,imx6sx-ldb
- fsl,imx8mp-ldb
- fsl,imx93-ldb
@@ -64,7 +65,9 @@
properties:
compatible:
contains:
- const: fsl,imx93-ldb
+ enum:
+ - fsl,imx6sx-ldb
+ - fsl,imx93-ldb
then:
properties:
ports:
diff --git a/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml b/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
index c4bf543..21d995f 100644
--- a/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
@@ -20,6 +20,7 @@
maxItems: 1
video-ports:
+ $ref: /schemas/types.yaml#/definitions/uint32
default: 0x230145
maximum: 0xffffff
description:
diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
index e841659..4ed7a79 100644
--- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
@@ -70,7 +70,9 @@
samsung,burst-clock-frequency:
$ref: /schemas/types.yaml#/definitions/uint32
description:
- DSIM high speed burst mode frequency.
+ DSIM high speed burst mode frequency. If absent,
+ the pixel clock from the attached device or bridge
+ will be used instead.
samsung,esc-clock-frequency:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -80,7 +82,8 @@
samsung,pll-clock-frequency:
$ref: /schemas/types.yaml#/definitions/uint32
description:
- DSIM oscillator clock frequency.
+ DSIM oscillator clock frequency. If absent, the clock frequency
+ of sclk_mipi will be used instead.
phys:
maxItems: 1
@@ -100,20 +103,42 @@
specified.
port@1:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
DSI output port node to the panel or the next bridge
in the chain.
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ uniqueItems: true
+ items:
+ enum: [ 1, 2, 3, 4 ]
+
+ lane-polarities:
+ minItems: 1
+ maxItems: 5
+ description:
+ The Samsung MIPI DSI IP requires that all the data lanes have
+ the same polarity.
+
+ dependencies:
+ lane-polarities: [data-lanes]
+
required:
- clock-names
- clocks
- compatible
- interrupts
- reg
- - samsung,burst-clock-frequency
- samsung,esc-clock-frequency
- - samsung,pll-clock-frequency
allOf:
- $ref: ../dsi-controller.yaml#
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
index 81ca3cb..6c1de0b 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
@@ -21,6 +21,9 @@
maxItems: 1
description: virtual channel number of a DSI peripheral
+ reset-gpios:
+ maxItems: 1
+
vddc-supply:
description: Regulator for 1.2V internal core power.
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
index e1494b5..0521261 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
@@ -4,16 +4,24 @@
$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358767.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Toshiba TC358767 eDP bridge
+title: Toshiba TC358767/TC358867/TC9595 DSI/DPI/eDP bridge
maintainers:
- Andrey Gusakov <andrey.gusakov@cogentembedded.com>
-description: The TC358767 is bridge device which converts DSI/DPI to eDP/DP
+description: |
+ The TC358767/TC358867/TC9595 is bridge device which
+ converts DSI/DPI to eDP/DP .
properties:
compatible:
- const: toshiba,tc358767
+ oneOf:
+ - items:
+ - enum:
+ - toshiba,tc358867
+ - toshiba,tc9595
+ - const: toshiba,tc358767
+ - const: toshiba,tc358767
reg:
enum:
diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml
index 83c0d00..3ee8f92 100644
--- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml
+++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml
@@ -36,6 +36,9 @@
description: GPIO signal to enable DDC bus
maxItems: 1
+ hdmi-pwr-supply:
+ description: Power supply for the HDMI +5V Power pin
+
port:
$ref: /schemas/graph.yaml#/properties/port
description: Connection to controller providing HDMI signals
diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 75b4efd..fc11ab5 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -21,6 +21,7 @@
- fsl,imx28-lcdif
- fsl,imx6sx-lcdif
- fsl,imx8mp-lcdif
+ - fsl,imx93-lcdif
- items:
- enum:
- fsl,imx6sl-lcdif
@@ -88,7 +89,9 @@
properties:
compatible:
contains:
- const: fsl,imx8mp-lcdif
+ enum:
+ - fsl,imx8mp-lcdif
+ - fsl,imx93-lcdif
then:
properties:
clocks:
@@ -107,6 +110,7 @@
enum:
- fsl,imx6sx-lcdif
- fsl,imx8mp-lcdif
+ - fsl,imx93-lcdif
then:
properties:
clocks:
@@ -123,6 +127,7 @@
- fsl,imx8mm-lcdif
- fsl,imx8mn-lcdif
- fsl,imx8mp-lcdif
+ - fsl,imx93-lcdif
then:
required:
- power-domains
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index 9274148..7fd42c8 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -27,6 +27,7 @@
- items:
- enum:
- mediatek,mt2712-disp-aal
+ - mediatek,mt6795-disp-aal
- const: mediatek,mt8173-disp-aal
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index d0ea77f..f21e440 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -33,6 +33,7 @@
- const: mediatek,mt2701-disp-color
- items:
- enum:
+ - mediatek,mt6795-disp-color
- mediatek,mt8183-disp-color
- mediatek,mt8186-disp-color
- mediatek,mt8188-disp-color
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index d976380..803c00f 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -17,15 +17,20 @@
properties:
compatible:
- enum:
- - mediatek,mt2701-dpi
- - mediatek,mt7623-dpi
- - mediatek,mt8173-dpi
- - mediatek,mt8183-dpi
- - mediatek,mt8186-dpi
- - mediatek,mt8188-dp-intf
- - mediatek,mt8192-dpi
- - mediatek,mt8195-dp-intf
+ oneOf:
+ - enum:
+ - mediatek,mt2701-dpi
+ - mediatek,mt7623-dpi
+ - mediatek,mt8173-dpi
+ - mediatek,mt8183-dpi
+ - mediatek,mt8186-dpi
+ - mediatek,mt8188-dp-intf
+ - mediatek,mt8192-dpi
+ - mediatek,mt8195-dp-intf
+ - items:
+ - enum:
+ - mediatek,mt6795-dpi
+ - const: mediatek,mt8183-dpi
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
index 4707b60..12441b9 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
@@ -22,13 +22,18 @@
properties:
compatible:
- enum:
- - mediatek,mt2701-dsi
- - mediatek,mt7623-dsi
- - mediatek,mt8167-dsi
- - mediatek,mt8173-dsi
- - mediatek,mt8183-dsi
- - mediatek,mt8186-dsi
+ oneOf:
+ - enum:
+ - mediatek,mt2701-dsi
+ - mediatek,mt7623-dsi
+ - mediatek,mt8167-dsi
+ - mediatek,mt8173-dsi
+ - mediatek,mt8183-dsi
+ - mediatek,mt8186-dsi
+ - items:
+ - enum:
+ - mediatek,mt6795-dsi
+ - const: mediatek,mt8173-dsi
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index 6c2be9d..c6641ac 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -26,6 +26,10 @@
- mediatek,mt8183-disp-gamma
- items:
- enum:
+ - mediatek,mt6795-disp-gamma
+ - const: mediatek,mt8173-disp-gamma
+ - items:
+ - enum:
- mediatek,mt8186-disp-gamma
- mediatek,mt8188-disp-gamma
- mediatek,mt8192-disp-gamma
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
index 2f8e2f4..eead5cb 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
@@ -24,6 +24,9 @@
- enum:
- mediatek,mt8173-disp-merge
- mediatek,mt8195-disp-merge
+ - items:
+ - const: mediatek,mt6795-disp-merge
+ - const: mediatek,mt8173-disp-merge
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
index 29f9fa8..831c653 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
@@ -24,6 +24,9 @@
- enum:
- mediatek,mt2712-disp-od
- mediatek,mt8173-disp-od
+ - items:
+ - const: mediatek,mt6795-disp-od
+ - const: mediatek,mt8173-disp-od
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index 92e320d..3e1069b 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -33,6 +33,10 @@
- const: mediatek,mt2701-disp-ovl
- items:
- enum:
+ - mediatek,mt6795-disp-ovl
+ - const: mediatek,mt8173-disp-ovl
+ - items:
+ - enum:
- mediatek,mt8188-disp-ovl
- mediatek,mt8195-disp-ovl
- const: mediatek,mt8183-disp-ovl
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
index 42059ef..39dbb5c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
@@ -39,6 +39,10 @@
- const: mediatek,mt2701-disp-rdma
- items:
- enum:
+ - mediatek,mt6795-disp-rdma
+ - const: mediatek,mt8173-disp-rdma
+ - items:
+ - enum:
- mediatek,mt8186-disp-rdma
- mediatek,mt8192-disp-rdma
- const: mediatek,mt8183-disp-rdma
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
index 21a4e96..a8a5c96 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
@@ -23,6 +23,9 @@
oneOf:
- enum:
- mediatek,mt8173-disp-split
+ - items:
+ - const: mediatek,mt6795-disp-split
+ - const: mediatek,mt8173-disp-split
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
index 62fad23..39e3e2d 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
@@ -24,6 +24,9 @@
oneOf:
- enum:
- mediatek,mt8173-disp-ufoe
+ - items:
+ - const: mediatek,mt6795-disp-ufoe
+ - const: mediatek,mt8173-disp-ufoe
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
index 9911831..a3a2b71 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
@@ -23,6 +23,9 @@
oneOf:
- enum:
- mediatek,mt8173-disp-wdma
+ - items:
+ - const: mediatek,mt6795-disp-wdma
+ - const: mediatek,mt8173-disp-wdma
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f0c2237..7a7cf3f 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -29,6 +29,7 @@
- items:
- enum:
- qcom,sm8450-dp
+ - qcom,sm8550-dp
- const: qcom,sm8350-dp
reg:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 130e16d..01848bd 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -15,6 +15,7 @@
- items:
- enum:
- qcom,apq8064-dsi-ctrl
+ - qcom,msm8226-dsi-ctrl
- qcom,msm8916-dsi-ctrl
- qcom,msm8953-dsi-ctrl
- qcom,msm8974-dsi-ctrl
@@ -26,6 +27,8 @@
- qcom,sdm660-dsi-ctrl
- qcom,sdm845-dsi-ctrl
- qcom,sm6115-dsi-ctrl
+ - qcom,sm6350-dsi-ctrl
+ - qcom,sm6375-dsi-ctrl
- qcom,sm8150-dsi-ctrl
- qcom,sm8250-dsi-ctrl
- qcom,sm8350-dsi-ctrl
@@ -256,6 +259,7 @@
compatible:
contains:
enum:
+ - qcom,msm8226-dsi-ctrl
- qcom,msm8974-dsi-ctrl
then:
properties:
@@ -297,6 +301,7 @@
contains:
enum:
- qcom,msm8998-dsi-ctrl
+ - qcom,sm6350-dsi-ctrl
then:
properties:
clocks:
@@ -364,6 +369,7 @@
enum:
- qcom,sdm845-dsi-ctrl
- qcom,sm6115-dsi-ctrl
+ - qcom,sm6375-dsi-ctrl
then:
properties:
clocks:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
index cf4a338..62fb3e4 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
@@ -15,10 +15,11 @@
properties:
compatible:
enum:
+ - qcom,dsi-phy-28nm-8226
+ - qcom,dsi-phy-28nm-8960
- qcom,dsi-phy-28nm-hpm
- qcom,dsi-phy-28nm-hpm-fam-b
- qcom,dsi-phy-28nm-lp
- - qcom,dsi-phy-28nm-8960
reg:
items:
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml
index 029d728..d65926b 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
@@ -19,16 +19,18 @@
properties:
compatible:
- items:
- - pattern: '^qcom,adreno-gmu-6[0-9][0-9]\.[0-9]$'
- - const: qcom,adreno-gmu
+ oneOf:
+ - items:
+ - pattern: '^qcom,adreno-gmu-6[0-9][0-9]\.[0-9]$'
+ - const: qcom,adreno-gmu
+ - const: qcom,adreno-gmu-wrapper
reg:
- minItems: 3
+ minItems: 1
maxItems: 4
reg-names:
- minItems: 3
+ minItems: 1
maxItems: 4
clocks:
@@ -44,7 +46,6 @@
- description: GMU HFI interrupt
- description: GMU interrupt
-
interrupt-names:
items:
- const: hfi
@@ -72,14 +73,8 @@
- compatible
- reg
- reg-names
- - clocks
- - clock-names
- - interrupts
- - interrupt-names
- power-domains
- power-domain-names
- - iommus
- - operating-points-v2
additionalProperties: false
@@ -122,6 +117,7 @@
contains:
enum:
- qcom,adreno-gmu-635.0
+ - qcom,adreno-gmu-660.1
then:
properties:
reg:
@@ -217,6 +213,28 @@
- const: axi
- const: memnoc
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,adreno-gmu-wrapper
+ then:
+ properties:
+ reg:
+ items:
+ - description: GMU wrapper register space
+ reg-names:
+ items:
+ - const: gmu
+ else:
+ required:
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - operating-points-v2
+
examples:
- |
#include <dt-bindings/clock/qcom,gpucc-sdm845.h>
@@ -225,7 +243,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
gmu: gmu@506a000 {
- compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
+ compatible = "qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
reg = <0x506a000 0x30000>,
<0xb280000 0x10000>,
@@ -249,3 +267,12 @@
iommus = <&adreno_smmu 5>;
operating-points-v2 = <&gmu_opp_table>;
};
+
+ gmu_wrapper: gmu@596a000 {
+ compatible = "qcom,adreno-gmu-wrapper";
+ reg = <0x0596a000 0x30000>;
+ reg-names = "gmu";
+ power-domains = <&gpucc GPU_CX_GDSC>,
+ <&gpucc GPU_GX_GDSC>;
+ power-domain-names = "cx", "gx";
+ };
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index 5dabe7b..58ca891 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -36,10 +36,7 @@
reg-names:
minItems: 1
- items:
- - const: kgsl_3d0_reg_memory
- - const: cx_mem
- - const: cx_dbgc
+ maxItems: 3
interrupts:
maxItems: 1
@@ -157,16 +154,62 @@
required:
- clocks
- clock-names
+
- if:
properties:
compatible:
contains:
- pattern: '^qcom,adreno-6[0-9][0-9]\.[0-9]$'
-
- then: # Since Adreno 6xx series clocks should be defined in GMU
+ enum:
+ - qcom,adreno-610.0
+ - qcom,adreno-619.1
+ then:
properties:
- clocks: false
- clock-names: false
+ clocks:
+ minItems: 6
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - const: alt_mem_iface
+ description: GPU Alternative Memory Interface clock
+ - const: gmu
+ description: CX GMU clock
+ - const: xo
+ description: GPUCC clocksource clock
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: kgsl_3d0_reg_memory
+ - const: cx_dbgc
+
+ required:
+ - clocks
+ - clock-names
+ else:
+ if:
+ properties:
+ compatible:
+ contains:
+ pattern: '^qcom,adreno-6[0-9][0-9]\.[0-9]$'
+
+ then: # Starting with A6xx, the clocks are usually defined in the GMU node
+ properties:
+ clocks: false
+ clock-names: false
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: kgsl_3d0_reg_memory
+ - const: cx_mem
+ - const: cx_dbgc
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
index a763cf8..2fe032d 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
@@ -22,6 +22,7 @@
- items:
- enum:
- qcom,apq8084-mdp5
+ - qcom,msm8226-mdp5
- qcom,msm8916-mdp5
- qcom,msm8917-mdp5
- qcom,msm8953-mdp5
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
index b010010..db9f07c 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
@@ -125,6 +125,7 @@
- qcom,dsi-phy-14nm-660
- qcom,dsi-phy-14nm-8953
- qcom,dsi-phy-20nm
+ - qcom,dsi-phy-28nm-8226
- qcom,dsi-phy-28nm-hpm
- qcom,dsi-phy-28nm-lp
- qcom,hdmi-phy-8084
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
index 1fb8321..630b114 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
@@ -13,7 +13,10 @@
properties:
compatible:
- const: qcom,sc7180-dpu
+ enum:
+ - qcom,sc7180-dpu
+ - qcom,sm6350-dpu
+ - qcom,sm6375-dpu
reg:
items:
@@ -26,6 +29,7 @@
- const: vbif
clocks:
+ minItems: 6
items:
- description: Display hf axi clock
- description: Display ahb clock
@@ -33,8 +37,10 @@
- description: Display lut clock
- description: Display core clock
- description: Display vsync clock
+ - description: Display core throttle clock
clock-names:
+ minItems: 6
items:
- const: bus
- const: iface
@@ -42,6 +48,7 @@
- const: lut
- const: core
- const: vsync
+ - const: throttle
required:
- compatible
@@ -52,6 +59,20 @@
unevaluatedProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: qcom,sm6375-dpu
+
+ then:
+ properties:
+ clocks:
+ minItems: 7
+
+ clock-names:
+ minItems: 7
+
examples:
- |
#include <dt-bindings/clock/qcom,dispcc-sc7180.h>
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
new file mode 100644
index 0000000..ed0ad19
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
@@ -0,0 +1,213 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6350 Display MDSS
+
+maintainers:
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+
+description:
+ SM6350 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
+ like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6350-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AXI clock from gcc
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sm6350-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm6350-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,dsi-phy-10nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm6350.h>
+ #include <dt-bindings/clock/qcom,gcc-sm6350.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm6350-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x800 0x2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm6350-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus", "iface", "rot", "lut", "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>;
+ assigned-clock-rates = <300000000>,
+ <19200000>,
+ <19200000>,
+ <19200000>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM6350_CX>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm6350-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SM6350_MX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
new file mode 100644
index 0000000..76369a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
@@ -0,0 +1,215 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6375-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6375 Display MDSS
+
+maintainers:
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+
+description:
+ SM6375 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
+ like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6375-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sm6375-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm6375-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sm6375-dsi-phy-7nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/clock/qcom,sm6375-gcc.h>
+ #include <dt-bindings/clock/qcom,sm6375-dispcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@5e00000 {
+ compatible = "qcom,sm6375-mdss";
+ reg = <0x05e00000 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "ahb", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x820 0x2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@5e01000 {
+ compatible = "qcom,sm6375-dpu";
+ reg = <0x05e01000 0x8e030>,
+ <0x05eb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+ <&gcc GCC_DISP_THROTTLE_CORE_CLK>;
+ clock-names = "bus",
+ "iface",
+ "rot",
+ "lut",
+ "core",
+ "vsync",
+ "throttle";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd SM6375_VDDCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+
+ dsi@5e94000 {
+ compatible = "qcom,sm6375-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x05e94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmpd SM6375_VDDMX>;
+
+ phys = <&mdss_dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ mdss_dsi0_phy: phy@5e94400 {
+ compatible = "qcom,sm6375-dsi-phy-7nm";
+ reg = <0x05e94400 0x200>,
+ <0x05e94600 0x280>,
+ <0x05e94900 0x264>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface", "ref";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
index 4d94dbf..79a226e 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
@@ -64,7 +64,7 @@
type: object
properties:
compatible:
- const: qcom,dsi-phy-5nm-8350
+ const: qcom,sm8350-dsi-phy-5nm
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
index aed5560..906ef627 100644
--- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -32,6 +32,10 @@
- innolux,hj110iz-01a
# STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
- starry,2081101qfh032011-53g
+ # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
+ - starry,himax83102-j02
+ # STARRY ili9882t 10.51" WUXGA TFT LCD panel
+ - starry,ili9882t
reg:
description: the virtual channel number of a DSI peripheral
diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
index 0039561e..5f7e4c4 100644
--- a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
@@ -19,11 +19,16 @@
properties:
compatible:
- items:
- - enum:
- - xiaomi,elish-boe-nt36523
- - xiaomi,elish-csot-nt36523
- - const: novatek,nt36523
+ oneOf:
+ - items:
+ - enum:
+ - xiaomi,elish-boe-nt36523
+ - xiaomi,elish-csot-nt36523
+ - const: novatek,nt36523
+ - items:
+ - enum:
+ - lenovo,j606f-boe-nt36523w
+ - const: novatek,nt36523w
reset-gpios:
maxItems: 1
@@ -34,6 +39,7 @@
reg: true
ports: true
+ rotation: true
backlight: true
required:
diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
index 9b701df..2f0238b 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
@@ -67,6 +67,7 @@
items:
- enum:
- sainsmart18
+ - shineworld,lh133k
- const: panel-mipi-dbi-spi
write-only:
@@ -86,6 +87,8 @@
Logic level supply for interface signals (Vddi).
No need to set if this is the same as power-supply.
+ spi-3wire: true
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 01560fe..1d4936f 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -33,6 +33,8 @@
- ampire,am-1280800n3tzqw-t00h
# Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
- ampire,am-480272h3tmqw-t01h
+ # Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD panel
+ - ampire,am-800480l1tmqw-t00h
# Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
- ampire,am800480r3tmqwa1h
# Ampire AM-800600P5TMQW-TB8H 8.0" SVGA TFT LCD panel
@@ -77,6 +79,8 @@
- auo,t215hvn01
# Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel
- avic,tm070ddh03
+ # BOE EV121WXM-N10-1850 12.1" WXGA (1280x800) TFT LCD panel
+ - boe,ev121wxm-n10-1850
# BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
- boe,hv070wsa-100
# BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
@@ -174,6 +178,8 @@
- innolux,at043tn24
# Innolux AT070TN92 7.0" WQVGA TFT LCD panel
- innolux,at070tn92
+ # Innolux G070ACE-L01 7" WVGA (800x480) TFT LCD panel
+ - innolux,g070ace-l01
# Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
- innolux,g070y2-l01
# Innolux G070Y2-T02 7" WVGA (800x480) TFT LCD TTL panel
@@ -280,6 +286,8 @@
- rocktech,rk101ii01d-ct
# Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
- rocktech,rk070er9427
+ # Rocktech Display Ltd. RK043FN48H 4.3" 480x272 LCD-TFT panel
+ - rocktech,rk043fn48h
# Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
- samsung,atna33xc20
# Samsung 12.2" (2560x1600 pixels) TFT LCD panel
diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
index 09b5eb7..150e810 100644
--- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
+++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
@@ -20,6 +20,8 @@
properties:
compatible:
enum:
+ # Anberic RG353V-V2 5.0" 640x480 TFT LCD panel
+ - anbernic,rg353v-panel-v2
# Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
- rocktech,jh057n00900
# Xingbangda XBD599 5.99" 720x1440 TFT LCD panel
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
new file mode 100644
index 0000000..45a236d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/samsung,s6d7aa0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S6D7AA0 MIPI-DSI LCD panel controller
+
+maintainers:
+ - Artur Weber <aweber.kernel@gmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ # 1280x800 LSL080AL02 panel
+ - samsung,lsl080al02
+ # 1024x768 LSL080AL03 panel
+ - samsung,lsl080al03
+ # 1024x768 LTL101AT01 panel
+ - samsung,ltl101at01
+ - const: samsung,s6d7aa0
+
+ reg: true
+
+ backlight:
+ description:
+ Backlight to use for the panel. If this property is set on panels
+ that have DSI-based backlight control (LSL080AL03 and LTL101AT01),
+ it overrides the DSI-based backlight.
+
+ reset-gpios:
+ description: Reset GPIO pin, usually GPIO_ACTIVE_LOW.
+
+ power-supply:
+ description:
+ Main power supply for the panel; the exact voltage differs between
+ panels, and is usually somewhere around 3.3-5v.
+
+ vmipi-supply:
+ description: VMIPI supply, usually 1.8v.
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "samsung,lsl080al02", "samsung,s6d7aa0";
+ reg = <0>;
+ power-supply = <&display_3v3_supply>;
+ reset-gpios = <&gpf0 4 GPIO_ACTIVE_LOW>;
+ backlight = <&backlight>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
index 1cdc91b..200fbf1 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
@@ -74,7 +74,7 @@
vdd3-supply = <&vcclcd_reg>;
vci-supply = <&vlcd_reg>;
reset-gpios = <&gpy4 5 0>;
- power-on-delay= <50>;
+ power-on-delay = <50>;
reset-delay = <100>;
init-delay = <100>;
panel-width-mm = <58>;
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
index 6f43d88..df61cb5 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -121,11 +121,11 @@
#size-cells = <0>;
vopb_out_edp: endpoint@0 {
reg = <0>;
- remote-endpoint=<&edp_in_vopb>;
+ remote-endpoint = <&edp_in_vopb>;
};
vopb_out_hdmi: endpoint@1 {
reg = <1>;
- remote-endpoint=<&hdmi_in_vopb>;
+ remote-endpoint = <&hdmi_in_vopb>;
};
};
};
diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
index c488308..5356005 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
@@ -74,8 +74,6 @@
- const: 2
required:
- - "#address-cells"
- - "#size-cells"
- compatible
- reg
- clocks
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
index a42bf33..2181855 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
@@ -73,6 +73,18 @@
avdd-dsi-csi-supply:
description: DSI/CSI power supply. Must supply 1.2 V.
+ vip:
+ $ref: /schemas/display/tegra/nvidia,tegra20-vip.yaml
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Input from the VIP (parallel input capture) module
+
patternProperties:
"^csi@[0-9a-f]+$":
type: object
@@ -108,6 +120,22 @@
#include <dt-bindings/clock/tegra20-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ camera@48 {
+ compatible = "aptina,mt9v111";
+ reg = <0x48>;
+ clocks = <&camera_clk>;
+
+ port {
+ mt9v111_out: endpoint {
+ remote-endpoint = <&vi_vip_in>;
+ };
+ };
+ };
+ };
+
vi@54080000 {
compatible = "nvidia,tegra20-vi";
reg = <0x54080000 0x00040000>;
@@ -115,6 +143,37 @@
clocks = <&tegra_car TEGRA20_CLK_VI>;
resets = <&tegra_car 100>;
reset-names = "vi";
+
+ vip {
+ compatible = "nvidia,tegra20-vip";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ vi_vip_in: endpoint {
+ remote-endpoint = <&mt9v111_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ vi_vip_out: endpoint {
+ remote-endpoint = <&vi_in>;
+ };
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ vi_in: endpoint {
+ remote-endpoint = <&vi_vip_out>;
+ };
+ };
+ };
};
- |
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml
new file mode 100644
index 0000000..14294ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-vip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra VIP (parallel video capture) controller
+
+maintainers:
+ - Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-vip
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port receiving the video stream from the sensor
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port sending the video stream to the VI
+
+ required:
+ - port@0
+ - port@1
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - ports
+
+# see nvidia,tegra20-vi.yaml for an example
diff --git a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
index 6484534..1e5752b 100644
--- a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
+++ b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
@@ -112,14 +112,23 @@
- const: stericsson,dma40
reg:
- items:
- - description: DMA40 memory base
- - description: LCPA memory base
+ oneOf:
+ - items:
+ - description: DMA40 memory base
+ - items:
+ - description: DMA40 memory base
+ - description: LCPA memory base, deprecated, use eSRAM pool instead
+ deprecated: true
+
reg-names:
- items:
- - const: base
- - const: lcpa
+ oneOf:
+ - items:
+ - const: base
+ - items:
+ - const: base
+ - const: lcpa
+ deprecated: true
interrupts:
maxItems: 1
@@ -127,6 +136,15 @@
clocks:
maxItems: 1
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: A phandle array with inner size 1 (no arg cells).
+ First phandle is the LCPA (Logical Channel Parameter Address) memory.
+ Second phandle is the LCLA (Logical Channel Link base Address) memory.
+ maxItems: 2
+ items:
+ maxItems: 1
+
memcpy-channels:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: Array of u32 elements indicating which channels on the DMA
@@ -138,6 +156,7 @@
- reg
- interrupts
- clocks
+ - sram
- memcpy-channels
additionalProperties: false
@@ -149,8 +168,9 @@
#include <dt-bindings/mfd/dbx500-prcmu.h>
dma-controller@801c0000 {
compatible = "stericsson,db8500-dma40", "stericsson,dma40";
- reg = <0x801c0000 0x1000>, <0x40010000 0x800>;
- reg-names = "base", "lcpa";
+ reg = <0x801c0000 0x1000>;
+ reg-names = "base";
+ sram = <&lcpa>, <&lcla>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
#dma-cells = <3>;
memcpy-channels = <56 57 58 59 60>;
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
index beecfe7..4ca300a 100644
--- a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
+++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
@@ -33,6 +33,7 @@
enum:
- ti,am62a-dmss-bcdma-csirx
- ti,am64-dmss-bcdma
+ - ti,j721s2-dmss-bcdma-csi
reg:
minItems: 3
@@ -151,7 +152,12 @@
required:
- power-domains
- else:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am64-dmss-bcdma
+ then:
properties:
reg:
minItems: 5
@@ -168,6 +174,28 @@
- ti,sci-rm-range-bchan
- ti,sci-rm-range-tchan
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,j721s2-dmss-bcdma-csi
+ then:
+ properties:
+ ti,sci-rm-range-bchan: false
+
+ reg:
+ maxItems: 4
+
+ reg-names:
+ items:
+ - const: gcfg
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ required:
+ - ti,sci-rm-range-tchan
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
index d6cbd95..2128f46 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
+++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
@@ -41,6 +41,9 @@
clock-names:
const: axi_clk
+ power-domains:
+ maxItems: 1
+
required:
- "#dma-cells"
- compatible
@@ -48,12 +51,14 @@
- interrupts
- clocks
- clock-names
+ - power-domains
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
dma: dma-controller@fd4c0000 {
compatible = "xlnx,zynqmp-dpdma";
@@ -63,6 +68,7 @@
clocks = <&dpdma_clk>;
clock-names = "axi_clk";
#dma-cells = <1>;
+ power-domains = <&zynqmp_firmware PD_DP>;
};
...
diff --git a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml
index 1dcb85a..cc93066 100644
--- a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml
+++ b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml
@@ -42,7 +42,7 @@
enum: [ 0, 1 ]
performance-domains:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description:
A phandle and performance domain specifier as defined by bindings of the
performance controller/provider specified by phandle.
diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml
index 11e2a95..0e31bb3 100644
--- a/Documentation/devicetree/bindings/eeprom/at25.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at25.yaml
@@ -33,6 +33,7 @@
- microchip,25lc040
- st,m95m02
- st,m95256
+ - st,m95640
- cypress,fm25
- const: atmel,at25
diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml
index f4eec4c..a41f9b9 100644
--- a/Documentation/devicetree/bindings/example-schema.yaml
+++ b/Documentation/devicetree/bindings/example-schema.yaml
@@ -52,8 +52,7 @@
- vendor,soc4-ip
- vendor,soc3-ip
- vendor,soc2-ip
- - enum:
- - vendor,soc1-ip
+ - const: vendor,soc1-ip
# additionalItems being false is implied
# minItems/maxItems equal to 2 is implied
- items:
@@ -85,6 +84,9 @@
discouraged.
clock-names:
+ # For single-entry lists in clocks, resets etc., the xxx-names often do not
+ # bring any value, especially if they copy the IP block name. In such case
+ # just skip the xxx-names.
items:
- const: bus
diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
index 6a9c96f..2c8cf6a 100644
--- a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
+++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
@@ -27,10 +27,14 @@
interrupt-names:
minItems: 1
- items:
- - const: usb_id
- - const: usb_vbus
-
+ anyOf:
+ - items:
+ - const: usb_id
+ - const: usb_vbus
+ - items:
+ - const: usb_id
+ - items:
+ - const: usb_vbus
required:
- compatible
- reg
@@ -49,7 +53,7 @@
interrupt-controller;
#interrupt-cells = <4>;
- usb_id: misc@900 {
+ usb_id: usb-detect@900 {
compatible = "qcom,pm8941-misc";
reg = <0x900>;
interrupts = <0x0 0x9 0 IRQ_TYPE_EDGE_BOTH>;
diff --git a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
index efdf59a..351b202 100644
--- a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
+++ b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
@@ -23,7 +23,7 @@
headphone detect mode to HPDETL, ARIZONA_ACCDET_MODE_HPR/2 sets it
to HPDETR. If this node is not included or if the value is unknown,
then headphone detection mode is set to HPDETL.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 2
@@ -51,7 +51,7 @@
description:
Additional software microphone detection debounce specified in
milliseconds.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
wlf,micd-pol-gpio:
description:
@@ -63,7 +63,7 @@
description:
Time allowed for MICBIAS to startup prior to performing microphone
detection, specified as per the ARIZONA_MICD_TIME_XXX defines.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 12
@@ -71,7 +71,7 @@
description:
Delay between successive microphone detection measurements, specified
as per the ARIZONA_MICD_TIME_XXX defines.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 12
@@ -79,7 +79,7 @@
description:
Microphone detection hardware debounces specified as the number of
measurements to take.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [2, 4]
wlf,micd-timeout-ms:
@@ -97,7 +97,7 @@
CTIA / OMTP headsets), the field can be of variable length but
should always be a multiple of 3 cells long, each three cell group
represents one polarity configuration.
- $ref: "/schemas/types.yaml#/definitions/uint32-matrix"
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
items:
items:
- description:
@@ -119,7 +119,7 @@
description:
Settings for the general purpose switch, set as one of the
ARIZONA_GPSW_XXX defines.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 5824c43..b138f3d 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -34,6 +34,10 @@
- description: SCMI compliant firmware with ARM SMC/HVC transport
items:
- const: arm,scmi-smc
+ - description: SCMI compliant firmware with ARM SMC/HVC transport
+ with shmem address(4KB-page, offset) as parameters
+ items:
+ - const: arm,scmi-smc-param
- description: SCMI compliant firmware with SCMI Virtio transport.
The virtio transport only supports a single device.
items:
@@ -214,7 +218,7 @@
patternProperties:
'^regulator@[0-9a-f]+$':
type: object
- $ref: "../regulator/regulator.yaml#"
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
properties:
@@ -299,7 +303,9 @@
properties:
compatible:
contains:
- const: arm,scmi-smc
+ enum:
+ - arm,scmi-smc
+ - arm,scmi-smc-param
then:
required:
- arm,smc-id
diff --git a/Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml b/Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml
new file mode 100644
index 0000000..684b15b
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/brcm,kona-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family Secure Monitor bounce buffer
+
+description:
+ A bounce buffer used for non-secure to secure communications.
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - brcm,bcm11351-smc
+ - brcm,bcm21664-smc
+ - brcm,bcm23550-smc
+ - const: brcm,kona-smc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ smc@3404c000 {
+ compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
+ reg = <0x3404c000 0x400>; /* 1 KiB in SRAM */
+ };
+...
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index 367d04a..bdbee58 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -51,6 +51,7 @@
- qcom,scm-sdm845
- qcom,scm-sdx55
- qcom,scm-sdx65
+ - qcom,scm-sdx75
- qcom,scm-sm6115
- qcom,scm-sm6125
- qcom,scm-sm6350
@@ -71,6 +72,8 @@
minItems: 1
maxItems: 3
+ dma-coherent: true
+
interconnects:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index f14f7b4..910bebe 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -7,7 +7,7 @@
title: Xilinx firmware driver
maintainers:
- - Nava kishore Manne <nava.manne@xilinx.com>
+ - Nava kishore Manne <nava.kishore.manne@amd.com>
description: The zynqmp-firmware node describes the interface to platform
firmware. ZynqMP has an interface to communicate with secure firmware.
diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml
index f47b614..04dcadc 100644
--- a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml
+++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml
@@ -7,7 +7,7 @@
title: Xilinx Zynq FPGA Manager
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
index ac6a207..26f1883 100644
--- a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
+++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
@@ -7,7 +7,7 @@
title: Xilinx Versal FPGA driver.
maintainers:
- - Nava kishore Manne <nava.manne@xilinx.com>
+ - Nava kishore Manne <nava.kishore.manne@amd.com>
description: |
Device Tree Versal FPGA bindings for the Versal SoC, controlled
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml
index 00a8d92..1390ae1 100644
--- a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml
+++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml
@@ -7,7 +7,7 @@
title: Xilinx Zynq Ultrascale MPSoC FPGA Manager
maintainers:
- - Nava kishore Manne <navam@xilinx.com>
+ - Nava kishore Manne <nava.kishore.manne@amd.com>
description: |
Device Tree Bindings for Zynq Ultrascale MPSoC FPGA Manager.
diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
deleted file mode 100644
index 4d69f79..0000000
--- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
+++ /dev/null
@@ -1,86 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Broadcom BCM6345 GPIO controller
-
-maintainers:
- - Álvaro Fernández Rojas <noltari@gmail.com>
- - Jonas Gorski <jonas.gorski@gmail.com>
-
-description: |+
- Bindings for Broadcom's BCM63xx memory-mapped GPIO controllers.
-
- These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
- are the only ones which don't need a pinctrl driver.
-
- BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
- and/or written, and the direction changed from input to output.
- BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
- and/or written, and the direction changed from input to output.
- BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
- and dirout registers, where GPIO state can be read and/or written, and the
- direction changed from input to output.
-
-properties:
- compatible:
- enum:
- - brcm,bcm6318-gpio
- - brcm,bcm6328-gpio
- - brcm,bcm6345-gpio
- - brcm,bcm6358-gpio
- - brcm,bcm6362-gpio
- - brcm,bcm6368-gpio
- - brcm,bcm63268-gpio
-
- gpio-controller: true
-
- "#gpio-cells":
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
- native-endian: true
-
- reg:
- maxItems: 2
-
- reg-names:
- items:
- - const: dirout
- - const: dat
-
-required:
- - compatible
- - reg
- - reg-names
- - gpio-controller
- - '#gpio-cells'
-
-additionalProperties: false
-
-examples:
- - |
- gpio@fffe0406 {
- compatible = "brcm,bcm6345-gpio";
- reg-names = "dirout", "dat";
- reg = <0xfffe0406 2>, <0xfffe040a 2>;
- native-endian;
-
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- - |
- gpio@0 {
- compatible = "brcm,bcm63268-gpio";
- reg-names = "dirout", "dat";
- reg = <0x0 0x8>, <0x8 0x8>;
-
- gpio-controller;
- gpio-ranges = <&pinctrl 0 0 52>;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
new file mode 100644
index 0000000..62fcc2bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/brcm,bcm63xx-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM63xx GPIO controller
+
+maintainers:
+ - Álvaro Fernández Rojas <noltari@gmail.com>
+ - Jonas Gorski <jonas.gorski@gmail.com>
+
+description: |+
+ Bindings for Broadcom's BCM63xx memory-mapped GPIO controllers.
+
+ These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
+ are the only ones which don't need a pinctrl driver.
+
+ BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
+ and/or written, and the direction changed from input to output.
+ BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
+ and dirout registers, where GPIO state can be read and/or written, and the
+ direction changed from input to output.
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm6318-gpio
+ - brcm,bcm6328-gpio
+ - brcm,bcm6358-gpio
+ - brcm,bcm6362-gpio
+ - brcm,bcm6368-gpio
+ - brcm,bcm63268-gpio
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ native-endian: true
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: dirout
+ - const: dat
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@0 {
+ compatible = "brcm,bcm63268-gpio";
+ reg-names = "dirout", "dat";
+ reg = <0x0 0x8>, <0x8 0x8>;
+
+ gpio-controller;
+ gpio-ranges = <&pinctrl 0 0 52>;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-delay.yaml b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml
new file mode 100644
index 0000000..1cebc40
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-delay.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO delay controller
+
+maintainers:
+ - Alexander Stein <linux@ew.tq-group.com>
+
+description: |
+ This binding describes an electrical setup where setting an GPIO output
+ is delayed by some external setup, e.g. RC circuit.
+
+ +----------+ +-----------+
+ | | VCC_B | |
+ | | | | |
+ | | VCC_A _ | |
+ | GPIO | | | R | Consumer |
+ |controller| ___ |_| | |
+ | | | | | | |
+ | [IOx|-------| |--+-----|-----+ |
+ | | |___| | | input |
+ | | | | |
+ +----------+ --- C +-----------+
+ ---
+ |
+ -
+ GND
+
+ If the input on the consumer is controlled by an open-drain signal
+ attached to an RC circuit the ramp-up delay is not under control
+ of the GPIO controller.
+
+properties:
+ compatible:
+ const: gpio-delay
+
+ "#gpio-cells":
+ description: |
+ Specifies the pin, ramp-up and ramp-down delays. The
+ delays are specified in microseconds.
+ const: 3
+
+ gpios:
+ description: Array of GPIOs which output signal change is delayed
+ minItems: 1
+ maxItems: 32
+
+ gpio-controller: true
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 32
+
+required:
+ - compatible
+ - "#gpio-cells"
+ - gpio-controller
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ enable_delay: enable-delay {
+ compatible = "gpio-delay";
+ #gpio-cells = <3>;
+ gpio-controller;
+ gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
+ <&gpio3 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ consumer {
+ enable-gpios = <&enable_delay 0 130000 30000>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml b/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml
new file mode 100644
index 0000000..daadfb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-ep9301.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EP93xx GPIO controller
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+ - Bartosz Golaszewski <brgl@bgdev.pl>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-gpio
+ - items:
+ - enum:
+ - cirrus,ep9302-gpio
+ - cirrus,ep9307-gpio
+ - cirrus,ep9312-gpio
+ - cirrus,ep9315-gpio
+ - const: cirrus,ep9301-gpio
+
+ reg:
+ minItems: 2
+ items:
+ - description: data register
+ - description: direction register
+ - description: interrupt registers base
+
+ reg-names:
+ minItems: 2
+ items:
+ - const: data
+ - const: dir
+ - const: intr
+
+ gpio-controller: true
+
+ gpio-ranges: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ oneOf:
+ - maxItems: 1
+ - description: port F has dedicated irq line for each gpio line
+ maxItems: 8
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@80840000 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840000 0x04>,
+ <0x80840010 0x04>,
+ <0x80840090 0x1c>;
+ reg-names = "data", "dir", "intr";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&vic1>;
+ interrupts = <27>;
+ };
+
+ gpio@80840004 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840004 0x04>,
+ <0x80840014 0x04>,
+ <0x808400ac 0x1c>;
+ reg-names = "data", "dir", "intr";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&vic1>;
+ interrupts = <27>;
+ };
+
+ gpio@80840008 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840008 0x04>,
+ <0x80840018 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@8084000c {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x8084000c 0x04>,
+ <0x8084001c 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@80840020 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840020 0x04>,
+ <0x80840024 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@80840030 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840030 0x04>,
+ <0x80840034 0x04>,
+ <0x8084004c 0x1c>;
+ reg-names = "data", "dir", "intr";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&vic0 19>, <&vic0 20>,
+ <&vic0 21>, <&vic0 22>,
+ <&vic1 15>, <&vic1 16>,
+ <&vic1 17>, <&vic1 18>;
+ };
+
+ gpio@80840038 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840038 0x04>,
+ <0x8084003c 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@80840040 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840040 0x04>,
+ <0x80840044 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
new file mode 100644
index 0000000..b394e05
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-mmio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic MMIO GPIO
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+ - Bartosz Golaszewski <brgl@bgdev.pl>
+
+description:
+ Some simple GPIO controllers may consist of a single data register or a pair
+ of set/clear-bit registers. Such controllers are common for glue logic in
+ FPGAs or ASICs. Commonly, these controllers are accessed over memory-mapped
+ NAND-style parallel busses.
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm6345-gpio
+ - ni,169445-nand-gpio
+ - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
+
+ big-endian: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ little-endian: true
+
+ reg:
+ minItems: 1
+ description:
+ A list of registers in the controller. The width of each register is
+ determined by its size. All registers must have the same width. The number
+ of GPIOs is set by the width, with bit 0 corresponding to GPIO 0.
+ items:
+ - description:
+ Register to READ the value of the GPIO lines. If GPIO line is high,
+ the bit will be set. If the GPIO line is low, the bit will be cleared.
+ This register may also be used to drive GPIOs if the SET register is
+ omitted.
+ - description:
+ Register to SET the value of the GPIO lines. Setting a bit in this
+ register will drive the GPIO line high.
+ - description:
+ Register to CLEAR the value of the GPIO lines. Setting a bit in this
+ register will drive the GPIO line low. If this register is omitted,
+ the SET register will be used to clear the GPIO lines as well, by
+ actively writing the line with 0.
+ - description:
+ Register to set the line as OUTPUT. Setting a bit in this register
+ will turn that line into an output line. Conversely, clearing a bit
+ will turn that line into an input.
+ - description:
+ Register to set this line as INPUT. Setting a bit in this register
+ will turn that line into an input line. Conversely, clearing a bit
+ will turn that line into an output.
+
+ reg-names:
+ minItems: 1
+ maxItems: 5
+ items:
+ enum:
+ - dat
+ - set
+ - clr
+ - dirout
+ - dirin
+
+ native-endian: true
+
+ no-output:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If this property is present, the controller cannot drive the GPIO lines.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - '#gpio-cells'
+ - gpio-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@1f300010 {
+ compatible = "ni,169445-nand-gpio";
+ reg = <0x1f300010 0x4>;
+ reg-names = "dat";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@e0100000 {
+ compatible = "wd,mbl-gpio";
+ reg-names = "dat";
+ reg = <0xe0100000 0x1>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ no-output;
+ };
+
+ gpio@fffe0406 {
+ compatible = "brcm,bcm6345-gpio";
+ reg-names = "dirout", "dat";
+ reg = <0xfffe0406 2>, <0xfffe040a 2>;
+ native-endian;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml
index 5b01343..452f897 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml
@@ -24,6 +24,10 @@
'#gpio-cells':
const: 2
+ gpio-line-names:
+ minItems: 4
+ maxItems: 8
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt b/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt
deleted file mode 100644
index b33f8f0..0000000
--- a/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-STMPE gpio
-----------
-
-Required properties:
- - compatible: "st,stmpe-gpio"
-
-Optional properties:
- - st,norequest-mask: bitmask specifying which GPIOs should _not_ be requestable
- due to different usage (e.g. touch, keypad)
-
-Node should be child node of stmpe node to which it belongs.
-
-Example:
- stmpe_gpio {
- compatible = "st,stmpe-gpio";
- st,norequest-mask = <0x20>; //gpio 5 can't be used
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml
index d2c39db..7c2d152 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml
@@ -61,6 +61,13 @@
gpio-ranges:
maxItems: 1
+patternProperties:
+ "^.+-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
index 572e171..5e24963 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
@@ -7,7 +7,7 @@
title: Xilinx Zynq GPIO controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt b/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
deleted file mode 100644
index ca2f8c7..0000000
--- a/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Bindings for the National Instruments 169445 GPIO NAND controller
-
-The 169445 GPIO NAND controller has two memory mapped GPIO registers, one
-for input (the ready signal) and one for output (control signals). It is
-intended to be used with the GPIO NAND driver.
-
-Required properties:
- - compatible: should be "ni,169445-nand-gpio"
- - reg-names: must contain
- "dat" - data register
- - reg: address + size pairs describing the GPIO register sets;
- order must correspond with the order of entries in reg-names
- - #gpio-cells: must be set to 2. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
- - gpio-controller: Marks the device node as a gpio controller.
-
-Optional properties:
- - no-output: disables driving output on the pins
-
-Examples:
- gpio1: nand-gpio-out@1f300010 {
- compatible = "ni,169445-nand-gpio";
- reg = <0x1f300010 0x4>;
- reg-names = "dat";
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpio2: nand-gpio-in@1f300014 {
- compatible = "ni,169445-nand-gpio";
- reg = <0x1f300014 0x4>;
- reg-names = "dat";
- gpio-controller;
- #gpio-cells = <2>;
- no-output;
- };
diff --git a/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml b/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml
new file mode 100644
index 0000000..22c0cae7
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/st,stmpe-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectonics Port Expander (STMPE) GPIO Block
+
+description:
+ STMicroelectronics Port Expander (STMPE) is a series of slow
+ bus controllers for various expanded peripherals such as GPIO, keypad,
+ touchscreen, ADC, PWM or rotator. It can contain one or several different
+ peripherals connected to SPI or I2C. These bindings pertain to the
+ GPIO portions of these expanders.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ const: st,stmpe-gpio
+
+ "#gpio-cells":
+ const: 2
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-controller: true
+
+ interrupt-controller: true
+
+ st,norequest-mask:
+ description:
+ A bitmask of GPIO lines that cannot be requested because for
+ for example not being connected to anything on the system
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+patternProperties:
+ "^.+-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
+
+additionalProperties: false
+
+required:
+ - compatible
+ - "#gpio-cells"
+ - "#interrupt-cells"
+ - gpio-controller
+ - interrupt-controller
diff --git a/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt b/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
deleted file mode 100644
index 038c3a6..0000000
--- a/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Bindings for the Western Digital's MyBook Live memory-mapped GPIO controllers.
-
-The Western Digital MyBook Live has two memory-mapped GPIO controllers.
-Both GPIO controller only have a single 8-bit data register, where GPIO
-state can be read and/or written.
-
-Required properties:
- - compatible: should be "wd,mbl-gpio"
- - reg-names: must contain
- "dat" - data register
- - reg: address + size pairs describing the GPIO register sets;
- order must correspond with the order of entries in reg-names
- - #gpio-cells: must be set to 2. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
- - gpio-controller: Marks the device node as a gpio controller.
-
-Optional properties:
- - no-output: GPIOs are read-only.
-
-Examples:
- gpio0: gpio0@e0000000 {
- compatible = "wd,mbl-gpio";
- reg-names = "dat";
- reg = <0xe0000000 0x1>;
- #gpio-cells = <2>;
- gpio-controller;
- };
-
- gpio1: gpio1@e0100000 {
- compatible = "wd,mbl-gpio";
- reg-names = "dat";
- reg = <0xe0100000 0x1>;
- #gpio-cells = <2>;
- gpio-controller;
- no-output;
- };
diff --git a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
index 31906c2..1638cfe 100644
--- a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
@@ -44,6 +44,7 @@
- GPIO0
- GPIO1
- GPIO2
+ - GPIO3
function:
enum:
diff --git a/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml b/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml
index f333ee2..c1060e5 100644
--- a/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml
+++ b/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml
@@ -7,7 +7,7 @@
title: Xilinx AXI GPIO controller
maintainers:
- - Neeli Srinivas <srinivas.neeli@xilinx.com>
+ - Neeli Srinivas <srinivas.neeli@amd.com>
description:
The AXI GPIO design provides a general purpose input/output interface
diff --git a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
index 31c0fc34..18e61af 100644
--- a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
+++ b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
@@ -12,7 +12,7 @@
PS_MODE). Every pin can be configured as input/output.
maintainers:
- - Piyush Mehta <piyush.mehta@xilinx.com>
+ - Piyush Mehta <piyush.mehta@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
index 0400a361..e796a1f 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -86,7 +86,7 @@
const: 2
dynamic-power-coefficient:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
A u32 value that represents the running time dynamic
power coefficient in units of uW/MHz/V^2. The
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
index 2a25384..ca02bab 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -92,7 +92,7 @@
dma-coherent: true
dynamic-power-coefficient:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
A u32 value that represents the running time dynamic
power coefficient in units of uW/MHz/V^2. The
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
index 318122d..0fae1ef 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
@@ -33,6 +33,7 @@
- rockchip,rk3228-mali
- samsung,exynos4210-mali
- stericsson,db8500-mali
+ - xlnx,zynqmp-mali
- const: arm,mali-400
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/hwmon/adi,max31827.yaml b/Documentation/devicetree/bindings/hwmon/adi,max31827.yaml
new file mode 100644
index 0000000..2dc8b07
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,max31827.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,max31827.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX31827, MAX31828, MAX31829 Low-Power Temperature Switch
+
+maintainers:
+ - Daniel Matyas <daniel.matyas@analog.com>
+
+description: |
+ Analog Devices MAX31827, MAX31828, MAX31829 Low-Power Temperature Switch with
+ I2C Interface
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31827-MAX31829.pdf
+
+properties:
+ compatible:
+ oneOf:
+ - const: adi,max31827
+ - items:
+ - enum:
+ - adi,max31828
+ - adi,max31829
+ - const: adi,max31827
+
+ reg:
+ maxItems: 1
+
+ vref-supply:
+ description:
+ Must have values in the interval (1.6V; 3.6V) in order for the device to
+ function correctly.
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@42 {
+ compatible = "adi,max31827";
+ reg = <0x42>;
+ vref-supply = <®_vdd>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
index ae4f68d..bd67cfe 100644
--- a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
+++ b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
@@ -105,7 +105,7 @@
G coefficient for temperature equation.
Default for series 5 = 60000
Default for series 6 = 57400
- multipleOf: 1000
+ multipleOf: 100
minimum: 1000
$ref: /schemas/types.yaml#/definitions/uint32
@@ -114,7 +114,7 @@
H coefficient for temperature equation.
Default for series 5 = 200000
Default for series 6 = 249400
- multipleOf: 1000
+ multipleOf: 100
minimum: 1000
$ref: /schemas/types.yaml#/definitions/uint32
@@ -131,7 +131,7 @@
J coefficient for temperature equation.
Default for series 5 = -100
Default for series 6 = 0
- multipleOf: 1000
+ multipleOf: 100
maximum: 0
$ref: /schemas/types.yaml#/definitions/int32
diff --git a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
index cb24d7b..ff57c54 100644
--- a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
+++ b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
@@ -7,7 +7,7 @@
title: Cadence I2C controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
diff --git a/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml b/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml
index 85d9efb..d9ef867 100644
--- a/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml
+++ b/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml
@@ -60,6 +60,7 @@
default: 0
regstep:
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
deprecated, use reg-shift above
deprecated: true
diff --git a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
index 32c821f..133855f 100644
--- a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
+++ b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
@@ -10,7 +10,7 @@
- Conor Culhane <conor.culhane@silvaco.com>
allOf:
- - $ref: "i3c.yaml#"
+ - $ref: i3c.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
index d521d51..16def29 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
@@ -47,6 +47,9 @@
avdd-supply:
description: AVdd voltage supply
+ vref-supply:
+ description: VRef voltage supply
+
adi,rejection-60-Hz-enable:
description: |
This bit enables a notch at 60 Hz when the first notch of the sinc
@@ -89,6 +92,7 @@
- interrupts
- dvdd-supply
- avdd-supply
+ - vref-supply
- spi-cpol
- spi-cpha
@@ -115,6 +119,7 @@
interrupt-parent = <&gpio>;
dvdd-supply = <&dvdd>;
avdd-supply = <&avdd>;
+ vref-supply = <&vref>;
adi,refin2-pins-enable;
adi,rejection-60-Hz-enable;
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
index 7f79a06..6168b44 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
@@ -26,6 +26,7 @@
- mediatek,mt2712-auxadc
- mediatek,mt6765-auxadc
- mediatek,mt7622-auxadc
+ - mediatek,mt7986-auxadc
- mediatek,mt8173-auxadc
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
index bd6e0d6..ad7d6fc 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
@@ -54,7 +54,7 @@
- '#io-channel-cells'
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
type: object
additionalProperties: false
description: |
@@ -101,7 +101,7 @@
oneOf:
- items:
- const: 1
- - enum: [ 1, 3, 4, 6, 20, 8, 10 ]
+ - enum: [ 1, 3, 4, 6, 20, 8, 10, 16 ]
- items:
- const: 10
- const: 81
@@ -148,7 +148,7 @@
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 512, 1024, 2048, 4096 ]
@@ -171,7 +171,7 @@
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 256, 512, 1024 ]
@@ -194,7 +194,7 @@
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 250, 420, 840 ]
@@ -217,7 +217,7 @@
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 85, 340, 1360 ]
@@ -249,7 +249,7 @@
#io-channel-cells = <1>;
/* Channel node */
- adc-chan@39 {
+ channel@39 {
reg = <0x39>;
qcom,decimation = <512>;
qcom,ratiometric;
@@ -258,19 +258,19 @@
qcom,pre-scaling = <1 3>;
};
- adc-chan@9 {
+ channel@9 {
reg = <0x9>;
};
- adc-chan@a {
+ channel@a {
reg = <0xa>;
};
- adc-chan@e {
+ channel@e {
reg = <0xe>;
};
- adc-chan@f {
+ channel@f {
reg = <0xf>;
};
};
@@ -292,16 +292,18 @@
#io-channel-cells = <1>;
/* Other properties are omitted */
- xo-therm@44 {
+ channel@44 {
reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>;
qcom,ratiometric;
qcom,hw-settle-time = <200>;
+ label = "xo_therm";
};
- conn-therm@47 {
+ channel@47 {
reg = <PM8350_ADC7_AMUX_THM4_100K_PU(1)>;
qcom,ratiometric;
qcom,hw-settle-time = <200>;
+ label = "conn_therm";
};
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml
index da50b52..aa24b84 100644
--- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml
@@ -15,6 +15,7 @@
- const: rockchip,saradc
- const: rockchip,rk3066-tsadc
- const: rockchip,rk3399-saradc
+ - const: rockchip,rk3588-saradc
- items:
- enum:
- rockchip,px30-saradc
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml
index 9b072b0..a60b1e1 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml
@@ -35,7 +35,7 @@
examples:
- |
spi {
- #address-cells= <1>;
+ #address-cells = <1>;
#size-cells = <0>;
adc@0 {
diff --git a/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml b/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml
index 72d2e91..2594fa1 100644
--- a/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml
+++ b/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml
@@ -216,7 +216,6 @@
description: Whether to enable burnout current for EXT1.
adi,ext1-burnout-current-nanoamp:
- $ref: /schemas/types.yaml#/definitions/uint32
description:
Burnout current in nanoamps to be applied to EXT1.
enum: [0, 50, 500, 1000, 10000]
@@ -233,7 +232,6 @@
description: Whether to enable burnout current for EXT2.
adi,ext2-burnout-current-nanoamp:
- $ref: /schemas/types.yaml#/definitions/uint32
description: Burnout current in nanoamps to be applied to EXT2.
enum: [0, 50, 500, 1000, 10000]
default: 0
@@ -249,7 +247,6 @@
description: Whether to enable burnout current for VIOUT.
adi,viout-burnout-current-nanoamp:
- $ref: /schemas/types.yaml#/definitions/uint32
description: Burnout current in nanoamps to be applied to VIOUT.
enum: [0, 1000, 10000]
default: 0
diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
index df2589f..dddf97b 100644
--- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
+++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
@@ -13,7 +13,7 @@
When an io-channel measures the midpoint of a voltage divider, the
interesting voltage is often the voltage over the full resistance
of the divider. This binding describes the voltage divider in such
- a curcuit.
+ a circuit.
Vin ----.
|
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
index ec64d78..1db6952 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
@@ -31,6 +31,9 @@
- invensense,mpu9250
- invensense,mpu9255
- items:
+ - const: invensense,icm20600
+ - const: invensense,icm20602
+ - items:
- const: invensense,icm20608d
- const: invensense,icm20608
diff --git a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
index b39f521..ee8724a 100644
--- a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
@@ -98,6 +98,7 @@
- reg
allOf:
+ - $ref: /schemas/iio/iio.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bu27008.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bu27008.yaml
new file mode 100644
index 0000000..4f66fd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/rohm,bu27008.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/rohm,bu27008.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BU27008 color sensor
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description:
+ The ROHM BU27008 is a sensor with 5 photodiodes (red, green, blue, clear
+ and IR) with four configurable channels. Red and green being always
+ available and two out of the rest three (blue, clear, IR) can be
+ selected to be simultaneously measured. Typical application is adjusting
+ LCD backlight of TVs, mobile phones and tablet PCs.
+
+properties:
+ compatible:
+ const: rohm,bu27008
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@38 {
+ compatible = "rohm,bu27008";
+ reg = <0x38>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml b/Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml
new file mode 100644
index 0000000..12b0c7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/ti,opt4001.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments OPT4001 Ambient Light Sensor
+
+maintainers:
+ - Stefan Windfeldt-Prytz <stefan.windfeldt-prytz@axis.com>
+
+description:
+ Ambient light sensor with an i2c interface.
+ Last part of compatible is for the packaging used.
+ Picostar is a 4 pinned SMT and sot-5x3 is a 8 pinned SOT.
+ https://www.ti.com/lit/gpn/opt4001
+
+properties:
+ compatible:
+ enum:
+ - ti,opt4001-picostar
+ - ti,opt4001-sot-5x3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator that provides power to the sensor
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,opt4001-sot-5x3
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ else:
+ properties:
+ interrupts: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@44 {
+ compatible = "ti,opt4001-sot-5x3";
+ reg = <0x44>;
+ vdd-supply = <&vdd_reg>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml b/Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml
new file mode 100644
index 0000000..ab5c09c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/potentiometer/renesas,x9250.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas X9250 quad potentiometers
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ The Renesas X9250 integrates four digitally controlled potentiometers.
+ On each potentiometer, the X9250T has a 100 kOhms total resistance and the
+ X9250U has a 50 kOhms total resistance.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+
+properties:
+ compatible:
+ enum:
+ - renesas,x9250t
+ - renesas,x9250u
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description:
+ Regulator for the VCC power supply.
+
+ avp-supply:
+ description:
+ Regulator for the analog V+ power supply.
+
+ avn-supply:
+ description:
+ Regulator for the analog V- power supply.
+
+ '#io-channel-cells':
+ const: 1
+
+ spi-max-frequency:
+ maximum: 2000000
+
+ wp-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the write-protect pin.
+
+required:
+ - compatible
+ - reg
+ - vcc-supply
+ - avp-supply
+ - avn-supply
+ - '#io-channel-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ potentiometer@0 {
+ compatible = "renesas,x9250t";
+ reg = <0>;
+ vcc-supply = <&vcc_regulator>;
+ avp-supply = <&avp_regulator>;
+ avn-supply = <&avp_regulator>;
+ wp-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <2000000>;
+ #io-channel-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml
new file mode 100644
index 0000000..c0a923f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/honeywell,mprls0025pa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Honeywell mprls0025pa pressure sensor
+
+maintainers:
+ - Andreas Klinger <ak@it-klinger.de>
+
+description: |
+ Honeywell pressure sensor of model mprls0025pa.
+
+ This sensor has an I2C and SPI interface. Only the I2C interface is
+ implemented.
+
+ 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.
+
+ 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.
+
+ Specifications about the devices can be found at:
+ https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/
+ products/sensors/pressure-sensors/board-mount-pressure-sensors/
+ micropressure-mpr-series/documents/
+ sps-siot-mpr-series-datasheet-32332628-ciid-172626.pdf
+
+properties:
+ compatible:
+ const: honeywell,mprls0025pa
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ Optional GPIO for resetting the device.
+ If not present the device is not resetted during the probe.
+ maxItems: 1
+
+ honeywell,pmin-pascal:
+ description:
+ Minimum pressure value the sensor can measure in pascal.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ honeywell,pmax-pascal:
+ description:
+ Maximum pressure value the sensor can measure in pascal.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ 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
+
+ vdd-supply:
+ description: provide VDD power to the sensor.
+
+required:
+ - compatible
+ - reg
+ - honeywell,pmin-pascal
+ - honeywell,pmax-pascal
+ - honeywell,transfer-function
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@18 {
+ compatible = "honeywell,mprls0025pa";
+ 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>;
+ honeywell,transfer-function = <1>;
+ vdd-supply = <&vcc_3v3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
index 1ff3afc..e450821 100644
--- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
+++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
@@ -84,6 +84,7 @@
- st,lps35hw
- description: IMUs
enum:
+ - st,lsm303d-imu
- st,lsm9ds0-imu
- description: Deprecated bindings
enum:
diff --git a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml
index d6965a0..654d31f 100644
--- a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/temperature/melexis,mlx90614.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Melexis MLX90614 contactless IR temperature sensor
+title: Melexis MLX90614/MLX90615 contactless IR temperature sensor
maintainers:
- Peter Meerwald <pmeerw@pmeerw.net>
@@ -15,7 +15,9 @@
properties:
compatible:
- const: melexis,mlx90614
+ enum:
+ - melexis,mlx90614
+ - melexis,mlx90615
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml
new file mode 100644
index 0000000..d43002b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/ti,tmp006.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TMP006 IR thermopile sensor
+
+maintainers:
+ - Peter Meerwald <pmeerw@pmeerw.net>
+
+description: |
+ TI TMP006 - Infrared Thermopile Sensor in Chip-Scale Package.
+ https://cdn.sparkfun.com/datasheets/Sensors/Temp/tmp006.pdf
+
+properties:
+ compatible:
+ const: ti,tmp006
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: provide VDD power to the sensor.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ temperature-sensor@40 {
+ compatible = "ti,tmp006";
+ reg = <0x40>;
+ vdd-supply = <&ldo4_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
index 3ec579d..c407993 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -14,6 +14,9 @@
Atmel maXTouch touchscreen or touchpads such as the mXT244
and similar devices.
+allOf:
+ - $ref: input.yaml#
+
properties:
compatible:
const: atmel,maxtouch
@@ -60,6 +63,10 @@
or experiment to determine which bit corresponds to which input. Use
KEY_RESERVED for unused padding values.
+ linux,keycodes:
+ minItems: 1
+ maxItems: 8
+
atmel,wakeup-method:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.txt b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
deleted file mode 100644
index d3db659..0000000
--- a/Documentation/devicetree/bindings/input/cypress,cyapa.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Cypress I2C Touchpad
-
-Required properties:
-- compatible: must be "cypress,cyapa".
-- reg: I2C address of the chip.
-- interrupts: interrupt to which the chip is connected (see interrupt
- binding[0]).
-
-Optional properties:
-- wakeup-source: touchpad can be used as a wakeup source.
-- pinctrl-names: should be "default" (see pinctrl binding [1]).
-- pinctrl-0: a phandle pointing to the pin settings for the device (see
- pinctrl binding [1]).
-- vcc-supply: a phandle for the regulator supplying 3.3V power.
-
-[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-Example:
- &i2c0 {
- /* ... */
-
- /* Cypress Gen3 touchpad */
- touchpad@67 {
- compatible = "cypress,cyapa";
- reg = <0x67>;
- interrupt-parent = <&gpio>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
- wakeup-source;
- };
-
- /* Cypress Gen5 and later touchpad */
- touchpad@24 {
- compatible = "cypress,cyapa";
- reg = <0x24>;
- interrupt-parent = <&gpio>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
- wakeup-source;
- };
-
- /* ... */
- };
diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.yaml b/Documentation/devicetree/bindings/input/cypress,cyapa.yaml
new file mode 100644
index 0000000..2951515
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cypress,cyapa.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/cypress,cyapa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cypress All Points Addressable (APA) I2C Touchpad / Trackpad
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+properties:
+ compatible:
+ const: cypress,cyapa
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ wakeup-source: true
+
+ vcc-supply:
+ description: 3.3V power
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ trackpad@67 {
+ reg = <0x67>;
+ compatible = "cypress,cyapa";
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpx1>;
+ wakeup-source;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
index ce18d7d..1edad1d 100644
--- a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
+++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
@@ -43,6 +43,15 @@
itself as long as it allows the main board to make signals compatible
with what the touchscreen is expecting for its IO rails.
+ goodix,no-reset-during-suspend:
+ description:
+ Set this to true to enforce the driver to not assert the reset GPIO
+ during suspend.
+ Due to potential touchscreen hardware flaw, back-powering could happen in
+ suspend if the power supply is on and with active-low reset GPIO asserted.
+ This property is used to avoid the back-powering issue.
+ type: boolean
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
index 037c3ae..e34c9e7 100644
--- a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
+++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
@@ -55,7 +55,7 @@
interrupt-names: true
- linux-keycodes:
+ linux,keycodes:
maxItems: 1
wakeup-source: true
diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.yaml b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml
index d32716c..6398534 100644
--- a/Documentation/devicetree/bindings/input/pwm-vibrator.yaml
+++ b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml
@@ -32,6 +32,8 @@
minItems: 1
maxItems: 2
+ enable-gpios: true
+
vcc-supply: true
direction-duty-cycle-ns:
diff --git a/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml b/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
index 1959ec3..4080422 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
@@ -40,6 +40,8 @@
linux,keycodes:
description: EV_ABS specific event code generated by the axis.
+ wakeup-source: true
+
patternProperties:
"^button@[0-9]+$":
type: object
diff --git a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml
index f7a5e31..fc21fe3 100644
--- a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml
+++ b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml
@@ -51,7 +51,7 @@
type: object
fsl,ddrc:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to DDR Controller.
diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
deleted file mode 100644
index bde63f8..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Amlogic meson GPIO interrupt controller
-
-Meson SoCs contains an interrupt controller which is able to watch the SoC
-pads and generate an interrupt on edge or level. The controller is essentially
-a 256 pads to 8 GIC interrupt multiplexer, with a filter block to select edge
-or level and polarity. It does not expose all 256 mux inputs because the
-documentation shows that the upper part is not mapped to any pad. The actual
-number of interrupt exposed depends on the SoC.
-
-Required properties:
-
-- compatible : must have "amlogic,meson8-gpio-intc" and either
- "amlogic,meson8-gpio-intc" for meson8 SoCs (S802) or
- "amlogic,meson8b-gpio-intc" for meson8b SoCs (S805) or
- "amlogic,meson-gxbb-gpio-intc" for GXBB SoCs (S905) or
- "amlogic,meson-gxl-gpio-intc" for GXL SoCs (S905X, S912)
- "amlogic,meson-axg-gpio-intc" for AXG SoCs (A113D, A113X)
- "amlogic,meson-g12a-gpio-intc" for G12A SoCs (S905D2, S905X2, S905Y2)
- "amlogic,meson-sm1-gpio-intc" for SM1 SoCs (S905D3, S905X3, S905Y3)
- "amlogic,meson-a1-gpio-intc" for A1 SoCs (A113L)
- "amlogic,meson-s4-gpio-intc" for S4 SoCs (S802X2, S905Y4, S805X2G, S905W2)
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller.
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value must be 2.
-- meson,channel-interrupts: Array with the 8 upstream hwirq numbers. These
- are the hwirqs used on the parent interrupt controller.
-
-Example:
-
-gpio_interrupt: interrupt-controller@9880 {
- compatible = "amlogic,meson-gxbb-gpio-intc",
- "amlogic,meson-gpio-intc";
- reg = <0x0 0x9880 0x0 0x10>;
- interrupt-controller;
- #interrupt-cells = <2>;
- meson,channel-interrupts = <64 65 66 67 68 69 70 71>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml
new file mode 100644
index 0000000..e84e4f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/amlogic,meson-gpio-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson GPIO interrupt controller
+
+maintainers:
+ - Heiner Kallweit <hkallweit1@gmail.com>
+
+description: |
+ Meson SoCs contains an interrupt controller which is able to watch the SoC
+ pads and generate an interrupt on edge or level. The controller is essentially
+ a 256 pads to 8 or 12 GIC interrupt multiplexer, with a filter block to select
+ edge or level and polarity. It does not expose all 256 mux inputs because the
+ documentation shows that the upper part is not mapped to any pad. The actual
+ number of interrupts exposed depends on the SoC.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,meson-gpio-intc
+ - items:
+ - enum:
+ - amlogic,meson8-gpio-intc
+ - amlogic,meson8b-gpio-intc
+ - amlogic,meson-gxbb-gpio-intc
+ - amlogic,meson-gxl-gpio-intc
+ - amlogic,meson-axg-gpio-intc
+ - amlogic,meson-g12a-gpio-intc
+ - amlogic,meson-sm1-gpio-intc
+ - amlogic,meson-a1-gpio-intc
+ - amlogic,meson-s4-gpio-intc
+ - const: amlogic,meson-gpio-intc
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ amlogic,channel-interrupts:
+ description: Array with the upstream hwirq numbers
+ minItems: 8
+ maxItems: 12
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - "#interrupt-cells"
+ - amlogic,channel-interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@9880 {
+ compatible = "amlogic,meson-gxbb-gpio-intc",
+ "amlogic,meson-gpio-intc";
+ reg = <0x9880 0x10>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ amlogic,channel-interrupts = <64 65 66 67 68 69 70 71>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml
new file mode 100644
index 0000000..393c128
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,eiointc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson Extended I/O Interrupt Controller
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+description: |
+ This interrupt controller is found on the Loongson-3 family chips and
+ Loongson-2K series chips and is used to distribute interrupts directly to
+ individual cores without forwarding them through the HT's interrupt line.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls2k0500-eiointc
+ - loongson,ls2k2000-eiointc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ eiointc: interrupt-controller@1fe11600 {
+ compatible = "loongson,ls2k0500-eiointc";
+ reg = <0x1fe10000 0x10000>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <3>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml
deleted file mode 100644
index 5000388..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml
+++ /dev/null
@@ -1,73 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/interrupt-controller/microchip,eic.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip External Interrupt Controller
-
-maintainers:
- - Claudiu Beznea <claudiu.beznea@microchip.com>
-
-description:
- This interrupt controller is found in Microchip SoCs (SAMA7G5) and provides
- support for handling up to 2 external interrupt lines.
-
-properties:
- compatible:
- enum:
- - microchip,sama7g5-eic
-
- reg:
- maxItems: 1
-
- interrupt-controller: true
-
- '#interrupt-cells':
- const: 2
- description:
- The first cell is the input IRQ number (between 0 and 1), the second cell
- is the trigger type as defined in interrupt.txt present in this directory.
-
- interrupts:
- description: |
- Contains the GIC SPI IRQs mapped to the external interrupt lines. They
- should be specified sequentially from output 0 to output 1.
- minItems: 2
- maxItems: 2
-
- clocks:
- maxItems: 1
-
- clock-names:
- const: pclk
-
-required:
- - compatible
- - reg
- - interrupt-controller
- - '#interrupt-cells'
- - interrupts
- - clocks
- - clock-names
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- eic: interrupt-controller@e1628000 {
- compatible = "microchip,sama7g5-eic";
- reg = <0xe1628000 0x100>;
- interrupt-parent = <&gic>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&pmc PMC_TYPE_PERIPHERAL 37>;
- clock-names = "pclk";
- };
-
-...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml
new file mode 100644
index 0000000..d56ba65
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/microchip,sama7g5-eic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip External Interrupt Controller
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description:
+ This interrupt controller is found in Microchip SoCs (SAMA7G5) and provides
+ support for handling up to 2 external interrupt lines.
+
+properties:
+ compatible:
+ enum:
+ - microchip,sama7g5-eic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+ description:
+ The first cell is the input IRQ number (between 0 and 1), the second cell
+ is the trigger type as defined in interrupt.txt present in this directory.
+
+ interrupts:
+ description: |
+ Contains the GIC SPI IRQs mapped to the external interrupt lines. They
+ should be specified sequentially from output 0 to output 1.
+ minItems: 2
+ maxItems: 2
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: pclk
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ eic: interrupt-controller@e1628000 {
+ compatible = "microchip,sama7g5-eic";
+ reg = <0xe1628000 0x100>;
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 37>;
+ clock-names = "pclk";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml
new file mode 100644
index 0000000..0fa952a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/ralink,rt2880-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ralink SoCs Interrupt Controller
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+description:
+ This interrupt controller support a central point for interrupt aggregation
+ for platform related blocks.
+
+properties:
+ compatible:
+ const: ralink,rt2880-intc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@200 {
+ compatible = "ralink,rt2880-intc";
+ reg = <0x200 0x100>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <2>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index f75736a..dc1f28e 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -57,14 +57,15 @@
- const: andestech,nceplic100
- items:
- enum:
+ - canaan,k210-plic
- sifive,fu540-c000-plic
- starfive,jh7100-plic
- starfive,jh7110-plic
- - canaan,k210-plic
- const: sifive,plic-1.0.0
- items:
- enum:
- allwinner,sun20i-d1-plic
+ - thead,th1520-plic
- const: thead,c900-plic
- items:
- const: sifive,plic-1.0.0
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index ba677d4..3a31a97 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -29,6 +29,7 @@
- qcom,msm8996-smmu-v2
- qcom,msm8998-smmu-v2
- qcom,sdm630-smmu-v2
+ - qcom,sm6375-smmu-v2
- const: qcom,smmu-v2
- description: Qcom SoCs implementing "qcom,smmu-500" and "arm,mmu-500"
@@ -45,6 +46,7 @@
- qcom,sdm845-smmu-500
- qcom,sdx55-smmu-500
- qcom,sdx65-smmu-500
+ - qcom,sdx75-smmu-500
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- qcom,sm6350-smmu-500
@@ -79,7 +81,9 @@
- description: Qcom Adreno GPUs implementing "qcom,smmu-500" and "arm,mmu-500"
items:
- enum:
+ - qcom,sa8775p-smmu-500
- qcom,sc7280-smmu-500
+ - qcom,sc8280xp-smmu-500
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- qcom,sm8150-smmu-500
@@ -267,6 +271,7 @@
enum:
- qcom,msm8998-smmu-v2
- qcom,sdm630-smmu-v2
+ - qcom,sm6375-smmu-v2
then:
anyOf:
- properties:
@@ -331,7 +336,10 @@
properties:
compatible:
contains:
- const: qcom,sc7280-smmu-500
+ enum:
+ - qcom,sa8775p-smmu-500
+ - qcom,sc7280-smmu-500
+ - qcom,sc8280xp-smmu-500
then:
properties:
clock-names:
@@ -413,10 +421,8 @@
- nvidia,smmu-500
- qcom,qcm2290-smmu-500
- qcom,qdu1000-smmu-500
- - qcom,sa8775p-smmu-500
- qcom,sc7180-smmu-500
- qcom,sc8180x-smmu-500
- - qcom,sc8280xp-smmu-500
- qcom,sdm670-smmu-500
- qcom,sdm845-smmu-500
- qcom,sdx55-smmu-500
diff --git a/Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml b/Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml
new file mode 100644
index 0000000..feb5feb
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/awinic,aw200xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AWINIC AW200XX LED
+
+maintainers:
+ - Martin Kurbanov <mmkurbanov@sberdevices.ru>
+
+description: |
+ This controller is present on AW20036/AW20054/AW20072.
+ It is a 3x12/6x9/6x12 matrix LED programmed via
+ an I2C interface, up to 36/54/72 LEDs or 12/18/24 RGBs,
+ 3 pattern controllers for auto breathing or group dimming control.
+
+ For more product information please see the link below:
+ aw20036 - https://www.awinic.com/en/productDetail/AW20036QNR#tech-docs
+ aw20054 - https://www.awinic.com/en/productDetail/AW20054QNR#tech-docs
+ aw20072 - https://www.awinic.com/en/productDetail/AW20072QNR#tech-docs
+
+properties:
+ compatible:
+ enum:
+ - awinic,aw20036
+ - awinic,aw20054
+ - awinic,aw20072
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ awinic,display-rows:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Leds matrix size
+
+patternProperties:
+ "^led@[0-9a-f]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ LED number
+ maxItems: 1
+
+ led-max-microamp:
+ default: 9780
+ description: |
+ Note that a driver will take the minimum of all LED limits
+ since the chip has a single global setting.
+ The maximum output current of each LED is calculated by the
+ following formula:
+ IMAXled = 160000 * (592 / 600.5) * (1 / display-rows)
+ And the minimum output current formula:
+ IMINled = 3300 * (592 / 600.5) * (1 / display-rows)
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - awinic,display-rows
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: awinic,aw20036
+ then:
+ properties:
+ awinic,display-rows:
+ enum: [1, 2, 3]
+ else:
+ properties:
+ awinic,display-rows:
+ enum: [1, 2, 3, 4, 5, 6, 7]
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@3a {
+ compatible = "awinic,aw20036";
+ reg = <0x3a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ awinic,display-rows = <3>;
+
+ led@0 {
+ reg = <0x0>;
+ color = <LED_COLOR_ID_RED>;
+ led-max-microamp = <9780>;
+ };
+
+ led@1 {
+ reg = <0x1>;
+ color = <LED_COLOR_ID_GREEN>;
+ led-max-microamp = <9780>;
+ };
+
+ led@2 {
+ reg = <0x2>;
+ color = <LED_COLOR_ID_BLUE>;
+ led-max-microamp = <9780>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
index e119145..c914e12 100644
--- a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
@@ -21,6 +21,9 @@
compatible:
const: kinetic,ktz8866
+ reg:
+ maxItems: 1
+
vddpos-supply:
description: positive boost supply regulator.
@@ -33,6 +36,7 @@
current-num-sinks:
description: number of the LED current sinks' channels.
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 2, 3, 4, 5, 6]
kinetic,current-ramp-delay-ms:
@@ -53,6 +57,7 @@
required:
- compatible
+ - reg
- vddpos-supply
- vddneg-supply
- enable-gpios
@@ -63,14 +68,19 @@
- |
#include <dt-bindings/gpio/gpio.h>
- backlight {
- compatible = "kinetic,ktz8866";
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
- vddpos-supply = <&bl_vddpos_5p5>;
- vddneg-supply = <&bl_vddneg_5p5>;
- enable-gpios = <&tlmm 139 GPIO_ACTIVE_HIGH>;
- current-num-sinks = <5>;
- kinetic,current-ramp-delay-ms = <128>;
- kinetic,led-enable-ramp-delay-ms = <1>;
- kinetic,enable-lcd-bias;
+ backlight@11 {
+ compatible = "kinetic,ktz8866";
+ reg = <0x11>;
+ vddpos-supply = <&bl_vddpos_5p5>;
+ vddneg-supply = <&bl_vddneg_5p5>;
+ enable-gpios = <&tlmm 139 GPIO_ACTIVE_HIGH>;
+ current-num-sinks = <5>;
+ kinetic,current-ramp-delay-ms = <128>;
+ kinetic,led-enable-ramp-delay-ms = <1>;
+ kinetic,enable-lcd-bias;
+ };
};
diff --git a/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml
new file mode 100644
index 0000000..9416e1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/lp855x-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments LP855X backlight controllers
+
+maintainers:
+ - Artur Weber <aweber.kernel@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,lp8550
+ - ti,lp8551
+ - ti,lp8552
+ - ti,lp8553
+ - ti,lp8555
+ - ti,lp8556
+ - ti,lp8557
+
+ reg:
+ maxItems: 1
+
+ dev-ctrl:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description:
+ Value of device control register. This is a device-specific value.
+
+ bl-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Backlight device name.
+
+ init-brt:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: Initial value of backlight brightness.
+
+ power-supply:
+ description: Regulator which controls the 3V rail.
+
+ enable-supply:
+ description: Regulator which controls the EN/VDDIO input.
+
+ pwms:
+ maxItems: 1
+ description: |
+ PWM channel to use for controlling the backlight; setting this
+ enables the PWM-based backlight control mode.
+
+ pwm-names: true
+
+ pwm-period:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ PWM period value. Deprecated; set the period value in the pwms
+ property instead.
+ deprecated: true
+
+patternProperties:
+ "^rom-[0-9a-f]{2}h$":
+ type: object
+ description: Nodes containing the values of configuration registers.
+ additionalProperties: false
+ properties:
+ rom-addr:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: Register address of ROM area to be updated.
+
+ rom-val:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: Value to write to the ROM register.
+
+required:
+ - compatible
+ - reg
+ - dev-ctrl
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@2c {
+ compatible = "ti,lp8555";
+ reg = <0x2c>;
+
+ dev-ctrl = /bits/ 8 <0x00>;
+
+ pwms = <&pwm 0 10000>;
+ pwm-names = "lp8555";
+
+ /* 4V OV, 4 output LED0 string enabled */
+ rom-14h {
+ rom-addr = /bits/ 8 <0x14>;
+ rom-val = /bits/ 8 <0xcf>;
+ };
+
+ /* Heavy smoothing, 24ms ramp time step */
+ rom-15h {
+ rom-addr = /bits/ 8 <0x15>;
+ rom-val = /bits/ 8 <0xc7>;
+ };
+
+ /* 4 output LED1 string enabled */
+ rom-19h {
+ rom-addr = /bits/ 8 <0x19>;
+ rom-val = /bits/ 8 <0x0f>;
+ };
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@2c {
+ compatible = "ti,lp8556";
+ reg = <0x2c>;
+
+ bl-name = "lcd-bl";
+ dev-ctrl = /bits/ 8 <0x85>;
+ init-brt = /bits/ 8 <0x10>;
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@2c {
+ compatible = "ti,lp8557";
+ reg = <0x2c>;
+ enable-supply = <&backlight_vddio>;
+ power-supply = <&backlight_vdd>;
+
+ dev-ctrl = /bits/ 8 <0x41>;
+ init-brt = /bits/ 8 <0x0a>;
+
+ /* 4V OV, 4 output LED string enabled */
+ rom-14h {
+ rom-addr = /bits/ 8 <0x14>;
+ rom-val = /bits/ 8 <0xcf>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/lp855x.txt b/Documentation/devicetree/bindings/leds/backlight/lp855x.txt
deleted file mode 100644
index 88f5664..0000000
--- a/Documentation/devicetree/bindings/leds/backlight/lp855x.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-lp855x bindings
-
-Required properties:
- - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
- "ti,lp8555", "ti,lp8556", "ti,lp8557"
- - reg: I2C slave address (u8)
- - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
-
-Optional properties:
- - bl-name: Backlight device name (string)
- - init-brt: Initial value of backlight brightness (u8)
- - pwm-period: PWM period value. Set only PWM input mode used (u32)
- - rom-addr: Register address of ROM area to be updated (u8)
- - rom-val: Register value to be updated (u8)
- - power-supply: Regulator which controls the 3V rail
- - enable-supply: Regulator which controls the EN/VDDIO input
-
-Example:
-
- /* LP8555 */
- backlight@2c {
- compatible = "ti,lp8555";
- reg = <0x2c>;
-
- dev-ctrl = /bits/ 8 <0x00>;
- pwm-period = <10000>;
-
- /* 4V OV, 4 output LED0 string enabled */
- rom_14h {
- rom-addr = /bits/ 8 <0x14>;
- rom-val = /bits/ 8 <0xcf>;
- };
-
- /* Heavy smoothing, 24ms ramp time step */
- rom_15h {
- rom-addr = /bits/ 8 <0x15>;
- rom-val = /bits/ 8 <0xc7>;
- };
-
- /* 4 output LED1 string enabled */
- rom_19h {
- rom-addr = /bits/ 8 <0x19>;
- rom-val = /bits/ 8 <0x0f>;
- };
- };
-
- /* LP8556 */
- backlight@2c {
- compatible = "ti,lp8556";
- reg = <0x2c>;
-
- bl-name = "lcd-bl";
- dev-ctrl = /bits/ 8 <0x85>;
- init-brt = /bits/ 8 <0x10>;
- };
-
- /* LP8557 */
- backlight@2c {
- compatible = "ti,lp8557";
- reg = <0x2c>;
- enable-supply = <&backlight_vddio>;
- power-supply = <&backlight_vdd>;
-
- dev-ctrl = /bits/ 8 <0x41>;
- init-brt = /bits/ 8 <0x0a>;
-
- /* 4V OV, 4 output LED string enabled */
- rom_14h {
- rom-addr = /bits/ 8 <0x14>;
- rom-val = /bits/ 8 <0xcf>;
- };
- };
diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
index 5ec47a8..5356902 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
@@ -68,7 +68,6 @@
required:
- compatible
- pwms
- - power-supply
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index 11aedf1..58b492d 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -105,8 +105,6 @@
- audio-mute
# LED indicates bluetooth power state
- bluetooth-power
- # LED indicates activity of all CPUs
- - cpu
# LED indicates camera flash state
- flash
# LED indicated keyboard capslock
diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
index 31840e3..e850a88 100644
--- a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
@@ -34,7 +34,7 @@
- color
allOf:
- - $ref: "common.yaml#"
+ - $ref: common.yaml#
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
index ae60791..058be1f 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
@@ -66,6 +66,14 @@
'#size-cells':
const: 0
+ ti,charge-pump-mode:
+ description:
+ Set the operating mode of the internal charge pump as defined in
+ <dt-bindings/leds/leds-lp55xx.h>.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 3 # auto
+ maximum: 3
+
patternProperties:
'^multi-led@[0-8]$':
type: object
@@ -152,6 +160,7 @@
examples:
- |
#include <dt-bindings/leds/common.h>
+ #include <dt-bindings/leds/leds-lp55xx.h>
i2c {
#address-cells = <1>;
@@ -164,6 +173,7 @@
reg = <0x32>;
clock-mode = /bits/ 8 <2>;
pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
+ ti,charge-pump-mode = <LP55XX_CP_BYPASS>;
led@0 {
reg = <0>;
diff --git a/Documentation/devicetree/bindings/leds/leds-mt6323.txt b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
index 7335369..052dccb8 100644
--- a/Documentation/devicetree/bindings/leds/leds-mt6323.txt
+++ b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
@@ -12,7 +12,10 @@
Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
Required properties:
-- compatible : Must be "mediatek,mt6323-led"
+- compatible : Must be one of
+ - "mediatek,mt6323-led"
+ - "mediatek,mt6331-led"
+ - "mediatek,mt6332-led"
- address-cells : Must be 1
- size-cells : Must be 0
diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
index 6295c91..e6f1999 100644
--- a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
@@ -16,18 +16,24 @@
properties:
compatible:
- enum:
- - qcom,pm660l-lpg
- - qcom,pm8150b-lpg
- - qcom,pm8150l-lpg
- - qcom,pm8350c-pwm
- - qcom,pm8916-pwm
- - qcom,pm8941-lpg
- - qcom,pm8994-lpg
- - qcom,pmc8180c-lpg
- - qcom,pmi8994-lpg
- - qcom,pmi8998-lpg
- - qcom,pmk8550-pwm
+ oneOf:
+ - enum:
+ - qcom,pm660l-lpg
+ - qcom,pm8150b-lpg
+ - qcom,pm8150l-lpg
+ - qcom,pm8350c-pwm
+ - qcom,pm8916-pwm
+ - qcom,pm8941-lpg
+ - qcom,pm8994-lpg
+ - qcom,pmc8180c-lpg
+ - qcom,pmi632-lpg
+ - qcom,pmi8994-lpg
+ - qcom,pmi8998-lpg
+ - qcom,pmk8550-pwm
+ - items:
+ - enum:
+ - qcom,pm8550-pwm
+ - const: qcom,pm8350c-pwm
"#pwm-cells":
const: 2
diff --git a/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml b/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml
index 4d2ffe5..37d2a93 100644
--- a/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml
@@ -20,6 +20,7 @@
compatible:
enum:
- ocs,ocp8110
+ - richtek,rt5033-led
- sgmicro,sgm3140
enable-gpios:
diff --git a/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml
index ffacf70..a8736fd 100644
--- a/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml
+++ b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml
@@ -26,6 +26,8 @@
- qcom,pm8150c-flash-led
- qcom,pm8150l-flash-led
- qcom,pm8350c-flash-led
+ - qcom,pm8550-flash-led
+ - qcom,pmi8998-flash-led
- const: qcom,spmi-flash-led
reg:
diff --git a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
index 64b0be9c..58f0d94 100644
--- a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
+++ b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
@@ -32,7 +32,7 @@
properties:
rohm,led-compatible:
description: LED identification string
- $ref: "/schemas/types.yaml#/definitions/string"
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- bd71828-ambled
- bd71828-grnled
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
deleted file mode 100644
index b48d7d3..0000000
--- a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Broadcom BCM2835 VideoCore mailbox IPC
-
-Required properties:
-
-- compatible: Should be "brcm,bcm2835-mbox"
-- reg: Specifies base physical address and size of the registers
-- interrupts: The interrupt number
- See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-- #mbox-cells: Specifies the number of cells needed to encode a mailbox
- channel. The value shall be 0, since there is only one
- mailbox channel implemented by the device.
-
-Example:
-
-mailbox: mailbox@7e00b880 {
- compatible = "brcm,bcm2835-mbox";
- reg = <0x7e00b880 0x40>;
- interrupts = <0 1>;
- #mbox-cells = <0>;
-};
-
-firmware: firmware {
- compatible = "raspberrypi,firmware";
- mboxes = <&mailbox>;
- #power-domain-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml
new file mode 100644
index 0000000..9588817
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/brcm,bcm2835-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 VideoCore mailbox IPC
+
+maintainers:
+ - Stefan Wahren <stefan.wahren@i2se.com>
+
+properties:
+ compatible:
+ const: brcm,bcm2835-mbox
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ mailbox@7e00b880 {
+ compatible = "brcm,bcm2835-mbox";
+ reg = <0x7e00b880 0x40>;
+ interrupts = <0 1>;
+ #mbox-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml
index a3e8751..2d14fc9 100644
--- a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml
+++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml
@@ -66,6 +66,7 @@
oneOf:
- const: nvidia,tegra186-hsp
- const: nvidia,tegra194-hsp
+ - const: nvidia,tegra264-hsp
- items:
- const: nvidia,tegra234-hsp
- const: nvidia,tegra194-hsp
diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
index 32d7bbc..d2e25ff 100644
--- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
+++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
@@ -18,6 +18,7 @@
oneOf:
- items:
- enum:
+ - qcom,ipq5018-apcs-apps-global
- qcom,ipq5332-apcs-apps-global
- qcom,ipq8074-apcs-apps-global
- qcom,ipq9574-apcs-apps-global
diff --git a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
index 374ffe6..aeaddbf 100644
--- a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
@@ -33,7 +33,7 @@
+------------------------------------------+
maintainers:
- - Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml
index 444f248..6c72e77 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml
@@ -65,9 +65,14 @@
properties:
data-lanes: true
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
required:
- data-lanes
+ - bus-type
required:
- port@4
@@ -82,6 +87,7 @@
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
i2c@e6508000 {
#address-cells = <1>;
@@ -101,6 +107,7 @@
port@4 {
reg = <4>;
max96712_out0: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
clock-lanes = <0>;
data-lanes = <1 2 3 4>;
remote-endpoint = <&csi40_in>;
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
index eb14999..9cc0a96 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
@@ -155,7 +155,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8916.h>
- camss: camss@1b00000 {
+ camss: camss@1b0ac00 {
compatible = "qcom,msm8916-camss";
clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml
index 8a10aa1..5cb0e33 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml
@@ -221,7 +221,7 @@
#include <dt-bindings/clock/qcom,gcc-msm8996.h>
#include <dt-bindings/clock/qcom,mmcc-msm8996.h>
- camss: camss@a00000 {
+ camss: camss@a34000 {
compatible = "qcom,msm8996-camss";
clocks = <&mmcc CAMSS_TOP_AHB_CLK>,
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml
index 0a109e1..584106e 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml
@@ -227,7 +227,7 @@
#include <dt-bindings/clock/qcom,gcc-sdm660.h>
#include <dt-bindings/clock/qcom,mmcc-sdm660.h>
- camss: camss@ca00000 {
+ camss: camss@ca00020 {
compatible = "qcom,sdm660-camss";
clocks = <&mmcc CAMSS_AHB_CLK>,
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml
index 1530ad0..ec4380a0a 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml
@@ -219,7 +219,7 @@
#address-cells = <2>;
#size-cells = <2>;
- camss: camss@a00000 {
+ camss: camss@acb3000 {
compatible = "qcom,sdm845-camss";
clocks = <&clock_camcc CAM_CC_CAMNOC_AXI_CLK>,
diff --git a/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml b/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml
index 7dde796..1e72b88 100644
--- a/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml
@@ -137,7 +137,7 @@
cru_parallel_in: endpoint@0 {
reg = <0>;
- remote-endpoint= <&ov5642>;
+ remote-endpoint = <&ov5642>;
hsync-active = <1>;
vsync-active = <1>;
};
@@ -150,7 +150,7 @@
cru_csi_in: endpoint@0 {
reg = <0>;
- remote-endpoint= <&csi_cru_in>;
+ remote-endpoint = <&csi_cru_in>;
};
};
};
diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml
index 91e8f36..324703b 100644
--- a/Documentation/devicetree/bindings/media/renesas,vin.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml
@@ -303,11 +303,11 @@
vin0csi20: endpoint@0 {
reg = <0>;
- remote-endpoint= <&csi20vin0>;
+ remote-endpoint = <&csi20vin0>;
};
vin0csi40: endpoint@2 {
reg = <2>;
- remote-endpoint= <&csi40vin0>;
+ remote-endpoint = <&csi40vin0>;
};
};
};
diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.yaml b/Documentation/devicetree/bindings/media/rockchip-rga.yaml
index dd645dd..ea23422 100644
--- a/Documentation/devicetree/bindings/media/rockchip-rga.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-rga.yaml
@@ -21,7 +21,9 @@
- const: rockchip,rk3288-rga
- const: rockchip,rk3399-rga
- items:
- - const: rockchip,rk3228-rga
+ - enum:
+ - rockchip,rk3228-rga
+ - rockchip,rk3568-rga
- const: rockchip,rk3288-rga
reg:
diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
index ee622a8..772ec32 100644
--- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
@@ -24,6 +24,7 @@
- rockchip,rk3399-vpu
- rockchip,px30-vpu
- rockchip,rk3568-vpu
+ - rockchip,rk3588-av1-vpu
- items:
- const: rockchip,rk3188-vpu
- const: rockchip,rk3066-vpu
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 8eb90c0..e69de29 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -1,78 +0,0 @@
-* Samsung Multi Format Codec (MFC)
-
-Multi Format Codec (MFC) is the IP present in Samsung SoCs which
-supports high resolution decoding and encoding functionalities.
-The MFC device driver is a v4l2 driver which can encode/decode
-video raw/elementary streams and has support for all popular
-video codecs.
-
-Required properties:
- - compatible : value should be either one among the following
- (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
- (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
- (c) "samsung,exynos3250-mfc", "samsung,mfc-v7" for MFC v7
- present in Exynos3250 SoC
- (d) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
- (e) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
- (f) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
- (g) "samsung,mfc-v10" for MFC v10 present in Exynos7880 SoC
-
- - reg : Physical base address of the IP registers and length of memory
- mapped region.
-
- - interrupts : MFC interrupt number to the CPU.
- - clocks : from common clock binding: handle to mfc clock.
- - clock-names : from common clock binding: must contain "mfc",
- corresponding to entry in the clocks property.
-
-Optional properties:
- - power-domains : power-domain property defined with a phandle
- to respective power domain.
- - memory-region : from reserved memory binding: phandles to two reserved
- memory regions, first is for "left" mfc memory bus interfaces,
- second if for the "right" mfc memory bus, used when no SYSMMU
- support is available; used only by MFC v5 present in Exynos4 SoCs
-
-Obsolete properties:
- - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
- property instead
-
-
-Example:
-SoC specific DT entry:
-
-mfc: codec@13400000 {
- compatible = "samsung,mfc-v5";
- reg = <0x13400000 0x10000>;
- interrupts = <0 94 0>;
- power-domains = <&pd_mfc>;
- clocks = <&clock 273>;
- clock-names = "mfc";
-};
-
-Reserved memory specific DT entry for given board (see reserved memory binding
-for more information):
-
-reserved-memory {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- mfc_left: region@51000000 {
- compatible = "shared-dma-pool";
- no-map;
- reg = <0x51000000 0x800000>;
- };
-
- mfc_right: region@43000000 {
- compatible = "shared-dma-pool";
- no-map;
- reg = <0x43000000 0x800000>;
- };
-};
-
-Board specific DT entry:
-
-codec@13400000 {
- memory-region = <&mfc_left>, <&mfc_right>;
-};
diff --git a/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
new file mode 100644
index 0000000..084b445
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/samsung,s5p-mfc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos Multi Format Codec (MFC)
+
+maintainers:
+ - Marek Szyprowski <m.szyprowski@samsung.com>
+ - Aakarsh Jain <aakarsh.jain@samsung.com>
+
+description:
+ Multi Format Codec (MFC) is the IP present in Samsung SoCs which
+ supports high resolution decoding and encoding functionalities.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - samsung,exynos5433-mfc # Exynos5433
+ - samsung,mfc-v5 # Exynos4
+ - samsung,mfc-v6 # Exynos5
+ - samsung,mfc-v7 # Exynos5420
+ - samsung,mfc-v8 # Exynos5800
+ - samsung,mfc-v10 # Exynos7880
+ - items:
+ - enum:
+ - samsung,exynos3250-mfc # Exynos3250
+ - const: samsung,mfc-v7 # Fall back for Exynos3250
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+ iommu-names:
+ minItems: 1
+ maxItems: 2
+
+ power-domains:
+ maxItems: 1
+
+ memory-region:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos3250-mfc
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ items:
+ - const: mfc
+ - const: sclk_mfc
+ iommus:
+ maxItems: 1
+ iommus-names: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos5433-mfc
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: pclk
+ - const: aclk
+ - const: aclk_xiu
+ iommus:
+ maxItems: 2
+ iommus-names:
+ items:
+ - const: left
+ - const: right
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,mfc-v5
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ items:
+ - const: mfc
+ - const: sclk_mfc
+ iommus:
+ maxItems: 2
+ iommus-names:
+ items:
+ - const: left
+ - const: right
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,mfc-v6
+ - samsung,mfc-v8
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: mfc
+ iommus:
+ maxItems: 2
+ iommus-names:
+ items:
+ - const: left
+ - const: right
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,mfc-v7
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 2
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos4.h>
+ #include <dt-bindings/clock/exynos-audss-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ codec@13400000 {
+ compatible = "samsung,mfc-v5";
+ reg = <0x13400000 0x10000>;
+ interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&pd_mfc>;
+ clocks = <&clock CLK_MFC>, <&clock CLK_SCLK_MFC>;
+ clock-names = "mfc", "sclk_mfc";
+ iommus = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
+ iommu-names = "left", "right";
+ };
diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
index 7d77823d..43daf83 100644
--- a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
@@ -7,7 +7,7 @@
title: Xilinx MIPI CSI-2 Receiver Subsystem
maintainers:
- - Vishal Sagar <vishal.sagar@xilinx.com>
+ - Vishal Sagar <vishal.sagar@amd.com>
description: |
The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture MIPI CSI-2
diff --git a/Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml
new file mode 100644
index 0000000..ac1a5a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/nuvoton,npcm-memory-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM Memory Controller
+
+maintainers:
+ - Marvin Lin <kflin@nuvoton.com>
+ - Stanley Chu <yschu@nuvoton.com>
+
+description: |
+ The Nuvoton BMC SoC supports DDR4 memory with or without ECC (error correction
+ check).
+
+ The memory controller supports single bit error correction, double bit error
+ detection (in-line ECC in which a section (1/8th) of the memory device used to
+ store data is used for ECC storage).
+
+ Note, the bootloader must configure ECC mode for the memory controller.
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,npcm750-memory-controller
+ - nuvoton,npcm845-memory-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mc: memory-controller@f0824000 {
+ compatible = "nuvoton,npcm750-memory-controller";
+ reg = <0xf0824000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
index 2fa4495..f54e553 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
@@ -165,7 +165,7 @@
const: 0
lpddr2:
- $ref: "ddr/jedec,lpddr2.yaml#"
+ $ref: ddr/jedec,lpddr2.yaml#
type: object
patternProperties:
diff --git a/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml b/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml
index e68c430..87ff9ee 100644
--- a/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml
@@ -8,8 +8,7 @@
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- - Manish Narani <manish.narani@xilinx.com>
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
description: |
Synopsys DesignWare Enhanced uMCTL2 DDR Memory Controller is capable of
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
index bc94069..b049837 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
@@ -129,7 +129,7 @@
The child device node represents the device connected to the GPMC
bus. The device can be a NAND chip, SRAM device, NOR device
or an ASIC.
- $ref: "ti,gpmc-child.yaml"
+ $ref: ti,gpmc-child.yaml
required:
diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
index 8f72e2f..75143db 100644
--- a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
@@ -8,8 +8,7 @@
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- - Manish Narani <manish.narani@xilinx.com>
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
description:
The Zynq DDR ECC controller has an optional ECC support in half-bus width
diff --git a/Documentation/devicetree/bindings/mfd/adi,max77541.yaml b/Documentation/devicetree/bindings/mfd/adi,max77541.yaml
new file mode 100644
index 0000000..c7895b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/adi,max77541.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/adi,max77541.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX77540/MAX77541 PMIC from ADI
+
+maintainers:
+ - Okan Sahin <okan.sahin@analog.com>
+
+description: |
+ MAX77540 is a Power Management IC with 2 buck regulators.
+
+ MAX77541 is a Power Management IC with 2 buck regulators and 1 ADC.
+
+properties:
+ compatible:
+ enum:
+ - adi,max77540
+ - adi,max77541
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ $ref: /schemas/regulator/adi,max77541-regulator.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@69 {
+ compatible = "adi,max77541";
+ reg = <0x69>;
+ interrupt-parent = <&gpio>;
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+
+ regulators {
+ buck1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <5200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ buck2 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <5200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
index 148f1da..9f9a14a 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
@@ -35,11 +35,11 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
index 7e58224..803277d 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
@@ -35,11 +35,11 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
index 2230848..b9a6856 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
@@ -35,11 +35,11 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
index c06693b..4651fe4d 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
@@ -35,11 +35,11 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
index c560bed..0330b62 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
@@ -35,11 +35,11 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
index c534f5f..82d3e44 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
@@ -35,11 +35,11 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
index acb9c54..dc379f3 100644
--- a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
+++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
@@ -122,12 +122,6 @@
compatible:
const: gw,gsc-fan
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
reg:
description: The fan controller base address
maxItems: 1
@@ -135,8 +129,6 @@
required:
- compatible
- reg
- - "#address-cells"
- - "#size-cells"
required:
- compatible
@@ -194,8 +186,6 @@
};
fan-controller@2c {
- #address-cells = <1>;
- #size-cells = <0>;
compatible = "gw,gsc-fan";
reg = <0x2c>;
};
diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
index 36de335..8b9a200 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
@@ -71,6 +71,7 @@
- qcom,pm8998
- qcom,pma8084
- qcom,pmd9635
+ - qcom,pmi632
- qcom,pmi8950
- qcom,pmi8962
- qcom,pmi8994
@@ -133,6 +134,7 @@
oneOf:
- $ref: /schemas/power/supply/qcom,pm8941-charger.yaml#
- $ref: /schemas/power/supply/qcom,pm8941-coincell.yaml#
+ - $ref: /schemas/power/supply/qcom,pmi8998-charger.yaml#
"gpio@[0-9a-f]+$":
type: object
@@ -146,6 +148,10 @@
type: object
$ref: /schemas/nvmem/qcom,spmi-sdam.yaml#
+ "phy@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/phy/qcom,snps-eusb2-repeater.yaml#
+
"pon@[0-9a-f]+$":
type: object
$ref: /schemas/power/reset/qcom,pon.yaml#
diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
index fe790af..5ad9d5d 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
@@ -34,6 +34,7 @@
- qcom,tcsr-ipq5332
- qcom,tcsr-ipq6018
- qcom,tcsr-ipq8064
+ - qcom,tcsr-ipq8074
- qcom,tcsr-ipq9574
- qcom,tcsr-mdm9615
- qcom,tcsr-msm8226
diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
new file mode 100644
index 0000000..386b1a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/richtek,rt5033.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT5033 Power Management Integrated Circuit
+
+maintainers:
+ - Jakob Hauser <jahau@rocketmail.com>
+
+description:
+ RT5033 is a multifunction device which includes battery charger, fuel gauge,
+ flash LED current source, LDO and synchronous Buck converter for portable
+ applications. It is interfaced to host controller using I2C interface. The
+ battery fuel gauge uses a separate I2C bus.
+
+properties:
+ compatible:
+ const: richtek,rt5033
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ description:
+ The regulators of RT5033 have to be instantiated under a sub-node named
+ "regulators". For SAFE_LDO voltage there is only one value of 4.9 V. LDO
+ voltage ranges from 1.2 V to 3.0 V in 0.1 V steps. BUCK voltage ranges
+ from 1.0 V to 3.0 V in 0.1 V steps.
+ type: object
+ patternProperties:
+ "^(SAFE_LDO|LDO|BUCK)$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+ additionalProperties: false
+
+ charger:
+ type: object
+ $ref: /schemas/power/supply/richtek,rt5033-charger.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ battery: battery {
+ compatible = "simple-battery";
+ precharge-current-microamp = <450000>;
+ constant-charge-current-max-microamp = <1000000>;
+ charge-term-current-microamp = <150000>;
+ precharge-upper-limit-microvolt = <3500000>;
+ constant-charge-voltage-max-microvolt = <4350000>;
+ };
+
+ extcon {
+ usb_con: connector {
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ fuel-gauge@35 {
+ compatible = "richtek,rt5033-battery";
+ reg = <0x35>;
+
+ interrupt-parent = <&msmgpio>;
+ interrupts = <121 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&fg_alert_default>;
+
+ power-supplies = <&rt5033_charger>;
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ pmic@34 {
+ compatible = "richtek,rt5033";
+ reg = <0x34>;
+
+ interrupt-parent = <&msmgpio>;
+ interrupts = <62 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_default>;
+
+ regulators {
+ safe_ldo_reg: SAFE_LDO {
+ regulator-name = "SAFE_LDO";
+ regulator-min-microvolt = <4900000>;
+ regulator-max-microvolt = <4900000>;
+ regulator-always-on;
+ };
+ ldo_reg: LDO {
+ regulator-name = "LDO";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+ buck_reg: BUCK {
+ regulator-name = "BUCK";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ };
+
+ rt5033_charger: charger {
+ compatible = "richtek,rt5033-charger";
+ monitored-battery = <&battery>;
+ richtek,usb-connector = <&usb_con>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml
new file mode 100644
index 0000000..cf2500f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml
@@ -0,0 +1,406 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rockchip,rk806.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RK806 Power Management Integrated Circuit
+
+maintainers:
+ - Sebastian Reichel <sebastian.reichel@collabora.com>
+
+description:
+ Rockchip RK806 series PMIC. This device consists of an spi or
+ i2c controlled MFD that includes multiple switchable regulators.
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk806
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ vcc1-supply:
+ description:
+ The input supply for dcdc-reg1.
+
+ vcc2-supply:
+ description:
+ The input supply for dcdc-reg2.
+
+ vcc3-supply:
+ description:
+ The input supply for dcdc-reg3.
+
+ vcc4-supply:
+ description:
+ The input supply for dcdc-reg4.
+
+ vcc5-supply:
+ description:
+ The input supply for dcdc-reg5.
+
+ vcc6-supply:
+ description:
+ The input supply for dcdc-reg6.
+
+ vcc7-supply:
+ description:
+ The input supply for dcdc-reg7.
+
+ vcc8-supply:
+ description:
+ The input supply for dcdc-reg8.
+
+ vcc9-supply:
+ description:
+ The input supply for dcdc-reg9.
+
+ vcc10-supply:
+ description:
+ The input supply for dcdc-reg10.
+
+ vcc11-supply:
+ description:
+ The input supply for pldo-reg1, pldo-reg2 and pldo-reg3.
+
+ vcc12-supply:
+ description:
+ The input supply for pldo-reg4 and pldo-reg5.
+
+ vcc13-supply:
+ description:
+ The input supply for nldo-reg1, nldo-reg2 and nldo-reg3.
+
+ vcc14-supply:
+ description:
+ The input supply for nldo-reg4 and nldo-reg5.
+
+ vcca-supply:
+ description:
+ The input supply for pldo-reg6.
+
+ regulators:
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "^(dcdc-reg([1-9]|10)|pldo-reg[1-6]|nldo-reg[1-5])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+
+ properties:
+ function:
+ enum: [pin_fun0, pin_fun1, pin_fun2, pin_fun3, pin_fun4, pin_fun5]
+
+ pins:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [gpio_pwrctrl1, gpio_pwrctrl2, gpio_pwrctrl3]
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/rockchip.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@0 {
+ compatible = "rockchip,rk806";
+ reg = <0x0>;
+
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc5v0_sys>;
+ vcc6-supply = <&vcc5v0_sys>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc5v0_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+ vcc10-supply = <&vcc5v0_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc5v0_sys>;
+ vcc13-supply = <&vcc5v0_sys>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc5v0_sys>;
+
+ regulators {
+ vdd_gpu_s0: dcdc-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_npu_s0: dcdc-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_npu_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_log_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_log_s0";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_vdenc_s0: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_vdenc_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu_mem_s0: dcdc-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_mem_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_npu_mem_s0: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_npu_mem_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_2v0_pldo_s3: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_2v0_pldo_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2000000>;
+ };
+ };
+
+ vdd_vdenc_mem_s0: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_vdenc_mem_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v1_nldo_s3: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1100000>;
+ };
+ };
+
+ avcc_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "avcc_1v8_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd1_1v8_ddr_s3: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd1_1v8_ddr_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_1v8_s3: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vcc_1v8_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vcc_3v3_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vccio_sd_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ master_pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "master_pldo6_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_0v75_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd2l_0v9_ddr_s3: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-name = "vdd2l_0v9_ddr_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ master_nldo3: nldo-reg3 {
+ regulator-name = "master_nldo3";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ avdd_0v75_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "avdd_0v75_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v85_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_0v85_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml
index 10c7b40..aea0b7d 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml
+++ b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml
@@ -153,29 +153,18 @@
additionalProperties: false
allOf:
- - if:
+ - not:
required:
- s5m8767,pmic-buck2-uses-gpio-dvs
- then:
- properties:
- s5m8767,pmic-buck3-uses-gpio-dvs: false
- s5m8767,pmic-buck4-uses-gpio-dvs: false
-
- - if:
+ - s5m8767,pmic-buck3-uses-gpio-dvs
+ - not:
+ required:
+ - s5m8767,pmic-buck2-uses-gpio-dvs
+ - s5m8767,pmic-buck4-uses-gpio-dvs
+ - not:
required:
- s5m8767,pmic-buck3-uses-gpio-dvs
- then:
- properties:
- s5m8767,pmic-buck2-uses-gpio-dvs: false
- s5m8767,pmic-buck4-uses-gpio-dvs: false
-
- - if:
- required:
- s5m8767,pmic-buck4-uses-gpio-dvs
- then:
- properties:
- s5m8767,pmic-buck2-uses-gpio-dvs: false
- s5m8767,pmic-buck3-uses-gpio-dvs: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
index 9573e4a..97c6109 100644
--- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
@@ -184,7 +184,7 @@
additionalProperties: false
patternProperties:
- "^(buck[1-4]|ldo[1-6]|boost|pwr_sw[1-2])-supply$":
+ "^(buck[1-4]|ldo[1-6]|vref_ddr|boost|pwr_sw[1-2])-supply$":
description: STPMIC1 voltage regulators supplies
"^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$":
diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
index 0c98d91..e6289fb 100644
--- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
@@ -101,7 +101,7 @@
};
clock-controller@4140 {
- compatible = "ti,am654-ehrpwm-tbclk", "syscon";
+ compatible = "ti,am654-ehrpwm-tbclk";
reg = <0x4140 0x18>;
#clock-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
new file mode 100644
index 0000000..9d43376
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,tps6594.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TPS6594 Power Management Integrated Circuit
+
+maintainers:
+ - Julien Panis <jpanis@baylibre.com>
+
+description:
+ TPS6594 is a Power Management IC which provides regulators and others
+ features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
+ PFSM (Pre-configurable Finite State Machine) managing the state of the device.
+ TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives.
+
+properties:
+ compatible:
+ enum:
+ - ti,lp8764-q1
+ - ti,tps6593-q1
+ - ti,tps6594-q1
+
+ reg:
+ description: I2C slave address or SPI chip select number.
+ maxItems: 1
+
+ ti,primary-pmic:
+ type: boolean
+ description: |
+ Identify the primary PMIC on SPMI bus.
+ A multi-PMIC synchronization scheme is implemented in the PMIC device
+ to synchronize the power state changes with other PMIC devices. This is
+ accomplished through a SPMI bus: the primary PMIC is the controller
+ device on the SPMI bus, and the secondary PMICs are the target devices
+ on the SPMI bus.
+
+ system-power-controller: true
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+ description: |
+ The first cell is the pin number, the second cell is used to specify flags.
+ See ../gpio/gpio.txt for more information.
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: List of regulators provided by this controller.
+
+ patternProperties:
+ "^buck([1-5]|12|34|123|1234)$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+
+ unevaluatedProperties: false
+
+ "^ldo[1-4]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+
+ unevaluatedProperties: false
+
+ allOf:
+ - if:
+ required:
+ - buck12
+ then:
+ properties:
+ buck123: false
+ buck1234: false
+ - if:
+ required:
+ - buck123
+ then:
+ properties:
+ buck34: false
+ - if:
+ required:
+ - buck1234
+ then:
+ properties:
+ buck34: false
+
+ additionalProperties: false
+
+patternProperties:
+ "^buck([1-5]|12|34|123|1234)-supply$":
+ description: Input supply phandle for each buck.
+
+ "^ldo[1-4]-supply$":
+ description: Input supply phandle for each ldo.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tps6593: pmic@48 {
+ compatible = "ti,tps6593-q1";
+ reg = <0x48>;
+ ti,primary-pmic;
+ system-power-controller;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq_pins_default>;
+ interrupt-parent = <&mcu_gpio0>;
+ interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+
+ buck123-supply = <&vcc_3v3_sys>;
+ buck4-supply = <&vcc_3v3_sys>;
+ buck5-supply = <&vcc_3v3_sys>;
+ ldo1-supply = <&vcc_3v3_sys>;
+ ldo2-supply = <&vcc_3v3_sys>;
+ ldo3-supply = <&buck5>;
+ ldo4-supply = <&vcc_3v3_sys>;
+
+ regulators {
+ buck123: buck123 {
+ regulator-name = "vcc_core";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <850000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck4: buck4 {
+ regulator-name = "vcc_1v1";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: buck5 {
+ regulator-name = "vcc_1v8_sys";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: ldo1 {
+ regulator-name = "vddshv5_sdio";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2: ldo2 {
+ regulator-name = "vpp_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3: ldo3 {
+ regulator-name = "vcc_0v85";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4: ldo4 {
+ regulator-name = "vdda_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
index f7f0f2c..9ad5574 100644
--- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
+++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
@@ -90,6 +90,7 @@
oneOf:
- enum:
- x-powers,axp152
+ - x-powers,axp192
- x-powers,axp202
- x-powers,axp209
- x-powers,axp221
diff --git a/Documentation/devicetree/bindings/mips/ralink.yaml b/Documentation/devicetree/bindings/mips/ralink.yaml
index 704b5b5..53c1f66 100644
--- a/Documentation/devicetree/bindings/mips/ralink.yaml
+++ b/Documentation/devicetree/bindings/mips/ralink.yaml
@@ -80,6 +80,7 @@
- enum:
- gnubee,gb-pc1
- gnubee,gb-pc2
+ - tplink,hc220-g5-v1
- const: mediatek,mt7621-soc
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/misc/brcm,kona-smc.txt b/Documentation/devicetree/bindings/misc/brcm,kona-smc.txt
deleted file mode 100644
index 05b4723..0000000
--- a/Documentation/devicetree/bindings/misc/brcm,kona-smc.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Broadcom Secure Monitor Bounce buffer
------------------------------------------------------
-This binding defines the location of the bounce buffer
-used for non-secure to secure communications.
-
-Required properties:
-- compatible : "brcm,kona-smc"
-- DEPRECATED: compatible : "bcm,kona-smc"
-- reg : Location and size of bounce buffer
-
-Example:
- smc@3404c000 {
- compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
- reg = <0x3404c000 0x400>; //1 KiB in SRAM
- };
diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
index 1ab9588..2dc3e24 100644
--- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
+++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
@@ -36,7 +36,7 @@
description:
A list of channels tied to this function, used for matching
the function to a set of virtual channels.
- $ref: "/schemas/types.yaml#/definitions/string-array"
+ $ref: /schemas/types.yaml#/definitions/string-array
items:
- const: fastrpcglink-apps-dsp
@@ -48,14 +48,14 @@
qcom,smd-channels:
description:
Channel name used for the RPM communication
- $ref: "/schemas/types.yaml#/definitions/string-array"
+ $ref: /schemas/types.yaml#/definitions/string-array
items:
- const: fastrpcsmd-apps-dsp
qcom,vmids:
description:
Virtual machine IDs for remote processor.
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
"#address-cells":
const: 1
diff --git a/Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml b/Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml
new file mode 100644
index 0000000..0c9a844
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/ti,j721e-esm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 ESM
+
+maintainers:
+ - Neha Malcom Francis <n-francis@ti.com>
+
+description:
+ The ESM (Error Signaling Module) is an IP block on TI K3 devices
+ that allows handling of safety events somewhat similar to what interrupt
+ controller would do. The safety signals have their separate paths within
+ the SoC, and they are handled by the ESM, which routes them to the proper
+ destination, which can be system reset, interrupt controller, etc. In the
+ simplest configuration the signals are just routed to reset the SoC.
+
+properties:
+ compatible:
+ const: ti,j721e-esm
+
+ reg:
+ maxItems: 1
+
+ ti,esm-pins:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ integer array of ESM interrupt pins to route to external event pin
+ which can be used to reset the SoC.
+ minItems: 1
+ maxItems: 255
+
+required:
+ - compatible
+ - reg
+ - ti,esm-pins
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ esm@700000 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x700000 0x0 0x1000>;
+ ti,esm-pins = <344>, <345>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
index 1c96da04..2459a55 100644
--- a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
+++ b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
@@ -53,10 +53,11 @@
items:
- const: arm,pl18x
- const: arm,primecell
- - description: Entry for STMicroelectronics variant of PL18x.
- This dedicated compatible is used by bootloaders.
+ - description: Entries for STMicroelectronics variant of PL18x.
items:
- - const: st,stm32-sdmmc2
+ - enum:
+ - st,stm32-sdmmc2
+ - st,stm32mp25-sdmmc2
- const: arm,pl18x
- const: arm,primecell
diff --git a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt
deleted file mode 100644
index d876580..0000000
--- a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Broadcom BCM2835 SDHOST controller
-
-This file documents differences between the core properties described
-by mmc.txt and the properties that represent the BCM2835 controller.
-
-Required properties:
-- compatible: Should be "brcm,bcm2835-sdhost".
-- clocks: The clock feeding the SDHOST controller.
-
-Optional properties:
-- dmas: DMA channel for read and write.
- See Documentation/devicetree/bindings/dma/dma.txt for details
-
-Example:
-
-sdhost: mmc@7e202000 {
- compatible = "brcm,bcm2835-sdhost";
- reg = <0x7e202000 0x100>;
- interrupts = <2 24>;
- clocks = <&clocks BCM2835_CLOCK_VPU>;
- dmas = <&dma 13>;
- dma-names = "rx-tx";
-};
diff --git a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml
new file mode 100644
index 0000000..3a5a448
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/brcm,bcm2835-sdhost.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 SDHOST controller
+
+maintainers:
+ - Stefan Wahren <stefan.wahren@i2se.com>
+
+allOf:
+ - $ref: mmc-controller.yaml
+
+properties:
+ compatible:
+ const: brcm,bcm2835-sdhost
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+
+ sdhost: mmc@7e202000 {
+ compatible = "brcm,bcm2835-sdhost";
+ reg = <0x7e202000 0x100>;
+ interrupts = <2 24>;
+ clocks = <&clocks BCM2835_CLOCK_VPU>;
+ dmas = <&dma 13>;
+ dma-names = "rx-tx";
+ bus-width = <4>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt
deleted file mode 100644
index 7f5dd83..0000000
--- a/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Broadcom BCM281xx SDHCI
-
-This file documents differences between the core properties in mmc.txt
-and the properties present in the bcm281xx SDHCI
-
-Required properties:
-- compatible : Should be "brcm,kona-sdhci"
-- DEPRECATED: compatible : Should be "bcm,kona-sdhci"
-- clocks: phandle + clock specifier pair of the external clock
-
-Refer to clocks/clock-bindings.txt for generic clock consumer properties.
-
-Example:
-
-sdio2: sdio@3f1a0000 {
- compatible = "brcm,kona-sdhci";
- reg = <0x3f1a0000 0x10000>;
- clocks = <&sdio3_clk>;
- interrupts = <0x0 74 0x4>;
-};
-
diff --git a/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.yaml b/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.yaml
new file mode 100644
index 0000000..12eb398
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/brcm,kona-sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family SDHCI controller
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+allOf:
+ - $ref: sdhci-common.yaml#
+
+properties:
+ compatible:
+ const: brcm,kona-sdhci
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/bcm281xx.h>
+
+ mmc@3f1a0000 {
+ compatible = "brcm,kona-sdhci";
+ reg = <0x3f1a0000 0x10000>;
+ clocks = <&master_ccu BCM281XX_MASTER_CCU_SDIO3>;
+ interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
index fbfd822..82eb7a2 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -42,6 +42,7 @@
- enum:
- fsl,imx6sll-usdhc
- fsl,imx6ull-usdhc
+ - fsl,imx6ul-usdhc
- const: fsl,imx6sx-usdhc
- items:
- const: fsl,imx7d-usdhc
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
index 4f2d9e8..6da28e6 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
@@ -36,11 +36,14 @@
- enum:
- qcom,ipq5018-sdhci
- qcom,ipq5332-sdhci
+ - qcom,ipq6018-sdhci
- qcom,ipq9574-sdhci
- qcom,qcm2290-sdhci
- qcom,qcs404-sdhci
+ - qcom,qdu1000-sdhci
- qcom,sc7180-sdhci
- qcom,sc7280-sdhci
+ - qcom,sc8280xp-sdhci
- qcom,sdm630-sdhci
- qcom,sdm670-sdhci
- qcom,sdm845-sdhci
diff --git a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml
index 9a88870..054b6b8 100644
--- a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml
@@ -49,13 +49,12 @@
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
reg:
minimum: 0
maximum: 7
- nand-ecc-mode: true
-
nand-ecc-algo:
const: bch
@@ -75,7 +74,7 @@
minimum: 0
maximum: 1
- additionalProperties: false
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
index 28fb9a7..787ef48 100644
--- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
@@ -40,6 +40,7 @@
patternProperties:
"^nand@[0-7]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
reg:
minimum: 0
@@ -58,6 +59,14 @@
meson-gxl-nfc 8, 16, 24, 30, 40, 50, 60
meson-axg-nfc 8
+ nand-rb:
+ maxItems: 1
+ items:
+ maximum: 0
+
+ unevaluatedProperties: false
+
+
required:
- compatible
- reg
@@ -87,6 +96,7 @@
nand@0 {
reg = <0>;
+ nand-rb = <0>;
};
};
diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
index 1571024..f57e963 100644
--- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
+++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
@@ -114,6 +114,7 @@
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
compatible:
const: brcm,nandcs
@@ -136,6 +137,8 @@
layout.
$ref: /schemas/types.yaml#/definitions/uint32
+ unevaluatedProperties: false
+
allOf:
- $ref: nand-controller.yaml#
- if:
diff --git a/Documentation/devicetree/bindings/mtd/denali,nand.yaml b/Documentation/devicetree/bindings/mtd/denali,nand.yaml
index 0be83ad..81f9553 100644
--- a/Documentation/devicetree/bindings/mtd/denali,nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/denali,nand.yaml
@@ -63,6 +63,12 @@
minItems: 1
maxItems: 2
+patternProperties:
+ "^nand@[a-f0-9]$":
+ type: object
+ $ref: raw-nand-chip.yaml
+ unevaluatedProperties: false
+
allOf:
- $ref: nand-controller.yaml
@@ -74,7 +80,6 @@
then:
patternProperties:
"^nand@[a-f0-9]$":
- type: object
properties:
nand-ecc-strength:
enum:
@@ -92,7 +97,6 @@
then:
patternProperties:
"^nand@[a-f0-9]$":
- type: object
properties:
nand-ecc-strength:
enum:
@@ -111,7 +115,6 @@
then:
patternProperties:
"^nand@[a-f0-9]$":
- type: object
properties:
nand-ecc-strength:
enum:
diff --git a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
index a7bdb5d..b9312eb 100644
--- a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
@@ -39,7 +39,9 @@
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
+
rb-gpios:
description: GPIO specifier for the busy pin.
maxItems: 1
@@ -48,6 +50,8 @@
description: GPIO specifier for the write-protect pin.
maxItems: 1
+ unevaluatedProperties: false
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml
index cc3def7..07bc7e3 100644
--- a/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml
@@ -42,17 +42,16 @@
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
reg:
minimum: 0
maximum: 1
- nand-ecc-mode: true
-
nand-ecc-algo:
const: hw
- additionalProperties: false
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml
new file mode 100644
index 0000000..a10729b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml
@@ -0,0 +1,226 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/marvell,nand-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell NAND Flash Controller (NFC)
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: marvell,armada-8k-nand-controller
+ - const: marvell,armada370-nand-controller
+ - enum:
+ - marvell,armada370-nand-controller
+ - marvell,pxa3xx-nand-controller
+ - description: legacy bindings
+ deprecated: true
+ enum:
+ - marvell,armada-8k-nand
+ - marvell,armada370-nand
+ - marvell,pxa3xx-nand
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description:
+ Shall reference the NAND controller clocks, the second one is
+ is only needed for the Armada 7K/8K SoCs
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: reg
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ items:
+ - const: data
+
+ marvell,system-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Syscon node that handles NAND controller related registers
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+ type: object
+ $ref: raw-nand-chip.yaml
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 3
+
+ nand-rb:
+ items:
+ - minimum: 0
+ maximum: 1
+
+ nand-ecc-step-size:
+ const: 512
+
+ nand-ecc-strength:
+ enum: [1, 4, 8, 12, 16]
+
+ nand-ecc-mode:
+ const: hw
+
+ marvell,nand-keep-config:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Orders the driver not to take the timings from the core and
+ leaving them completely untouched. Bootloader timings will then
+ be used.
+
+ marvell,nand-enable-arbiter:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ To enable the arbiter, all boards blindly used it,
+ this bit was set by the bootloader for many boards and even if
+ it is marked reserved in several datasheets, it might be needed to set
+ it (otherwise it is harmless).
+ deprecated: true
+
+ required:
+ - reg
+ - nand-rb
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+allOf:
+ - $ref: nand-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: marvell,pxa3xx-nand-controller
+ then:
+ required:
+ - dmas
+ - dma-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: marvell,armada-8k-nand-controller
+ then:
+ properties:
+ clocks:
+ minItems: 2
+
+ clock-names:
+ minItems: 2
+
+ required:
+ - marvell,system-controller
+
+ else:
+ properties:
+ clocks:
+ minItems: 1
+
+ clock-names:
+ minItems: 1
+
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ nand_controller: nand-controller@d0000 {
+ compatible = "marvell,armada370-nand-controller";
+ reg = <0xd0000 0x54>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&coredivclk 0>;
+
+ nand@0 {
+ reg = <0>;
+ label = "main-storage";
+ nand-rb = <0>;
+ nand-ecc-mode = "hw";
+ marvell,nand-keep-config;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "Rootfs";
+ reg = <0x00000000 0x40000000>;
+ };
+ };
+ };
+ };
+
+ - |
+ cp0_nand_controller: nand-controller@720000 {
+ compatible = "marvell,armada-8k-nand-controller",
+ "marvell,armada370-nand-controller";
+ reg = <0x720000 0x54>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <115 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "core", "reg";
+ clocks = <&cp0_clk 1 2>,
+ <&cp0_clk 1 17>;
+ marvell,system-controller = <&cp0_syscon0>;
+
+ nand@0 {
+ reg = <0>;
+ label = "main-storage";
+ nand-rb = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ };
+ };
+
+ - |
+ nand-controller@43100000 {
+ compatible = "marvell,pxa3xx-nand-controller";
+ reg = <0x43100000 90>;
+ interrupts = <45>;
+ clocks = <&clks 1>;
+ clock-names = "core";
+ dmas = <&pdma 97 3>;
+ dma-names = "data";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ nand@0 {
+ reg = <0>;
+ nand-rb = <0>;
+ nand-ecc-mode = "hw";
+ marvell,nand-keep-config;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mtd/marvell-nand.txt b/Documentation/devicetree/bindings/mtd/marvell-nand.txt
deleted file mode 100644
index a2d9a0f..0000000
--- a/Documentation/devicetree/bindings/mtd/marvell-nand.txt
+++ /dev/null
@@ -1,126 +0,0 @@
-Marvell NAND Flash Controller (NFC)
-
-Required properties:
-- compatible: can be one of the following:
- * "marvell,armada-8k-nand-controller"
- * "marvell,armada370-nand-controller"
- * "marvell,pxa3xx-nand-controller"
- * "marvell,armada-8k-nand" (deprecated)
- * "marvell,armada370-nand" (deprecated)
- * "marvell,pxa3xx-nand" (deprecated)
- Compatibles marked deprecated support only the old bindings described
- at the bottom.
-- reg: NAND flash controller memory area.
-- #address-cells: shall be set to 1. Encode the NAND CS.
-- #size-cells: shall be set to 0.
-- interrupts: shall define the NAND controller interrupt.
-- clocks: shall reference the NAND controller clocks, the second one is
- is only needed for the Armada 7K/8K SoCs
-- clock-names: mandatory if there is a second clock, in this case there
- should be one clock named "core" and another one named "reg"
-- marvell,system-controller: Set to retrieve the syscon node that handles
- NAND controller related registers (only required with the
- "marvell,armada-8k-nand[-controller]" compatibles).
-
-Optional properties:
-- label: see partition.txt. New platforms shall omit this property.
-- dmas: shall reference DMA channel associated to the NAND controller.
- This property is only used with "marvell,pxa3xx-nand[-controller]"
- compatible strings.
-- dma-names: shall be "rxtx".
- This property is only used with "marvell,pxa3xx-nand[-controller]"
- compatible strings.
-
-Optional children nodes:
-Children nodes represent the available NAND chips.
-
-Required properties:
-- reg: shall contain the native Chip Select ids (0-3).
-- nand-rb: see nand-controller.yaml (0-1).
-
-Optional properties:
-- marvell,nand-keep-config: orders the driver not to take the timings
- from the core and leaving them completely untouched. Bootloader
- timings will then be used.
-- label: MTD name.
-- nand-on-flash-bbt: see nand-controller.yaml.
-- nand-ecc-mode: see nand-controller.yaml. Will use hardware ECC if not specified.
-- nand-ecc-algo: see nand-controller.yaml. This property is essentially useful when
- not using hardware ECC. Howerver, it may be added when using hardware
- ECC for clarification but will be ignored by the driver because ECC
- mode is chosen depending on the page size and the strength required by
- the NAND chip. This value may be overwritten with nand-ecc-strength
- property.
-- nand-ecc-strength: see nand-controller.yaml.
-- nand-ecc-step-size: see nand-controller.yaml. Marvell's NAND flash controller does
- use fixed strength (1-bit for Hamming, 16-bit for BCH), so the actual
- step size will shrink or grow in order to fit the required strength.
- Step sizes are not completely random for all and follow certain
- patterns described in AN-379, "Marvell SoC NFC ECC".
-
-See Documentation/devicetree/bindings/mtd/nand-controller.yaml for more details on
-generic bindings.
-
-
-Example:
-nand_controller: nand-controller@d0000 {
- compatible = "marvell,armada370-nand-controller";
- reg = <0xd0000 0x54>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&coredivclk 0>;
-
- nand@0 {
- reg = <0>;
- label = "main-storage";
- nand-rb = <0>;
- nand-ecc-mode = "hw";
- marvell,nand-keep-config;
- nand-on-flash-bbt;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "Rootfs";
- reg = <0x00000000 0x40000000>;
- };
- };
- };
-};
-
-
-Note on legacy bindings: One can find, in not-updated device trees,
-bindings slightly different than described above with other properties
-described below as well as the partitions node at the root of a so
-called "nand" node (without clear controller/chip separation).
-
-Legacy properties:
-- marvell,nand-enable-arbiter: To enable the arbiter, all boards blindly
- used it, this bit was set by the bootloader for many boards and even if
- it is marked reserved in several datasheets, it might be needed to set
- it (otherwise it is harmless) so whether or not this property is set,
- the bit is selected by the driver.
-- num-cs: Number of chip-select lines to use, all boards blindly set 1
- to this and for a reason, other values would have failed. The value of
- this property is ignored.
-
-Example:
-
- nand0: nand@43100000 {
- compatible = "marvell,pxa3xx-nand";
- reg = <0x43100000 90>;
- interrupts = <45>;
- dmas = <&pdma 97 0>;
- dma-names = "rxtx";
- #address-cells = <1>;
- marvell,nand-keep-config;
- marvell,nand-enable-arbiter;
- num-cs = <1>;
- /* Partitions (optional) */
- };
diff --git a/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml b/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml
index a6e7f12..ab503a3 100644
--- a/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml
+++ b/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml
@@ -40,12 +40,11 @@
patternProperties:
"^nand@[a-f0-9]$":
- $ref: nand-chip.yaml#
+ $ref: raw-nand-chip.yaml#
unevaluatedProperties: false
properties:
reg:
maximum: 1
- nand-on-flash-bbt: true
nand-ecc-mode:
const: hw
diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
index f8c9768..18f6733 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
@@ -164,7 +164,7 @@
reg = <0 0xf80000>;
};
firmware@f80000 {
- label ="firmware";
+ label = "firmware";
reg = <0xf80000 0x80000>;
read-only;
};
diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml
index da3d488..b82ca03 100644
--- a/Documentation/devicetree/bindings/mtd/mtd.yaml
+++ b/Documentation/devicetree/bindings/mtd/mtd.yaml
@@ -12,7 +12,7 @@
properties:
$nodename:
- pattern: "^(flash|.*sram)(@.*)?$"
+ pattern: "^(flash|.*sram|nand)(@.*)?$"
label:
description:
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index f70a32d..83a4fe4 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -16,16 +16,6 @@
children nodes of the NAND controller. This representation should be
enforced even for simple controllers supporting only one chip.
- The ECC strength and ECC step size properties define the user
- desires in terms of correction capability of a controller. Together,
- they request the ECC engine to correct {strength} bit errors per
- {size} bytes.
-
- The interpretation of these parameters is implementation-defined, so
- not all implementations must support all possible
- combinations. However, implementations are encouraged to further
- specify the value(s) they support.
-
properties:
$nodename:
pattern: "^nand-controller(@.*)?"
@@ -51,79 +41,8 @@
patternProperties:
"^nand@[a-f0-9]$":
- $ref: nand-chip.yaml#
-
- properties:
- reg:
- description:
- Contains the chip-select IDs.
-
- nand-ecc-placement:
- description:
- Location of the ECC bytes. This location is unknown by default
- but can be explicitly set to "oob", if all ECC bytes are
- known to be stored in the OOB area, or "interleaved" if ECC
- bytes will be interleaved with regular data in the main area.
- $ref: /schemas/types.yaml#/definitions/string
- enum: [ oob, interleaved ]
-
- nand-bus-width:
- description:
- Bus width to the NAND chip
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [8, 16]
- default: 8
-
- nand-on-flash-bbt:
- description:
- With this property, the OS will search the device for a Bad
- Block Table (BBT). If not found, it will create one, reserve
- a few blocks at the end of the device to store it and update
- it as the device ages. Otherwise, the out-of-band area of a
- few pages of all the blocks will be scanned at boot time to
- find Bad Block Markers (BBM). These markers will help to
- build a volatile BBT in RAM.
- $ref: /schemas/types.yaml#/definitions/flag
-
- nand-ecc-maximize:
- description:
- Whether or not the ECC strength should be maximized. The
- maximum ECC strength is both controller and chip
- dependent. The ECC engine has to select the ECC config
- providing the best strength and taking the OOB area size
- constraint into account. This is particularly useful when
- only the in-band area is used by the upper layers, and you
- want to make your NAND as reliable as possible.
- $ref: /schemas/types.yaml#/definitions/flag
-
- nand-is-boot-medium:
- description:
- Whether or not the NAND chip is a boot medium. Drivers might
- use this information to select ECC algorithms supported by
- the boot ROM or similar restrictions.
- $ref: /schemas/types.yaml#/definitions/flag
-
- nand-rb:
- description:
- Contains the native Ready/Busy IDs.
- $ref: /schemas/types.yaml#/definitions/uint32-array
-
- rb-gpios:
- description:
- Contains one or more GPIO descriptor (the numper of descriptor
- depends on the number of R/B pins exposed by the flash) for the
- Ready/Busy pins. Active state refers to the NAND ready state and
- should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
-
- wp-gpios:
- description:
- Contains one GPIO descriptor for the Write Protect pin.
- Active state refers to the NAND Write Protect state and should be
- set to GPIOD_ACTIVE_LOW unless the signal is inverted.
- maxItems: 1
-
- required:
- - reg
+ type: object
+ $ref: raw-nand-chip.yaml#
required:
- "#address-cells"
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
index cdffbb9..1ebe9e2 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
@@ -55,6 +55,7 @@
linux,rootfs:
description: Marks partition that contains root filesystem to mount and boot
user space from
+ type: boolean
if:
not:
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
index 2edc65e..1dda2c8 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
@@ -21,6 +21,7 @@
- $ref: linksys,ns-partitions.yaml
- $ref: qcom,smem-part.yaml
- $ref: redboot-fis.yaml
+ - $ref: tplink,safeloader-partitions.yaml
properties:
compatible: true
diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
index 00c991f..4ada60f 100644
--- a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
+++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
@@ -34,7 +34,9 @@
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
+
nand-bus-width:
const: 8
@@ -45,6 +47,24 @@
enum:
- 512
+ qcom,boot-partitions:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: offset
+ - description: size
+ description:
+ Boot partition use a different layout where the 4 bytes of spare
+ data are not protected by ECC. Use this to declare these special
+ partitions by defining first the offset and then the size.
+
+ It's in the form of <offset1 size1 offset2 size2 offset3 ...>
+ and should be declared in ascending order.
+
+ Refer to the ipq8064 example on how to use this special binding.
+
+ unevaluatedProperties: false
+
allOf:
- $ref: nand-controller.yaml#
@@ -107,22 +127,15 @@
- qcom,ipq806x-nand
then:
- properties:
- qcom,boot-partitions:
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: offset
- - description: size
- description:
- Boot partition use a different layout where the 4 bytes of spare
- data are not protected by ECC. Use this to declare these special
- partitions by defining first the offset and then the size.
-
- It's in the form of <offset1 size1 offset2 size2 offset3 ...>
- and should be declared in ascending order.
-
- Refer to the ipq8064 example on how to use this special binding.
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ qcom,boot-partitions: true
+ else:
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ qcom,boot-partitions: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
new file mode 100644
index 0000000..092448d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/raw-nand-chip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raw NAND Chip Common Properties
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+allOf:
+ - $ref: nand-chip.yaml#
+
+description: |
+ The ECC strength and ECC step size properties define the user
+ desires in terms of correction capability of a controller. Together,
+ they request the ECC engine to correct {strength} bit errors per
+ {size} bytes for a particular raw NAND chip.
+
+ The interpretation of these parameters is implementation-defined, so
+ not all implementations must support all possible
+ combinations. However, implementations are encouraged to further
+ specify the value(s) they support.
+
+properties:
+ $nodename:
+ pattern: "^nand@[a-f0-9]$"
+
+ reg:
+ description:
+ Contains the chip-select IDs.
+
+ nand-ecc-placement:
+ description:
+ Location of the ECC bytes. This location is unknown by default
+ but can be explicitly set to "oob", if all ECC bytes are
+ known to be stored in the OOB area, or "interleaved" if ECC
+ bytes will be interleaved with regular data in the main area.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ oob, interleaved ]
+ deprecated: true
+
+ nand-ecc-mode:
+ description:
+ Legacy ECC configuration mixing the ECC engine choice and
+ configuration.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [none, soft, soft_bch, hw, hw_syndrome, on-die]
+ deprecated: true
+
+ nand-bus-width:
+ description:
+ Bus width to the NAND chip
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [8, 16]
+ default: 8
+
+ nand-on-flash-bbt:
+ description:
+ With this property, the OS will search the device for a Bad
+ Block Table (BBT). If not found, it will create one, reserve
+ a few blocks at the end of the device to store it and update
+ it as the device ages. Otherwise, the out-of-band area of a
+ few pages of all the blocks will be scanned at boot time to
+ find Bad Block Markers (BBM). These markers will help to
+ build a volatile BBT in RAM.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nand-ecc-maximize:
+ description:
+ Whether or not the ECC strength should be maximized. The
+ maximum ECC strength is both controller and chip
+ dependent. The ECC engine has to select the ECC config
+ providing the best strength and taking the OOB area size
+ constraint into account. This is particularly useful when
+ only the in-band area is used by the upper layers, and you
+ want to make your NAND as reliable as possible.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nand-is-boot-medium:
+ description:
+ Whether or not the NAND chip is a boot medium. Drivers might
+ use this information to select ECC algorithms supported by
+ the boot ROM or similar restrictions.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nand-rb:
+ description:
+ Contains the native Ready/Busy IDs.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ rb-gpios:
+ description:
+ Contains one or more GPIO descriptor (the numper of descriptor
+ depends on the number of R/B pins exposed by the flash) for the
+ Ready/Busy pins. Active state refers to the NAND ready state and
+ should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
+
+ wp-gpios:
+ description:
+ Contains one GPIO descriptor for the Write Protect pin.
+ Active state refers to the NAND Write Protect state and should be
+ set to GPIOD_ACTIVE_LOW unless the signal is inverted.
+ maxItems: 1
+
+required:
+ - reg
+
+# This is a generic file other binding inherit from and extend
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
index 7eb1d0a..ee53715 100644
--- a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
@@ -57,6 +57,7 @@
patternProperties:
"^nand@[0-7]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
reg:
minimum: 0
@@ -116,6 +117,8 @@
Only used in combination with 'nand-is-boot-medium'.
+ unevaluatedProperties: false
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
index 986e85c..e72cb5b 100644
--- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
@@ -37,6 +37,7 @@
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
nand-ecc-step-size:
const: 512
@@ -44,6 +45,8 @@
nand-ecc-strength:
enum: [1, 4, 8]
+ unevaluatedProperties: false
+
allOf:
- $ref: nand-controller.yaml#
diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml
index 4774c92..df4fdc0 100644
--- a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml
+++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml
@@ -30,6 +30,8 @@
patternProperties:
"^flash@[0-1],[0-9a-f]+$":
type: object
+ $ref: mtd-physmap.yaml
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
index 3bd912e..23e92be 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
@@ -7,7 +7,7 @@
title: Allwinner A20 GMAC
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 47bc205..4bfac91 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -63,7 +63,7 @@
- syscon
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/altr,tse.yaml b/Documentation/devicetree/bindings/net/altr,tse.yaml
index 9d02af4..f5d3b70 100644
--- a/Documentation/devicetree/bindings/net/altr,tse.yaml
+++ b/Documentation/devicetree/bindings/net/altr,tse.yaml
@@ -72,8 +72,8 @@
compatible:
contains:
enum:
- - const: altr,tse-1.0
- - const: ALTR,tse-1.0
+ - altr,tse-1.0
+ - ALTR,tse-1.0
then:
properties:
reg:
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
index a2c51a8..ee7a65b 100644
--- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -27,7 +27,7 @@
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
index 57e4c87..f01a398 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
@@ -24,11 +24,12 @@
- nxp,88w8997-bt
fw-init-baudrate:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 115200
description:
Chip baudrate after FW is downloaded and initialized.
This property depends on the module vendor's
- configuration. If this property is not specified,
- 115200 is set as default.
+ configuration.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
index 68f78b9..56cbb42b 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
@@ -16,6 +16,7 @@
properties:
compatible:
enum:
+ - qcom,qca2066-bt
- qcom,qca6174-bt
- qcom,qca9377-bt
- qcom,wcn3990-bt
@@ -50,6 +51,9 @@
vddch0-supply:
description: VDD_CH0 supply regulator handle
+ vddch1-supply:
+ description: VDD_CH1 supply regulator handle
+
vddaon-supply:
description: VDD_AON supply regulator handle
@@ -95,6 +99,7 @@
compatible:
contains:
enum:
+ - qcom,qca2066-bt
- qcom,qca6174-bt
then:
required:
diff --git a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml
index 0e5e5db..7c90a43 100644
--- a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml
+++ b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml
@@ -55,7 +55,7 @@
patternProperties:
"^mdio@[0-9a-f]+$":
type: object
- $ref: "brcm,unimac-mdio.yaml"
+ $ref: brcm,unimac-mdio.yaml
description:
GENET internal UniMAC MDIO bus
diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml
index bef5e0f..bf8894a 100644
--- a/Documentation/devicetree/bindings/net/cdns,macb.yaml
+++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml
@@ -109,6 +109,16 @@
power-domains:
maxItems: 1
+ cdns,rx-watermark:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the receive partial store and forward mode is activated,
+ the receiver will only begin to forward the packet to the external
+ AHB or AXI slave when enough packet data is stored in the SRAM packet buffer.
+ rx-watermark corresponds to the number of SRAM buffer locations,
+ that need to be filled, before the forwarding process is activated.
+ Width of the SRAM is platform dependent, and can be 4, 8 or 16 bytes.
+
'#address-cells':
const: 1
@@ -166,6 +176,7 @@
compatible = "cdns,macb";
reg = <0xfffc4000 0x4000>;
interrupts = <21>;
+ cdns,rx-watermark = <0x44>;
phy-mode = "rmii";
local-mac-address = [3a 0e 03 04 05 06];
clock-names = "pclk", "hclk", "tx_clk";
diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt
index 2363b41..3372613 100644
--- a/Documentation/devicetree/bindings/net/dsa/marvell.txt
+++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt
@@ -20,7 +20,7 @@
6171, 6172, 6175, 6176, 6185, 6240, 6320, 6321,
6341, 6350, 6351, 6352
- "marvell,mv88e6190" : Switch has base address 0x00. Use with models:
- 6190, 6190X, 6191, 6290, 6390, 6390X
+ 6163, 6190, 6190X, 6191, 6290, 6390, 6390X
- "marvell,mv88e6250" : Switch has base address 0x08 or 0x18. Use with model:
6220, 6250
diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
index 9a64ed6..4d5f5cc 100644
--- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
@@ -12,10 +12,6 @@
cs_sck_delay of 500ns. Ensuring that this SPI timing requirement is observed
depends on the SPI bus master driver.
-allOf:
- - $ref: dsa.yaml#/$defs/ethernet-ports
- - $ref: /schemas/spi/spi-peripheral-props.yaml#
-
maintainers:
- Vladimir Oltean <vladimir.oltean@nxp.com>
@@ -36,6 +32,9 @@
reg:
maxItems: 1
+ spi-cpha: true
+ spi-cpol: true
+
# Optional container node for the 2 internal MDIO buses of the SJA1110
# (one for the internal 100base-T1 PHYs and the other for the single
# 100base-TX PHY). The "reg" property does not have physical significance.
@@ -109,6 +108,30 @@
1860, 1880, 1900, 1920, 1940, 1960, 1980, 2000, 2020, 2040, 2060, 2080,
2100, 2120, 2140, 2160, 2180, 2200, 2220, 2240, 2260]
+allOf:
+ - $ref: dsa.yaml#/$defs/ethernet-ports
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - nxp,sja1105e
+ - nxp,sja1105p
+ - nxp,sja1105q
+ - nxp,sja1105r
+ - nxp,sja1105s
+ - nxp,sja1105t
+ then:
+ properties:
+ spi-cpol: false
+ required:
+ - spi-cpha
+ else:
+ properties:
+ spi-cpha: false
+ required:
+ - spi-cpol
+
unevaluatedProperties: false
examples:
@@ -120,6 +143,7 @@
ethernet-switch@1 {
reg = <0x1>;
compatible = "nxp,sja1105t";
+ spi-cpha;
ethernet-ports {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index 4f57453..c1241c8 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -93,6 +93,12 @@
the turn around line low at end of the control phase of the
MDIO transaction.
+ clocks:
+ maxItems: 1
+ description:
+ External clock connected to the PHY. If not specified it is assumed
+ that the PHY uses a fixed crystal or an internal oscillator.
+
enet-phy-lane-swap:
$ref: /schemas/types.yaml#/definitions/flag
description:
diff --git a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml
index d23fa37..42a0bc9 100644
--- a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml
+++ b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml
@@ -19,7 +19,7 @@
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
index d71fa9d..8a3713a 100644
--- a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
+++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
@@ -17,11 +17,12 @@
maxlinear,use-broken-interrupts:
description: |
Interrupts are broken on some GPY2xx PHYs in that they keep the
- interrupt line asserted even after the interrupt status register is
- cleared. Thus it is blocking the interrupt line which is usually bad
- for shared lines. By default interrupts are disabled for this PHY and
- polling mode is used. If one can live with the consequences, this
- property can be used to enable interrupt handling.
+ interrupt line asserted for a random amount of time even after the
+ interrupt status register is cleared. Thus it is blocking the
+ interrupt line which is usually bad for shared lines. By default,
+ interrupts are disabled for this PHY and polling mode is used. If one
+ can live with the consequences, this property can be used to enable
+ interrupt handling.
Affected PHYs (as far as known) are GPY215B and GPY215C.
type: boolean
diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
index acb2b2a..31cc0c4 100644
--- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
@@ -293,7 +293,7 @@
patternProperties:
"^mac@[0-1]$":
type: object
- additionalProperties: false
+ unevaluatedProperties: false
allOf:
- $ref: ethernet-controller.yaml#
description:
@@ -305,14 +305,9 @@
reg:
maxItems: 1
- phy-handle: true
-
- phy-mode: true
-
required:
- reg
- compatible
- - phy-handle
required:
- compatible
diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml
index 0fa2132..5aa320c 100644
--- a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml
@@ -25,7 +25,7 @@
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
properties:
compatible:
@@ -156,7 +156,7 @@
reg = <0x1101c000 0x1300>;
interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>;
interrupt-names = "macirq";
- phy-mode ="rgmii-rxid";
+ phy-mode = "rgmii-rxid";
mac-address = [00 55 7b b5 7d f7];
clock-names = "axi",
"apb",
diff --git a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml
index b44d835..b726c6e 100644
--- a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml
+++ b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml
@@ -44,13 +44,13 @@
allOf:
- $ref: ethernet-controller.yaml#
- - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
- if:
properties:
compatible:
contains:
const: micrel,ks8851
then:
+ $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
reg:
maxItems: 1
@@ -60,6 +60,7 @@
contains:
const: micrel,ks8851-mll
then:
+ $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
properties:
reg:
minItems: 2
diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml
index 63409cb..4c01cae 100644
--- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml
+++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml
@@ -24,7 +24,7 @@
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
index b110abb..2d382fa 100644
--- a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
+++ b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
@@ -16,7 +16,7 @@
properties:
$nodename:
- pattern: "^ethernet-pse(@.*)?$"
+ pattern: "^ethernet-pse(@.*|-([0-9]|[1-9][0-9]+))?$"
"#pse-cells":
description:
diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml
index 60a3804..7bdb412 100644
--- a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml
@@ -20,6 +20,7 @@
compatible:
enum:
- qcom,qcs404-ethqos
+ - qcom,sa8775p-ethqos
- qcom,sc8280xp-ethqos
- qcom,sm8150-ethqos
@@ -32,11 +33,13 @@
- const: rgmii
interrupts:
+ minItems: 1
items:
- description: Combined signal for various interrupt events
- description: The interrupt that occurs when Rx exits the LPI state
interrupt-names:
+ minItems: 1
items:
- const: macirq
- const: eth_lpi
@@ -49,11 +52,18 @@
- const: stmmaceth
- const: pclk
- const: ptp_ref
- - const: rgmii
+ - enum:
+ - rgmii
+ - phyaux
iommus:
maxItems: 1
+ phys: true
+
+ phy-names:
+ const: serdes
+
required:
- compatible
- clocks
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
index 2a21bbe..7f324c6 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
@@ -32,7 +32,7 @@
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
properties:
compatible:
@@ -91,12 +91,18 @@
$ref: /schemas/types.yaml#/definitions/phandle
tx_delay:
- description: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as default.
+ description: Delay value for TXD timing.
$ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 0x7F
+ default: 0x30
rx_delay:
- description: Delay value for RXD timing. Range value is 0~0x7F, 0x10 as default.
+ description: Delay value for RXD timing.
$ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 0x7F
+ default: 0x10
phy-supply:
description: PHY regulator
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 363b3e3..ddf9522 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -67,6 +67,7 @@
- loongson,ls2k-dwmac
- loongson,ls7a-dwmac
- qcom,qcs404-ethqos
+ - qcom,sa8775p-ethqos
- qcom,sc8280xp-ethqos
- qcom,sm8150-ethqos
- renesas,r9a06g032-gmac
@@ -582,6 +583,7 @@
- ingenic,x1600-mac
- ingenic,x1830-mac
- ingenic,x2000-mac
+ - qcom,sa8775p-ethqos
- qcom,sc8280xp-ethqos
- snps,dwmac-3.50a
- snps,dwmac-4.10a
@@ -638,6 +640,7 @@
- ingenic,x1830-mac
- ingenic,x2000-mac
- qcom,qcs404-ethqos
+ - qcom,sa8775p-ethqos
- qcom,sc8280xp-ethqos
- qcom,sm8150-ethqos
- snps,dwmac-4.00
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index 395a465..c9c2513 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -168,14 +168,14 @@
patternProperties:
"^mdio@[0-9a-f]+$":
type: object
- $ref: "ti,davinci-mdio.yaml#"
+ $ref: ti,davinci-mdio.yaml#
description:
CPSW MDIO bus.
"^cpts@[0-9a-f]+":
type: object
- $ref: "ti,k3-am654-cpts.yaml#"
+ $ref: ti,k3-am654-cpts.yaml#
description:
CPSW Common Platform Time Sync (CPTS) module.
diff --git a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
index 474fa8b..052f636 100644
--- a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
@@ -19,7 +19,7 @@
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
index fec1cc9..4aa521f 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
@@ -15,6 +15,9 @@
These chips also have a Bluetooth portion described in a separate
binding.
+allOf:
+ - $ref: ieee80211.yaml#
+
properties:
compatible:
oneOf:
@@ -38,6 +41,7 @@
- brcm,bcm4354-fmac
- brcm,bcm4356-fmac
- brcm,bcm4359-fmac
+ - brcm,bcm4366-fmac
- cypress,cyw4373-fmac
- cypress,cyw43012-fmac
- const: brcm,bcm4329-fmac
@@ -120,7 +124,7 @@
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index c85ed33..7758a55 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -84,6 +84,8 @@
required:
- iommus
+ ieee80211-freq-limit: true
+
qcom,ath10k-calibration-data:
$ref: /schemas/types.yaml#/definitions/uint8-array
description:
@@ -164,6 +166,7 @@
additionalProperties: false
allOf:
+ - $ref: ieee80211.yaml#
- if:
properties:
compatible:
@@ -355,4 +358,5 @@
"msi14",
"msi15",
"legacy";
+ ieee80211-freq-limit = <5470000 5875000>;
};
diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt b/Documentation/devicetree/bindings/net/xilinx_axienet.txt
deleted file mode 100644
index 80e505a..0000000
--- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-XILINX AXI ETHERNET Device Tree Bindings
---------------------------------------------------------
-
-Also called AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core
-provides connectivity to an external ethernet PHY supporting different
-interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two
-segments of memory for buffering TX and RX, as well as the capability of
-offloading TX/RX checksum calculation off the processor.
-
-Management configuration is done through the AXI interface, while payload is
-sent and received through means of an AXI DMA controller. This driver
-includes the DMA driver code, so this driver is incompatible with AXI DMA
-driver.
-
-For more details about mdio please refer phy.txt file in the same directory.
-
-Required properties:
-- compatible : Must be one of "xlnx,axi-ethernet-1.00.a",
- "xlnx,axi-ethernet-1.01.a", "xlnx,axi-ethernet-2.01.a"
-- reg : Address and length of the IO space, as well as the address
- and length of the AXI DMA controller IO space, unless
- axistream-connected is specified, in which case the reg
- attribute of the node referenced by it is used.
-- interrupts : Should be a list of 2 or 3 interrupts: TX DMA, RX DMA,
- and optionally Ethernet core. If axistream-connected is
- specified, the TX/RX DMA interrupts should be on that node
- instead, and only the Ethernet core interrupt is optionally
- specified here.
-- phy-handle : Should point to the external phy device if exists. Pointing
- this to the PCS/PMA PHY is deprecated and should be avoided.
- See ethernet.txt file in the same directory.
-- xlnx,rxmem : Set to allocated memory buffer for Rx/Tx in the hardware
-
-Optional properties:
-- phy-mode : See ethernet.txt
-- xlnx,phy-type : Deprecated, do not use, but still accepted in preference
- to phy-mode.
-- xlnx,txcsum : 0 or empty for disabling TX checksum offload,
- 1 to enable partial TX checksum offload,
- 2 to enable full TX checksum offload
-- xlnx,rxcsum : Same values as xlnx,txcsum but for RX checksum offload
-- xlnx,switch-x-sgmii : Boolean to indicate the Ethernet core is configured to
- support both 1000BaseX and SGMII modes. If set, the phy-mode
- should be set to match the mode selected on core reset (i.e.
- by the basex_or_sgmii core input line).
-- clock-names: Tuple listing input clock names. Possible clocks:
- s_axi_lite_clk: Clock for AXI register slave interface
- axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces
- ref_clk: Ethernet reference clock, used by signal delay
- primitives and transceivers
- mgt_clk: MGT reference clock (used by optional internal
- PCS/PMA PHY)
-
- Note that if s_axi_lite_clk is not specified by name, the
- first clock of any name is used for this. If that is also not
- specified, the clock rate is auto-detected from the CPU clock
- (but only on platforms where this is possible). New device
- trees should specify all applicable clocks by name - the
- fallbacks to an unnamed clock or to CPU clock are only for
- backward compatibility.
-- clocks: Phandles to input clocks matching clock-names. Refer to common
- clock bindings.
-- axistream-connected: Reference to another node which contains the resources
- for the AXI DMA controller used by this device.
- If this is specified, the DMA-related resources from that
- device (DMA registers and DMA TX/RX interrupts) rather
- than this one will be used.
- - mdio : Child node for MDIO bus. Must be defined if PHY access is
- required through the core's MDIO interface (i.e. always,
- unless the PHY is accessed through a different bus).
- Non-standard MDIO bus frequency is supported via
- "clock-frequency", see mdio.yaml.
-
- - pcs-handle: Phandle to the internal PCS/PMA PHY in SGMII or 1000Base-X
- modes, where "pcs-handle" should be used to point
- to the PCS/PMA PHY, and "phy-handle" should point to an
- external PHY if exists.
-
-Example:
- axi_ethernet_eth: ethernet@40c00000 {
- compatible = "xlnx,axi-ethernet-1.00.a";
- device_type = "network";
- interrupt-parent = <µblaze_0_axi_intc>;
- interrupts = <2 0 1>;
- clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
- clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
- phy-mode = "mii";
- reg = <0x40c00000 0x40000 0x50c00000 0x40000>;
- xlnx,rxcsum = <0x2>;
- xlnx,rxmem = <0x800>;
- xlnx,txcsum = <0x2>;
- phy-handle = <&phy0>;
- axi_ethernetlite_0_mdio: mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- phy0: phy@0 {
- device_type = "ethernet-phy";
- reg = <1>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml b/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
new file mode 100644
index 0000000..1d33d80
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
@@ -0,0 +1,183 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/xlnx,axi-ethernet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AXI 1G/2.5G Ethernet Subsystem
+
+description: |
+ Also called AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core
+ provides connectivity to an external ethernet PHY supporting different
+ interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two
+ segments of memory for buffering TX and RX, as well as the capability of
+ offloading TX/RX checksum calculation off the processor.
+
+ Management configuration is done through the AXI interface, while payload is
+ sent and received through means of an AXI DMA controller. This driver
+ includes the DMA driver code, so this driver is incompatible with AXI DMA
+ driver.
+
+maintainers:
+ - Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
+
+properties:
+ compatible:
+ enum:
+ - xlnx,axi-ethernet-1.00.a
+ - xlnx,axi-ethernet-1.01.a
+ - xlnx,axi-ethernet-2.01.a
+
+ reg:
+ description:
+ Address and length of the IO space, as well as the address
+ and length of the AXI DMA controller IO space, unless
+ axistream-connected is specified, in which case the reg
+ attribute of the node referenced by it is used.
+ maxItems: 2
+
+ interrupts:
+ items:
+ - description: Ethernet core interrupt
+ - description: Tx DMA interrupt
+ - description: Rx DMA interrupt
+ description:
+ Ethernet core interrupt is optional. If axistream-connected property is
+ present DMA node should contains TX/RX DMA interrupts else DMA interrupt
+ resources are mentioned on ethernet node.
+ minItems: 1
+
+ phy-handle: true
+
+ xlnx,rxmem:
+ description:
+ Set to allocated memory buffer for Rx/Tx in the hardware.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ phy-mode:
+ enum:
+ - mii
+ - gmii
+ - rgmii
+ - sgmii
+ - 1000BaseX
+
+ xlnx,phy-type:
+ description:
+ Do not use, but still accepted in preference to phy-mode.
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ xlnx,txcsum:
+ description:
+ TX checksum offload. 0 or empty for disabling TX checksum offload,
+ 1 to enable partial TX checksum offload and 2 to enable full TX
+ checksum offload.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+
+ xlnx,rxcsum:
+ description:
+ RX checksum offload. 0 or empty for disabling RX checksum offload,
+ 1 to enable partial RX checksum offload and 2 to enable full RX
+ checksum offload.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+
+ xlnx,switch-x-sgmii:
+ type: boolean
+ description:
+ Indicate the Ethernet core is configured to support both 1000BaseX and
+ SGMII modes. If set, the phy-mode should be set to match the mode
+ selected on core reset (i.e. by the basex_or_sgmii core input line).
+
+ clocks:
+ items:
+ - description: Clock for AXI register slave interface.
+ - description: AXI4-Stream clock for TXD RXD TXC and RXS interfaces.
+ - description: Ethernet reference clock, used by signal delay primitives
+ and transceivers.
+ - description: MGT reference clock (used by optional internal PCS/PMA PHY)
+
+ clock-names:
+ items:
+ - const: s_axi_lite_clk
+ - const: axis_clk
+ - const: ref_clk
+ - const: mgt_clk
+
+ axistream-connected:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle of AXI DMA controller which contains the resources
+ used by this device. If this is specified, the DMA-related resources
+ from that device (DMA registers and DMA TX/RX interrupts) rather than
+ this one will be used.
+
+ mdio:
+ type: object
+
+ pcs-handle:
+ description: Phandle to the internal PCS/PMA PHY in SGMII or 1000Base-X
+ modes, where "pcs-handle" should be used to point to the PCS/PMA PHY,
+ and "phy-handle" should point to an external PHY if exists.
+ maxItems: 1
+
+required:
+ - compatible
+ - interrupts
+ - reg
+ - xlnx,rxmem
+ - phy-handle
+
+allOf:
+ - $ref: /schemas/net/ethernet-controller.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ axi_ethernet_eth: ethernet@40c00000 {
+ compatible = "xlnx,axi-ethernet-1.00.a";
+ interrupts = <2 0 1>;
+ clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
+ clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
+ phy-mode = "mii";
+ reg = <0x40c00000 0x40000>,<0x50c00000 0x40000>;
+ xlnx,rxcsum = <0x2>;
+ xlnx,rxmem = <0x800>;
+ xlnx,txcsum = <0x2>;
+ phy-handle = <&phy0>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ reg = <1>;
+ };
+ };
+ };
+
+ - |
+ axi_ethernet_eth1: ethernet@40000000 {
+ compatible = "xlnx,axi-ethernet-1.00.a";
+ interrupts = <0>;
+ clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
+ clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
+ phy-mode = "mii";
+ reg = <0x00 0x40000000 0x00 0x40000>;
+ xlnx,rxcsum = <0x2>;
+ xlnx,rxmem = <0x800>;
+ xlnx,txcsum = <0x2>;
+ phy-handle = <&phy1>;
+ axistream-connected = <&dma>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy1: ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ reg = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
index 36def71..13412af 100644
--- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
+++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
@@ -36,14 +36,29 @@
et0macaddr:
type: object
description: First Ethernet interface's MAC address
+ properties:
+ "#nvmem-cell-cells":
+ description: The first argument is a MAC address offset.
+ const: 1
+ additionalProperties: false
et1macaddr:
type: object
description: Second Ethernet interface's MAC address
+ properties:
+ "#nvmem-cell-cells":
+ description: The first argument is a MAC address offset.
+ const: 1
+ additionalProperties: false
et2macaddr:
type: object
description: Third Ethernet interface's MAC address
+ properties:
+ "#nvmem-cell-cells":
+ description: The first argument is a MAC address offset.
+ const: 1
+ additionalProperties: false
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
index 9876243..99e60d7 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/nvmem/imx-ocotp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale i.MX6 On-Chip OTP Controller (OCOTP)
+title: Freescale i.MX On-Chip OTP Controller (OCOTP)
maintainers:
- Anson Huang <Anson.Huang@nxp.com>
@@ -12,7 +12,7 @@
description: |
This binding represents the on-chip eFuse OTP controller found on
i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL,
- i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN and i.MX8MP SoCs.
+ i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN i.MX8MP and i.MX93 SoCs.
allOf:
- $ref: nvmem.yaml#
@@ -32,6 +32,7 @@
- fsl,imx7ulp-ocotp
- fsl,imx8mq-ocotp
- fsl,imx8mm-ocotp
+ - fsl,imx93-ocotp
- const: syscon
- items:
- enum:
@@ -46,12 +47,6 @@
reg:
maxItems: 1
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 1
-
clocks:
maxItems: 1
@@ -61,21 +56,6 @@
- compatible
- reg
-patternProperties:
- "^.*@[0-9a-f]+$":
- type: object
-
- properties:
- reg:
- maxItems: 1
- description:
- Offset and size in bytes within the storage device.
-
- required:
- - reg
-
- additionalProperties: false
-
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
new file mode 100644
index 0000000..e698098
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/fixed-cell.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fixed offset & size NVMEM cell
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+properties:
+ reg:
+ maxItems: 1
+
+ bits:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - minimum: 0
+ maximum: 7
+ description:
+ Offset in bit within the address range specified by reg.
+ - minimum: 1
+ description:
+ Size in bit within the address range specified by reg.
+
+required:
+ - reg
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml
new file mode 100644
index 0000000..c271537
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/fixed-layout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout for fixed NVMEM cells
+
+description:
+ Many NVMEM devices have hardcoded cells layout (offset and size of defined
+ NVMEM content doesn't change).
+
+ This binding allows defining such NVMEM layout with its cells. It can be used
+ on top of any NVMEM device.
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ compatible:
+ const: fixed-layout
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+patternProperties:
+ "@[a-f0-9]+$":
+ type: object
+ $ref: fixed-cell.yaml
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ calibration@4000 {
+ reg = <0x4000 0x100>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
index 8512ee5..3b40f78 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
@@ -18,16 +18,13 @@
perform their parsing. The nvmem-layout container is here to describe these.
oneOf:
+ - $ref: fixed-layout.yaml
- $ref: kontron,sl28-vpd.yaml
- $ref: onie,tlv-layout.yaml
properties:
compatible: true
- '#address-cells': false
-
- '#size-cells': false
-
required:
- compatible
diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
index d16d42f..7ec2988 100644
--- a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
@@ -27,6 +27,7 @@
- enum:
- mediatek,mt7622-efuse
- mediatek,mt7623-efuse
+ - mediatek,mt7986-efuse
- mediatek,mt8173-efuse
- mediatek,mt8183-efuse
- mediatek,mt8186-efuse
diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
index 8938eec..a9b822a 100644
--- a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
@@ -18,12 +18,6 @@
- fsl,imx23-ocotp
- fsl,imx28-ocotp
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 1
-
reg:
maxItems: 1
@@ -35,7 +29,7 @@
- reg
- clocks
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 75bb93d..9802441 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -49,23 +49,8 @@
patternProperties:
"@[0-9a-f]+(,[0-7])?$":
type: object
-
- properties:
- reg:
- maxItems: 1
- description:
- Offset and size in bytes within the storage device.
-
- bits:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- - minimum: 0
- maximum: 7
- description:
- Offset in bit within the address range specified by reg.
- - minimum: 1
- description:
- Size in bit within the address range specified by reg.
+ $ref: layouts/fixed-cell.yaml
+ deprecated: true
additionalProperties: true
@@ -83,24 +68,30 @@
/* ... */
- /* Data cells */
- tsens_calibration: calib@404 {
- reg = <0x404 0x10>;
- };
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
- tsens_calibration_bckp: calib_bckp@504 {
- reg = <0x504 0x11>;
- bits = <6 128>;
- };
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x404 0x10>;
+ };
- pvs_version: pvs-version@6 {
- reg = <0x6 0x2>;
- bits = <7 2>;
- };
+ tsens_calibration_bckp: calib_bckp@504 {
+ reg = <0x504 0x11>;
+ bits = <6 128>;
+ };
- speed_bin: speed-bin@c{
- reg = <0xc 0x1>;
- bits = <2 3>;
+ pvs_version: pvs-version@6 {
+ reg = <0x6 0x2>;
+ bits = <7 2>;
+ };
+
+ speed_bin: speed-bin@c{
+ reg = <0xc 0x1>;
+ bits = <2 3>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index 8d8503d..6cd4682 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -18,8 +18,11 @@
- enum:
- qcom,apq8064-qfprom
- qcom,apq8084-qfprom
+ - qcom,ipq5332-qfprom
+ - qcom,ipq6018-qfprom
- qcom,ipq8064-qfprom
- qcom,ipq8074-qfprom
+ - qcom,ipq9574-qfprom
- qcom,msm8916-qfprom
- qcom,msm8974-qfprom
- qcom,msm8976-qfprom
@@ -64,12 +67,6 @@
power-domains:
maxItems: 1
- # Needed if any child nodes are present.
- "#address-cells":
- const: 1
- "#size-cells":
- const: 1
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml
index dce0c7d..cd980de 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml
@@ -25,12 +25,6 @@
reg:
maxItems: 1
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 1
-
ranges: true
required:
diff --git a/Documentation/devicetree/bindings/nvmem/rmem.yaml b/Documentation/devicetree/bindings/nvmem/rmem.yaml
index 38a39c9..1ec0d09 100644
--- a/Documentation/devicetree/bindings/nvmem/rmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/rmem.yaml
@@ -17,6 +17,7 @@
items:
- enum:
- raspberrypi,bootloader-config
+ - raspberrypi,bootloader-public-key
- const: nvmem-rmem
reg:
diff --git a/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
new file mode 100644
index 0000000..9c6eff7
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/rockchip,otp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip internal OTP (One Time Programmable) memory
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,px30-otp
+ - rockchip,rk3308-otp
+ - rockchip,rk3588-otp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 4
+
+ clock-names:
+ minItems: 3
+ items:
+ - const: otp
+ - const: apb_pclk
+ - const: phy
+ - const: arb
+
+ resets:
+ minItems: 1
+ maxItems: 3
+
+ reset-names:
+ minItems: 1
+ maxItems: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: nvmem.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,px30-otp
+ - rockchip,rk3308-otp
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ resets:
+ maxItems: 1
+ reset-names:
+ items:
+ - const: phy
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3588-otp
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ resets:
+ minItems: 3
+ reset-names:
+ items:
+ - const: otp
+ - const: apb
+ - const: arb
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/px30-cru.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ otp: efuse@ff290000 {
+ compatible = "rockchip,px30-otp";
+ reg = <0x0 0xff290000 0x0 0x4000>;
+ clocks = <&cru SCLK_OTP_USR>, <&cru PCLK_OTP_NS>,
+ <&cru PCLK_OTP_PHY>;
+ clock-names = "otp", "apb_pclk", "phy";
+ resets = <&cru SRST_OTP_PHY>;
+ reset-names = "phy";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpu_id: id@7 {
+ reg = <0x07 0x10>;
+ };
+
+ cpu_leakage: cpu-leakage@17 {
+ reg = <0x17 0x1>;
+ };
+
+ performance: performance@1e {
+ reg = <0x1e 0x1>;
+ bits = <4 3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-otp.txt b/Documentation/devicetree/bindings/nvmem/rockchip-otp.txt
deleted file mode 100644
index 40f649f..0000000
--- a/Documentation/devicetree/bindings/nvmem/rockchip-otp.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Rockchip internal OTP (One Time Programmable) memory device tree bindings
-
-Required properties:
-- compatible: Should be one of the following.
- - "rockchip,px30-otp" - for PX30 SoCs.
- - "rockchip,rk3308-otp" - for RK3308 SoCs.
-- reg: Should contain the registers location and size
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Should be "otp", "apb_pclk" and "phy".
-- resets: Must contain an entry for each entry in reset-names.
- See ../../reset/reset.txt for details.
-- reset-names: Should be "phy".
-
-See nvmem.txt for more information.
-
-Example:
- otp: otp@ff290000 {
- compatible = "rockchip,px30-otp";
- reg = <0x0 0xff290000 0x0 0x4000>;
- #address-cells = <1>;
- #size-cells = <1>;
- clocks = <&cru SCLK_OTP_USR>, <&cru PCLK_OTP_NS>,
- <&cru PCLK_OTP_PHY>;
- clock-names = "otp", "apb_pclk", "phy";
- };
diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
index b8bca05..efccc5a 100644
--- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
@@ -14,9 +14,6 @@
- $ref: nvmem.yaml#
properties:
- "#address-cells": true
- "#size-cells": true
-
compatible:
const: socionext,uniphier-efuse
diff --git a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml
index 8877c22..da3f1de 100644
--- a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml
@@ -28,12 +28,6 @@
clocks:
maxItems: 1
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 1
-
thermal-calibration:
type: object
description: thermal calibration values
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
index b3c22eb..8111122 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
@@ -13,6 +13,7 @@
compatible:
enum:
- qcom,sdx55-pcie-ep
+ - qcom,sdx65-pcie-ep
- qcom,sm8450-pcie-ep
reg:
@@ -109,6 +110,7 @@
contains:
enum:
- qcom,sdx55-pcie-ep
+ - qcom,sdx65-pcie-ep
then:
properties:
clocks:
diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
index 88386a6..6b62f6f 100644
--- a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
@@ -47,7 +47,7 @@
pcie-ep@f8000000 {
compatible = "rockchip,rk3399-pcie-ep";
- reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0x80000000 0x0 0x20000>;
+ reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0xfa000000 0x0 0x2000000>;
reg-names = "apb-base", "mem-base";
clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
<&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
@@ -63,6 +63,8 @@
phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>;
phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3";
rockchip,max-outbound-regions = <16>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_clkreqnb_cpm>;
};
};
...
diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
index 24c8894..a4f61ce 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
@@ -41,20 +41,24 @@
- const: config
clocks:
+ minItems: 5
items:
- description: AHB clock for PCIe master
- description: AHB clock for PCIe slave
- description: AHB clock for PCIe dbi
- description: APB clock for PCIe
- description: Auxiliary clock for PCIe
+ - description: PIPE clock
clock-names:
+ minItems: 5
items:
- const: aclk_mst
- const: aclk_slv
- const: aclk_dbi
- const: pclk
- const: aux
+ - const: pipe
msi-map: true
@@ -70,13 +74,19 @@
maxItems: 1
ranges:
- maxItems: 2
+ minItems: 2
+ maxItems: 3
resets:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
reset-names:
- const: pipe
+ oneOf:
+ - const: pipe
+ - items:
+ - const: pwr
+ - const: pipe
vpcie3v3-supply: true
diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml
index 24ddc28..4734be4 100644
--- a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml
+++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml
@@ -7,7 +7,7 @@
title: CPM Host Controller device tree for Xilinx Versal SoCs
maintainers:
- - Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
+ - Bharat Kumar Gogada <bharat.kumar.gogada@amd.com>
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
diff --git a/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml
index 50f46a6..4adab01 100644
--- a/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml
+++ b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml
@@ -42,8 +42,8 @@
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
pmu {
- #address-cells=<2>;
- #size-cells=<2>;
+ #address-cells = <2>;
+ #size-cells = <2>;
pmu@ff638000 {
compatible = "amlogic,g12a-ddr-pmu";
diff --git a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
index 80a9238..e9fad4b 100644
--- a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
+++ b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/perf/fsl-imx-ddr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale(NXP) IMX8 DDR performance monitor
+title: Freescale(NXP) IMX8/9 DDR performance monitor
maintainers:
- Frank Li <frank.li@nxp.com>
@@ -19,6 +19,7 @@
- fsl,imx8mm-ddr-pmu
- fsl,imx8mn-ddr-pmu
- fsl,imx8mp-ddr-pmu
+ - fsl,imx93-ddr-pmu
- items:
- enum:
- fsl,imx8mm-ddr-pmu
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
index 43a4b88..580fbe3 100644
--- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
@@ -115,8 +115,8 @@
compatible:
contains:
enum:
- - const: brcm,bcm4908-usb-phy
- - const: brcm,brcmstb-usb-phy
+ - brcm,bcm4908-usb-phy
+ - brcm,brcmstb-usb-phy
then:
properties:
reg:
diff --git a/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt
deleted file mode 100644
index 3dc8b3d..0000000
--- a/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-BROADCOM KONA USB2 PHY
-
-Required properties:
- - compatible: brcm,kona-usb2-phy
- - reg: offset and length of the PHY registers
- - #phy-cells: must be 0
-Refer to phy/phy-bindings.txt for the generic PHY binding properties
-
-Example:
-
- usbphy: usb-phy@3f130000 {
- compatible = "brcm,kona-usb2-phy";
- reg = <0x3f130000 0x28>;
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml
new file mode 100644
index 0000000..d7faeb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,kona-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family USB 2.0 PHY
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,kona-usb2-phy
+
+ reg:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@3f130000 {
+ compatible = "brcm,kona-usb2-phy";
+ reg = <0x3f130000 0x28>;
+ #phy-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml
index c9e65a2..c7281a7 100644
--- a/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml
@@ -31,6 +31,12 @@
"#phy-cells":
const: 0
+ cdns,usb2-disconnect-threshold-microvolt:
+ description: The microvolt threshold value utilized for detecting
+ USB disconnection event.
+ enum: [575, 610, 645]
+ default: 575
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
index e6f9f55..dc3a3f7 100644
--- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
@@ -35,6 +35,53 @@
description:
A phandle to the regulator for USB VBUS.
+ fsl,phy-tx-vref-tune-percent:
+ description:
+ Tunes the HS DC level relative to the nominal level
+ minimum: 94
+ maximum: 124
+
+ fsl,phy-tx-rise-tune-percent:
+ description:
+ Adjusts the rise/fall time duration of the HS waveform relative to
+ its nominal value
+ minimum: 97
+ maximum: 103
+
+ fsl,phy-tx-preemp-amp-tune-microamp:
+ description:
+ Adjust amount of current sourced to DPn and DMn after a J-to-K
+ or K-to-J transition. Default is 0 (disabled).
+ minimum: 0
+ maximum: 1800
+
+ fsl,phy-tx-vboost-level-microvolt:
+ description:
+ Adjust the boosted transmit launch pk-pk differential amplitude
+ minimum: 880
+ maximum: 1120
+
+ fsl,phy-comp-dis-tune-percent:
+ description:
+ Adjust the voltage level used to detect a disconnect event at the host
+ relative to the nominal value
+ minimum: 91
+ maximum: 115
+
+ fsl,phy-pcs-tx-deemph-3p5db-attenuation-db:
+ description:
+ Adjust TX de-emphasis attenuation in dB at nominal
+ 3.5dB point as per USB specification
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 36
+
+ fsl,phy-pcs-tx-swing-full-percent:
+ description:
+ Scaling of the voltage defined by fsl,phy-tx-vboost-level-microvolt
+ minimum: 0
+ maximum: 100
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
new file mode 100644
index 0000000..f4b1ca2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,mxs-usbphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS USB Phy Device
+
+maintainers:
+ - Xu Yang <xu.yang_2@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx23-usbphy
+ - fsl,imx7ulp-usbphy
+ - fsl,vf610-usbphy
+ - items:
+ - enum:
+ - fsl,imx28-usbphy
+ - fsl,imx6ul-usbphy
+ - fsl,imx6sl-usbphy
+ - fsl,imx6sx-usbphy
+ - fsl,imx6q-usbphy
+ - const: fsl,imx23-usbphy
+ - items:
+ - const: fsl,imx6sll-usbphy
+ - const: fsl,imx6ul-usbphy
+ - const: fsl,imx23-usbphy
+ - items:
+ - enum:
+ - fsl,imx8dxl-usbphy
+ - fsl,imx8qm-usbphy
+ - fsl,imx8ulp-usbphy
+ - const: fsl,imx7ulp-usbphy
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+ power-domains:
+ maxItems: 1
+
+ fsl,anatop:
+ description:
+ phandle for anatop register, it is only for imx6 SoC series.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ phy-3p0-supply:
+ description:
+ One of USB PHY's power supply. Can be used to keep a good signal
+ quality.
+
+ fsl,tx-cal-45-dn-ohms:
+ description:
+ Resistance (in ohms) of switchable high-speed trimming resistor
+ connected in parallel with the 45 ohm resistor that terminates
+ the DN output signal.
+ minimum: 35
+ maximum: 54
+ default: 45
+
+ fsl,tx-cal-45-dp-ohms:
+ description:
+ Resistance (in ohms) of switchable high-speed trimming resistor
+ connected in parallel with the 45 ohm resistor that terminates
+ the DP output signal.
+ minimum: 35
+ maximum: 54
+ default: 45
+
+ fsl,tx-d-cal:
+ description:
+ Current trimming value (as a percentage) of the 17.78 mA TX
+ reference current.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 79
+ maximum: 119
+ default: 100
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx6q-usbphy
+ - fsl,imx6sl-usbphy
+ - fsl,imx6sx-usbphy
+ - fsl,imx6sll-usbphy
+ - fsl,vf610-usbphy
+ - items:
+ - const: fsl,imx6ul-usbphy
+ - const: fsl,imx23-usbphy
+ then:
+ required:
+ - fsl,anatop
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+
+ usbphy1: usb-phy@20c9000 {
+ compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
+ reg = <0x020c9000 0x1000>;
+ clocks = <&clks IMX6QDL_CLK_USBPHY1>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ fsl,anatop = <&anatop>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
index 5d54b0a..7dd6a4d 100644
--- a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
@@ -15,7 +15,7 @@
properties:
$nodename:
- pattern: "combophy(@.*|-[0-9a-f])*$"
+ pattern: "combophy(@.*|-([0-9]|[1-9][0-9]+))?$"
compatible:
items:
diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
index 26f2b88..a63b20d 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
@@ -26,6 +26,10 @@
- const: mediatek,mt2701-mipi-tx
- items:
- enum:
+ - mediatek,mt6795-mipi-tx
+ - const: mediatek,mt8173-mipi-tx
+ - items:
+ - enum:
- mediatek,mt8365-mipi-tx
- const: mediatek,mt8183-mipi-tx
- const: mediatek,mt2701-mipi-tx
@@ -83,7 +87,7 @@
clocks = <&clk26m>;
clock-output-names = "mipi_tx0_pll";
drive-strength-microamp = <4000>;
- nvmem-cells= <&mipi_tx_calibration>;
+ nvmem-cells = <&mipi_tx_calibration>;
nvmem-cell-names = "calibration-data";
#clock-cells = <0>;
#phy-cells = <0>;
diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
index 786cfd7..3c28ec5 100644
--- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
@@ -32,15 +32,6 @@
clock-names:
const: phy_ref
- assigned-clocks:
- maxItems: 1
-
- assigned-clock-parents:
- maxItems: 1
-
- assigned-clock-rates:
- maxItems: 1
-
"#phy-cells":
const: 0
diff --git a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
deleted file mode 100644
index 70c813b..0000000
--- a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-* Freescale MXS USB Phy Device
-
-Required properties:
-- compatible: should contain:
- * "fsl,imx23-usbphy" for imx23 and imx28
- * "fsl,imx6q-usbphy" for imx6dq and imx6dl
- * "fsl,imx6sl-usbphy" for imx6sl
- * "fsl,vf610-usbphy" for Vybrid vf610
- * "fsl,imx6sx-usbphy" for imx6sx
- * "fsl,imx7ulp-usbphy" for imx7ulp
- * "fsl,imx8dxl-usbphy" for imx8dxl
- "fsl,imx23-usbphy" is still a fallback for other strings
-- reg: Should contain registers location and length
-- interrupts: Should contain phy interrupt
-- fsl,anatop: phandle for anatop register, it is only for imx6 SoC series
-
-Optional properties:
-- fsl,tx-cal-45-dn-ohms: Integer [35-54]. Resistance (in ohms) of switchable
- high-speed trimming resistor connected in parallel with the 45 ohm resistor
- that terminates the DN output signal. Default: 45
-- fsl,tx-cal-45-dp-ohms: Integer [35-54]. Resistance (in ohms) of switchable
- high-speed trimming resistor connected in parallel with the 45 ohm resistor
- that terminates the DP output signal. Default: 45
-- fsl,tx-d-cal: Integer [79-119]. Current trimming value (as a percentage) of
- the 17.78mA TX reference current. Default: 100
-
-Example:
-usbphy1: usb-phy@20c9000 {
- compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
- reg = <0x020c9000 0x1000>;
- interrupts = <0 44 0x04>;
- fsl,anatop = <&anatop>;
-};
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml
index 9ae514f..d3cd799 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml
@@ -31,8 +31,14 @@
- const: pipe
resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
items:
- - description: exclusive PHY reset line
+ - const: phy
+ - const: apb
rockchip,enable-ssc:
type: boolean
@@ -78,6 +84,32 @@
- rockchip,pipe-phy-grf
- "#phy-cells"
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3568-naneng-combphy
+ then:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3588-naneng-combphy
+ then:
+ properties:
+ resets:
+ minItems: 2
+ reset-names:
+ minItems: 2
+ required:
+ - reset-names
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml
index c4f8e6f..6566353 100644
--- a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml
@@ -43,6 +43,9 @@
"#phy-cells":
const: 0
+ power-domains:
+ maxItems: 1
+
vdda-phy-supply: true
vdda-pll-supply: true
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
index 62045dc..3d42ee3 100644
--- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
@@ -203,6 +203,7 @@
compatible:
contains:
enum:
+ - qcom,sc8180x-qmp-pcie-phy
- qcom,sm8250-qmp-gen3x2-pcie-phy
- qcom,sm8250-qmp-modem-pcie-phy
- qcom,sm8450-qmp-gen4x2-pcie-phy
@@ -224,7 +225,6 @@
compatible:
contains:
enum:
- - qcom,sc8180x-qmp-pcie-phy
- qcom,sdm845-qmp-pcie-phy
- qcom,sdx55-qmp-pcie-phy
- qcom,sm8250-qmp-gen3x1-pcie-phy
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml
index 80a5348..881ba54 100644
--- a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml
@@ -160,6 +160,7 @@
contains:
enum:
- qcom,msm8998-qmp-ufs-phy
+ - qcom,sc8180x-qmp-ufs-phy
- qcom,sdm845-qmp-ufs-phy
- qcom,sm6350-qmp-ufs-phy
- qcom,sm8150-qmp-ufs-phy
@@ -183,23 +184,6 @@
compatible:
contains:
enum:
- - qcom,sc8180x-qmp-ufs-phy
- then:
- patternProperties:
- "^phy@[0-9a-f]+$":
- properties:
- reg:
- items:
- - description: TX
- - description: RX
- - description: PCS
- - description: PCS_MISC
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- qcom,msm8996-qmp-ufs-phy
- qcom,sm6115-qmp-ufs-phy
then:
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml
index e81a382..4c96dab 100644
--- a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml
@@ -23,14 +23,12 @@
- qcom,ipq8074-qmp-usb3-phy
- qcom,msm8996-qmp-usb3-phy
- qcom,msm8998-qmp-usb3-phy
- - qcom,qcm2290-qmp-usb3-phy
- qcom,sc7180-qmp-usb3-phy
- qcom,sc8180x-qmp-usb3-phy
- qcom,sdm845-qmp-usb3-phy
- qcom,sdm845-qmp-usb3-uni-phy
- qcom,sdx55-qmp-usb3-uni-phy
- qcom,sdx65-qmp-usb3-uni-phy
- - qcom,sm6115-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-uni-phy
- qcom,sm8250-qmp-usb3-phy
@@ -253,29 +251,6 @@
compatible:
contains:
enum:
- - qcom,qcm2290-qmp-usb3-phy
- - qcom,sm6115-qmp-usb3-phy
- then:
- properties:
- clocks:
- maxItems: 3
- clock-names:
- items:
- - const: cfg_ahb
- - const: ref
- - const: com_aux
- resets:
- maxItems: 2
- reset-names:
- items:
- - const: phy_phy
- - const: phy
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- qcom,sdm845-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-phy
- qcom,sm8350-qmp-usb3-phy
@@ -318,12 +293,10 @@
enum:
- qcom,ipq6018-qmp-usb3-phy
- qcom,ipq8074-qmp-usb3-phy
- - qcom,qcm2290-qmp-usb3-phy
- qcom,sc7180-qmp-usb3-phy
- qcom,sc8180x-qmp-usb3-phy
- qcom,sdx55-qmp-usb3-uni-phy
- qcom,sdx65-qmp-usb3-uni-phy
- - qcom,sm6115-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-uni-phy
- qcom,sm8250-qmp-usb3-phy
then:
diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 543c1a2..95eecba 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -18,13 +18,14 @@
oneOf:
- items:
- enum:
+ - qcom,ipq6018-qusb2-phy
- qcom,ipq8074-qusb2-phy
+ - qcom,ipq9574-qusb2-phy
- qcom,msm8953-qusb2-phy
- qcom,msm8996-qusb2-phy
- qcom,msm8998-qusb2-phy
- qcom,qcm2290-qusb2-phy
- qcom,sdm660-qusb2-phy
- - qcom,ipq6018-qusb2-phy
- qcom,sm4250-qusb2-phy
- qcom,sm6115-qusb2-phy
- items:
diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml
new file mode 100644
index 0000000..b910775
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SerDes/SGMII ethernet PHY controller
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description:
+ The SerDes PHY sits between the MAC and the external PHY and provides
+ separate Rx Tx lines.
+
+properties:
+ compatible:
+ const: qcom,sa8775p-dwmac-sgmii-phy
+
+ reg:
+ items:
+ - description: serdes
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: sgmi_ref
+
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to the PHY.
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ serdes_phy: phy@8901000 {
+ compatible = "qcom,sa8775p-dwmac-sgmii-phy";
+ reg = <0x08901000 0xe10>;
+ clocks = <&gcc GCC_SGMI_CLKREF_EN>;
+ clock-names = "sgmi_ref";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml
index 0ef2c9b..d307343 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml
@@ -61,6 +61,10 @@
power-domains:
maxItems: 1
+ orientation-switch:
+ description: Flag the port as possible handler of orientation switching
+ type: boolean
+
resets:
items:
- description: reset of phy block.
@@ -251,6 +255,8 @@
vdda-phy-supply = <&vdda_usb2_ss_1p2>;
vdda-pll-supply = <&vdda_usb2_ss_core>;
+ orientation-switch;
+
usb3-phy@200 {
reg = <0x200 0x128>,
<0x400 0x200>,
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index 94c0fab..a1897a7 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -78,9 +78,9 @@
then:
properties:
clocks:
- maxItems: 3
+ minItems: 3
clock-names:
- maxItems: 3
+ minItems: 3
else:
properties:
clocks:
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
index 16fce10..f99fbbc 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
@@ -16,7 +16,11 @@
properties:
compatible:
enum:
+ - qcom,ipq9574-qmp-usb3-phy
+ - qcom,qcm2290-qmp-usb3-phy
+ - qcom,sa8775p-qmp-usb3-uni-phy
- qcom,sc8280xp-qmp-usb3-uni-phy
+ - qcom,sm6115-qmp-usb3-phy
reg:
maxItems: 1
@@ -25,11 +29,7 @@
maxItems: 4
clock-names:
- items:
- - const: aux
- - const: ref
- - const: com_aux
- - const: pipe
+ maxItems: 4
power-domains:
maxItems: 1
@@ -60,7 +60,6 @@
- reg
- clocks
- clock-names
- - power-domains
- resets
- reset-names
- vdda-phy-supply
@@ -69,6 +68,60 @@
- clock-output-names
- "#phy-cells"
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq9574-qmp-usb3-phy
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: aux
+ - const: ref
+ - const: cfg_ahb
+ - const: pipe
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcm2290-qmp-usb3-phy
+ - qcom,sm6115-qmp-usb3-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: cfg_ahb
+ - const: ref
+ - const: com_aux
+ - const: pipe
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-qmp-usb3-uni-phy
+ - qcom,sc8280xp-qmp-usb3-uni-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: aux
+ - const: ref
+ - const: com_aux
+ - const: pipe
+ required:
+ - power-domains
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
index 3cd5fc3..ef1c02d 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -60,6 +60,26 @@
description:
See include/dt-bindings/dt-bindings/phy/phy-qcom-qmp.h
+ orientation-switch:
+ description:
+ Flag the PHY as possible handler of USB Type-C orientation switching
+ type: boolean
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output endpoint of the PHY
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the USB controller
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the DisplayPort controller
+
required:
- compatible
- reg
@@ -98,6 +118,37 @@
vdda-phy-supply = <&vreg_l9d>;
vdda-pll-supply = <&vreg_l4d>;
+ orientation-switch;
+
#clock-cells = <1>;
#phy-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&typec_connector_ss>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <&dwc3_ss_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ remote-endpoint = <&mdss_dp_out>;
+ };
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml
index aa97478..f042d6a 100644
--- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml
@@ -13,7 +13,9 @@
properties:
compatible:
contains:
- const: qcom,usb-hs-phy-apq8064
+ enum:
+ - qcom,usb-hs-phy-apq8064
+ - qcom,usb-hs-phy-msm8960
then:
properties:
resets:
@@ -40,6 +42,7 @@
- qcom,usb-hs-phy-apq8064
- qcom,usb-hs-phy-msm8226
- qcom,usb-hs-phy-msm8916
+ - qcom,usb-hs-phy-msm8960
- qcom,usb-hs-phy-msm8974
- const: qcom,usb-hs-phy
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
index a26524b..0f200e3 100644
--- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
@@ -20,6 +20,7 @@
- qcom,usb-snps-femto-v2-phy
- items:
- enum:
+ - qcom,sa8775p-usb-hs-phy
- qcom,sc8280xp-usb-hs-phy
- const: qcom,usb-snps-hs-5nm-phy
- items:
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
index e2b861c..774c3c269 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
@@ -37,7 +37,8 @@
Optional properties:
- GENERIC_PINCONFIG: generic pinconfig options to use:
- bias-disable, bias-pull-down, bias-pull-up, drive-open-drain,
- input-schmitt-enable, input-debounce, output-low, output-high.
+ drive-push-pull input-schmitt-enable, input-debounce, output-low,
+ output-high.
- for microchip,sama7g5-pinctrl only:
- slew-rate: 0 - disabled, 1 - enabled (default)
- atmel,drive-strength: 0 or 1 for low drive, 2 for medium drive and 3 for
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
new file mode 100644
index 0000000..f3deda9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux-aon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra234 AON Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+$ref: nvidia,tegra234-pinmux-common.yaml
+
+properties:
+ compatible:
+ const: nvidia,tegra234-pinmux-aon
+
+patternProperties:
+ "^pinmux(-[a-z0-9-]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ can0_dout_paa0, can0_din_paa1, can1_dout_paa2,
+ can1_din_paa3, can0_stb_paa4, can0_en_paa5,
+ soc_gpio49_paa6, can0_err_paa7, can1_stb_pbb0,
+ can1_en_pbb1, soc_gpio50_pbb2, can1_err_pbb3,
+ spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2,
+ spi2_cs0_pcc3, touch_clk_pcc4, uart3_tx_pcc5,
+ uart3_rx_pcc6, gen2_i2c_scl_pcc7, gen2_i2c_sda_pdd0,
+ gen8_i2c_scl_pdd1, gen8_i2c_sda_pdd2,
+ sce_error_pee0, vcomp_alert_pee1,
+ ao_retention_n_pee2, batt_oc_pee3, power_on_pee4,
+ soc_gpio26_pee5, soc_gpio27_pee6, bootv_ctl_n_pee7,
+ hdmi_cec_pgg0,
+ # drive groups
+ drive_touch_clk_pcc4, drive_uart3_rx_pcc6,
+ drive_uart3_tx_pcc5, drive_gen8_i2c_sda_pdd2,
+ drive_gen8_i2c_scl_pdd1, drive_spi2_mosi_pcc2,
+ drive_gen2_i2c_scl_pcc7, drive_spi2_cs0_pcc3,
+ drive_gen2_i2c_sda_pdd0, drive_spi2_sck_pcc0,
+ drive_spi2_miso_pcc1, drive_can1_dout_paa2,
+ drive_can1_din_paa3, drive_can0_dout_paa0,
+ drive_can0_din_paa1, drive_can0_stb_paa4,
+ drive_can0_en_paa5, drive_soc_gpio49_paa6,
+ drive_can0_err_paa7, drive_can1_stb_pbb0,
+ drive_can1_en_pbb1, drive_soc_gpio50_pbb2,
+ drive_can1_err_pbb3, drive_sce_error_pee0,
+ drive_batt_oc_pee3, drive_bootv_ctl_n_pee7,
+ drive_power_on_pee4, drive_soc_gpio26_pee5,
+ drive_soc_gpio27_pee6, drive_ao_retention_n_pee2,
+ drive_vcomp_alert_pee1, drive_hdmi_cec_pgg0 ]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-tegra.h>
+
+ pinmux@c300000 {
+ compatible = "nvidia,tegra234-pinmux-aon";
+ reg = <0xc300000 0x4000>;
+
+ pinctrl-names = "cec";
+ pinctrl-0 = <&cec_state>;
+
+ cec_state: pinmux-cec {
+ cec {
+ nvidia,pins = "hdmi_cec_pgg0";
+ nvidia,function = "gp";
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml
new file mode 100644
index 0000000..4f9de78
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra234 Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ reg:
+ items:
+ - description: pinmux registers
+
+patternProperties:
+ "^pinmux(-[a-z0-9-]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra-pinmux-common.yaml
+ # We would typically use unevaluatedProperties here but that has the
+ # downside that all the properties in the common bindings become valid
+ # for all chip generations. In this case, however, we want the per-SoC
+ # bindings to be able to override which of the common properties are
+ # allowed, since not all pinmux generations support the same sets of
+ # properties. This way, the common bindings define the format of the
+ # properties but the per-SoC bindings define which of them apply to a
+ # given chip.
+ additionalProperties: false
+ properties:
+ nvidia,function:
+ enum: [ gp, uartc, i2c8, spi2, i2c2, can1, can0, rsvd0, eth0, eth2,
+ eth1, dp, eth3, i2c4, i2c7, i2c9, eqos, pe2, pe1, pe0, pe3,
+ pe4, pe5, pe6, pe7, pe8, pe9, pe10, qspi0, qspi1, qpsi,
+ sdmmc1, sce, soc, gpio, hdmi, ufs0, spi3, spi1, uartb, uarte,
+ usb, extperiph2, extperiph1, i2c3, vi0, i2c5, uarta, uartd,
+ i2c1, i2s4, i2s6, aud, spi5, touch, uartj, rsvd1, wdt, tsc,
+ dmic3, led, vi0_alt, i2s5, nv, extperiph3, extperiph4, spi4,
+ ccla, i2s1, i2s2, i2s3, i2s8, rsvd2, dmic5, dca, displayb,
+ displaya, vi1, dcb, dmic1, dmic4, i2s7, dmic2, dspk0, rsvd3,
+ tsc_alt, istctrl, vi1_alt, dspk1, igpu ]
+
+ # out of the common properties, only these are allowed for Tegra234
+ nvidia,pins: true
+ nvidia,pull: true
+ nvidia,tristate: true
+ nvidia,schmitt: true
+ nvidia,enable-input: true
+ nvidia,open-drain: true
+ nvidia,lock: true
+ nvidia,drive-type: true
+ nvidia,io-hv: true
+
+ required:
+ - nvidia,pins
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
new file mode 100644
index 0000000..17b865e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra234 Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+$ref: nvidia,tegra234-pinmux-common.yaml
+
+properties:
+ compatible:
+ const: nvidia,tegra234-pinmux
+
+patternProperties:
+ "^pinmux(-[a-z0-9-]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ dap6_sclk_pa0, dap6_dout_pa1, dap6_din_pa2,
+ dap6_fs_pa3, dap4_sclk_pa4, dap4_dout_pa5,
+ dap4_din_pa6, dap4_fs_pa7, soc_gpio08_pb0,
+ qspi0_sck_pc0, qspi0_cs_n_pc1,
+ qspi0_io0_pc2, qspi0_io1_pc3, qspi0_io2_pc4,
+ qspi0_io3_pc5, qspi1_sck_pc6, qspi1_cs_n_pc7,
+ qspi1_io0_pd0, qspi1_io1_pd1, qspi1_io2_pd2,
+ qspi1_io3_pd3, eqos_txc_pe0, eqos_td0_pe1,
+ eqos_td1_pe2, eqos_td2_pe3, eqos_td3_pe4,
+ eqos_tx_ctl_pe5, eqos_rd0_pe6, eqos_rd1_pe7,
+ eqos_rd2_pf0, eqos_rd3_pf1, eqos_rx_ctl_pf2,
+ eqos_rxc_pf3, eqos_sma_mdio_pf4, eqos_sma_mdc_pf5,
+ soc_gpio13_pg0, soc_gpio14_pg1, soc_gpio15_pg2,
+ soc_gpio16_pg3, soc_gpio17_pg4, soc_gpio18_pg5,
+ soc_gpio19_pg6, soc_gpio20_pg7, soc_gpio21_ph0,
+ soc_gpio22_ph1, soc_gpio06_ph2, uart4_tx_ph3,
+ uart4_rx_ph4, uart4_rts_ph5, uart4_cts_ph6,
+ soc_gpio41_ph7, soc_gpio42_pi0, soc_gpio43_pi1,
+ soc_gpio44_pi2, gen1_i2c_scl_pi3, gen1_i2c_sda_pi4,
+ cpu_pwr_req_pi5, soc_gpio07_pi6,
+ sdmmc1_clk_pj0, sdmmc1_cmd_pj1, sdmmc1_dat0_pj2,
+ sdmmc1_dat1_pj3, sdmmc1_dat2_pj4, sdmmc1_dat3_pj5,
+ pex_l0_clkreq_n_pk0, pex_l0_rst_n_pk1,
+ pex_l1_clkreq_n_pk2, pex_l1_rst_n_pk3,
+ pex_l2_clkreq_n_pk4, pex_l2_rst_n_pk5,
+ pex_l3_clkreq_n_pk6, pex_l3_rst_n_pk7,
+ pex_l4_clkreq_n_pl0, pex_l4_rst_n_pl1,
+ pex_wake_n_pl2, soc_gpio34_pl3, dp_aux_ch0_hpd_pm0,
+ dp_aux_ch1_hpd_pm1, dp_aux_ch2_hpd_pm2,
+ dp_aux_ch3_hpd_pm3, soc_gpio55_pm4, soc_gpio36_pm5,
+ soc_gpio53_pm6, soc_gpio38_pm7, dp_aux_ch3_n_pn0,
+ soc_gpio39_pn1, soc_gpio40_pn2, dp_aux_ch1_p_pn3,
+ dp_aux_ch1_n_pn4, dp_aux_ch2_p_pn5, dp_aux_ch2_n_pn6,
+ dp_aux_ch3_p_pn7, extperiph1_clk_pp0,
+ extperiph2_clk_pp1, cam_i2c_scl_pp2, cam_i2c_sda_pp3,
+ soc_gpio23_pp4, soc_gpio24_pp5, soc_gpio25_pp6,
+ pwr_i2c_scl_pp7, pwr_i2c_sda_pq0, soc_gpio28_pq1,
+ soc_gpio29_pq2, soc_gpio30_pq3, soc_gpio31_pq4,
+ soc_gpio32_pq5, soc_gpio33_pq6, soc_gpio35_pq7,
+ soc_gpio37_pr0, soc_gpio56_pr1, uart1_tx_pr2,
+ uart1_rx_pr3, uart1_rts_pr4, uart1_cts_pr5,
+ soc_gpio61_pw0, soc_gpio62_pw1, gpu_pwr_req_px0,
+ cv_pwr_req_px1, gp_pwm2_px2, gp_pwm3_px3, uart2_tx_px4,
+ uart2_rx_px5, uart2_rts_px6, uart2_cts_px7, spi3_sck_py0,
+ spi3_miso_py1, spi3_mosi_py2, spi3_cs0_py3,
+ spi3_cs1_py4, uart5_tx_py5, uart5_rx_py6,
+ uart5_rts_py7, uart5_cts_pz0, usb_vbus_en0_pz1,
+ usb_vbus_en1_pz2, spi1_sck_pz3, spi1_miso_pz4,
+ spi1_mosi_pz5, spi1_cs0_pz6, spi1_cs1_pz7,
+ spi5_sck_pac0, spi5_miso_pac1, spi5_mosi_pac2,
+ spi5_cs0_pac3, soc_gpio57_pac4, soc_gpio58_pac5,
+ soc_gpio59_pac6, soc_gpio60_pac7, soc_gpio45_pad0,
+ soc_gpio46_pad1, soc_gpio47_pad2, soc_gpio48_pad3,
+ ufs0_ref_clk_pae0, ufs0_rst_n_pae1,
+ pex_l5_clkreq_n_paf0, pex_l5_rst_n_paf1,
+ pex_l6_clkreq_n_paf2, pex_l6_rst_n_paf3,
+ pex_l7_clkreq_n_pag0, pex_l7_rst_n_pag1,
+ pex_l8_clkreq_n_pag2, pex_l8_rst_n_pag3,
+ pex_l9_clkreq_n_pag4, pex_l9_rst_n_pag5,
+ pex_l10_clkreq_n_pag6, pex_l10_rst_n_pag7,
+ sdmmc1_comp, eqos_comp, qspi_comp,
+ # drive groups
+ drive_soc_gpio08_pb0, drive_soc_gpio36_pm5,
+ drive_soc_gpio53_pm6, drive_soc_gpio55_pm4,
+ drive_soc_gpio38_pm7, drive_soc_gpio39_pn1,
+ drive_soc_gpio40_pn2, drive_dp_aux_ch0_hpd_pm0,
+ drive_dp_aux_ch1_hpd_pm1, drive_dp_aux_ch2_hpd_pm2,
+ drive_dp_aux_ch3_hpd_pm3, drive_dp_aux_ch1_p_pn3,
+ drive_dp_aux_ch1_n_pn4, drive_dp_aux_ch2_p_pn5,
+ drive_dp_aux_ch2_n_pn6, drive_dp_aux_ch3_p_pn7,
+ drive_dp_aux_ch3_n_pn0, drive_pex_l2_clkreq_n_pk4,
+ drive_pex_wake_n_pl2, drive_pex_l1_clkreq_n_pk2,
+ drive_pex_l1_rst_n_pk3, drive_pex_l0_clkreq_n_pk0,
+ drive_pex_l0_rst_n_pk1, drive_pex_l2_rst_n_pk5,
+ drive_pex_l3_clkreq_n_pk6, drive_pex_l3_rst_n_pk7,
+ drive_pex_l4_clkreq_n_pl0, drive_pex_l4_rst_n_pl1,
+ drive_soc_gpio34_pl3, drive_pex_l5_clkreq_n_paf0,
+ drive_pex_l5_rst_n_paf1, drive_pex_l6_clkreq_n_paf2,
+ drive_pex_l6_rst_n_paf3, drive_pex_l10_clkreq_n_pag6,
+ drive_pex_l10_rst_n_pag7, drive_pex_l7_clkreq_n_pag0,
+ drive_pex_l7_rst_n_pag1, drive_pex_l8_clkreq_n_pag2,
+ drive_pex_l8_rst_n_pag3, drive_pex_l9_clkreq_n_pag4,
+ drive_pex_l9_rst_n_pag5, drive_sdmmc1_clk_pj0,
+ drive_sdmmc1_cmd_pj1, drive_sdmmc1_dat3_pj5,
+ drive_sdmmc1_dat2_pj4, drive_sdmmc1_dat1_pj3,
+ drive_sdmmc1_dat0_pj2 ]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-tegra.h>
+
+ pinmux@2430000 {
+ compatible = "nvidia,tegra234-pinmux";
+ reg = <0x2430000 0x17000>;
+
+ pinctrl-names = "pex_rst";
+ pinctrl-0 = <&pex_rst_c5_out_state>;
+
+ pex_rst_c5_out_state: pinmux-pex-rst-c5-out {
+ pexrst {
+ nvidia,pins = "pex_l5_rst_n_paf1";
+ nvidia,schmitt = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ nvidia,io-hv = <TEGRA_PIN_ENABLE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml
new file mode 100644
index 0000000..fad0118
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq5018-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm IPQ5018 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ5018 SoC.
+
+properties:
+ compatible:
+ const: qcom,ipq5018-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+ "#interrupt-cells": true
+ gpio-controller: true
+ "#gpio-cells": true
+ gpio-ranges: true
+ wakeup-parent: true
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 24
+
+ gpio-line-names:
+ maxItems: 47
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq5018-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq5018-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq5018-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-3][0-9]|4[0-6])$"
+ minItems: 1
+ maxItems: 8
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, audio_pdm0, audio_pdm1, audio_rxbclk, audio_rxd,
+ audio_rxfsync, audio_rxmclk, audio_txbclk, audio_txd,
+ audio_txfsync, audio_txmclk, blsp0_i2c, blsp0_spi, blsp0_uart0,
+ blsp0_uart1, blsp1_i2c0, blsp1_i2c1, blsp1_spi0, blsp1_spi1,
+ blsp1_uart0, blsp1_uart1, blsp1_uart2, blsp2_i2c0, blsp2_i2c1,
+ blsp2_spi, blsp2_spi0, blsp2_spi1, btss, burn0, burn1, cri_trng,
+ cri_trng0, cri_trng1, cxc_clk, cxc_data, dbg_out, eud_gpio,
+ gcc_plltest, gcc_tlmm, gpio, led0, led2, mac0, mac1, mdc, mdio,
+ pcie0_clk, pcie0_wake, pcie1_clk, pcie1_wake, pll_test,
+ prng_rosc, pwm0, pwm1, pwm2, pwm3, qdss_cti_trig_in_a0,
+ qdss_cti_trig_in_a1, qdss_cti_trig_in_b0, qdss_cti_trig_in_b1,
+ qdss_cti_trig_out_a0, qdss_cti_trig_out_a1,
+ qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, qdss_traceclk_a,
+ qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b,
+ qdss_tracedata_a, qdss_tracedata_b, qspi_clk, qspi_cs,
+ qspi_data, reset_out, sdc1_clk, sdc1_cmd, sdc1_data, wci_txd,
+ wci_rxd, wsa_swrm, wsi_clk3, wsi_data3, wsis_reset, xfem ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq5018-tlmm";
+ reg = <0x01000000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 47>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio33";
+ function = "blsp1_uart1";
+ bias-pull-down;
+ };
+
+ tx-pins {
+ pins = "gpio34";
+ function = "blsp1_uart1";
+ bias-pull-down;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml
index 673713d..e5e9962 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml
@@ -53,6 +53,7 @@
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -86,19 +87,9 @@
rx0, rx1, sdc_clk, sdc_cmd, sdc_data, sdc_rclk, tsens_max,
wci20, wci21, wsa_swrm ]
- bias-pull-down: true
- bias-pull-up: true
- bias-disable: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
required:
- pins
- additionalProperties: false
-
allOf:
- $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
index eaadd5a..8aaf501 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
@@ -49,6 +49,7 @@
- qcom,pm8921-gpio
- qcom,pm8941-gpio
- qcom,pm8950-gpio
+ - qcom,pm8953-gpio
- qcom,pm8994-gpio
- qcom,pm8998-gpio
- qcom,pma8084-gpio
@@ -175,6 +176,7 @@
- qcom,pm8350b-gpio
- qcom,pm8550ve-gpio
- qcom,pm8950-gpio
+ - qcom,pm8953-gpio
- qcom,pmi632-gpio
then:
properties:
@@ -434,6 +436,7 @@
- gpio1-gpio44 for pm8921
- gpio1-gpio36 for pm8941
- gpio1-gpio8 for pm8950 (hole on gpio3)
+ - gpio1-gpio8 for pm8953 (hole on gpio3 and gpio6)
- gpio1-gpio22 for pm8994
- gpio1-gpio26 for pm8998
- gpio1-gpio22 for pma8084
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml
index 0327636..c323f6d 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml
@@ -45,6 +45,7 @@
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -81,19 +82,9 @@
uim2_data, uim2_present, uim2_reset, usb_phy, vfr_1,
vsense_trigger, wlan1_adc0, wlan1_adc1 ]
- bias-pull-down: true
- bias-pull-up: true
- bias-disable: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
required:
- pins
- additionalProperties: false
-
allOf:
- $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml
index 4ae39fc..4bd6d79 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml
@@ -55,6 +55,7 @@
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -104,20 +105,9 @@
usb1_phy, usb1_sbrx, usb1_sbtx, usb1_usb4, usb2phy_ac,
vsense_trigger ]
- bias-bus-hold: true
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
required:
- pins
- additionalProperties: false
-
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml
index 2ef793a..2731978 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml
@@ -85,7 +85,7 @@
qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14,
dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem,
dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto,
- dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0,
+ dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, pcie_clkreq,
dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25,
sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2,
qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3,
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml
new file mode 100644
index 0000000..7cb96aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdx75-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SDX75 TLMM block
+
+maintainers:
+ - Rohit Agarwal <quic_rohiagar@quicinc.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SDX75 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sdx75-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts: true
+ interrupt-controller: true
+ "#interrupt-cells": true
+ gpio-controller: true
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 67
+
+ gpio-line-names:
+ maxItems: 133
+
+ "#gpio-cells": true
+ gpio-ranges: true
+ wakeup-parent: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdx75-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdx75-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdx75-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-2])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ adsp_ext, atest_char, audio_ref_clk, bimc_dte, char_exec, coex_uart2,
+ coex_uart, cri_trng, cri_trng0, cri_trng1, dbg_out_clk, ddr_bist,
+ ddr_pxi0, ebi0_wrcdc, ebi2_a, ebi2_lcd, ebi2_lcd_te, emac0_mcg,
+ emac0_ptp, emac1_mcg, emac1_ptp, emac_cdc, emac_pps_in, eth0_mdc,
+ eth0_mdio, eth1_mdc, eth1_mdio, ext_dbg, gcc_125_clk, gcc_gp1_clk,
+ gcc_gp2_clk, gcc_gp3_clk, gcc_plltest, gpio, i2s_mclk, jitter_bist,
+ ldo_en, ldo_update, m_voc, mgpi_clk, native_char, native_tsens,
+ native_tsense, nav_dr_sync, nav_gpio, pa_indicator, pci_e,
+ pcie0_clkreq_n, pcie1_clkreq_n, pcie2_clkreq_n, pll_bist_sync,
+ pll_clk_aux, pll_ref_clk, pri_mi2s, prng_rosc, qdss_cti, qdss_gpio,
+ qlink0_b_en, qlink0_b_req, qlink0_l_en, qlink0_l_req, qlink0_wmss,
+ qlink1_l_en, qlink1_l_req, qlink1_wmss, qup_se0, qup_se1_l2_mira,
+ qup_se1_l2_mirb, qup_se1_l3_mira, qup_se1_l3_mirb, qup_se2, qup_se3,
+ qup_se4, qup_se5, qup_se6, qup_se7, qup_se8, rgmii_rx_ctl, rgmii_rxc,
+ rgmii_rxd, rgmii_tx_ctl, rgmii_txc, rgmii_txd, sd_card, sdc1_tb,
+ sdc2_tb_trig, sec_mi2s, sgmii_phy_intr0_n, sgmii_phy_intr1_n,
+ spmi_coex, spmi_vgi, tgu_ch0_trigout, tmess_prng0, tmess_prng1,
+ tmess_prng2, tmess_prng3, tri_mi2s, uim1_clk, uim1_data, uim1_present,
+ uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset,
+ usb2phy_ac_en, vsense_trigger_mirnat]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,sdx75-tlmm";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 133>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio12";
+ function = "qup_se1_l2_mira";
+ bias-disable;
+ };
+
+ tx-pins {
+ pins = "gpio13";
+ function = "qup_se1_l3_mira";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml
index a57d44e..ede0f3a 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml
@@ -62,6 +62,7 @@
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
$ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -102,19 +103,9 @@
wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk,
wsa_data ]
- bias-pull-down: true
- bias-pull-up: true
- bias-disable: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
required:
- pins
- additionalProperties: false
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
index 1ab0f8d..2120ef7 100644
--- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
@@ -27,6 +27,8 @@
- st,stm32mp135-pinctrl
- st,stm32mp157-pinctrl
- st,stm32mp157-z-pinctrl
+ - st,stm32mp257-pinctrl
+ - st,stm32mp257-z-pinctrl
'#address-cells':
const: 1
@@ -56,7 +58,7 @@
Indicates the SOC package used.
More details in include/dt-bindings/pinctrl/stm32-pinfunc.h
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2, 4, 8]
+ enum: [0x1, 0x2, 0x4, 0x8, 0x100, 0x400, 0x800]
patternProperties:
'^gpio@[0-9a-f]*$':
diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml
index 598a042..b85f9e3 100644
--- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml
@@ -7,7 +7,7 @@
title: Xilinx Zynq Pinctrl
maintainers:
- - Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
+ - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
description: |
Please refer to pinctrl-bindings.txt in this directory for details of the
diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
index 2722dc7..24ad061 100644
--- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -7,8 +7,7 @@
title: Xilinx ZynqMP Pinctrl
maintainers:
- - Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
- - Rajan Vaja <rajan.vaja@xilinx.com>
+ - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
description: |
Please refer to pinctrl-bindings.txt in this directory for details of the
diff --git a/Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml b/Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml
new file mode 100644
index 0000000..f559a2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/atmel,at91sam9260-shdwc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip AT91 SHDWC Shutdown Controller
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description: |
+ Microchip AT91 SHDWC shutdown controller controls the power supplies VDDIO
+ and VDDCORE and the wake-up detection on debounced input lines.
+
+properties:
+ compatible:
+ enum:
+ - atmel,at91sam9260-shdwc
+ - atmel,at91sam9rl-shdwc
+ - atmel,at91sam9x5-shdwc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ atmel,wakeup-mode:
+ description: operation mode of the wakeup mode
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ none, high, low, any ]
+
+ atmel,wakeup-counter:
+ description: counter on wake-up 0
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+
+ atmel,wakeup-rtt-timer:
+ description: enable real-time timer wake-up
+ type: boolean
+
+ atmel,wakeup-rtc-timer:
+ description: enable real-time clock wake-up
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,at91sam9x5-shdwc
+ then:
+ properties:
+ atmel,wakeup-rtt-timer: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,at91sam9260-shdwc
+ then:
+ properties:
+ atmel,wakeup-rtc-timer: false
+
+additionalProperties: false
+
+examples:
+ - |
+ shdwc: poweroff@fffffd10 {
+ compatible = "atmel,at91sam9260-shdwc";
+ reg = <0xfffffd10 0x10>;
+ clocks = <&clk32k>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml
new file mode 100644
index 0000000..8c58e12
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/atmel,sama5d2-shdwc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip AT91 SAMA5D2 SHDWC Shutdown Controller
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description: |
+ Microchip AT91 SHDWC shutdown controller controls the power supplies VDDIO
+ and VDDCORE and the wake-up detection on debounced input lines.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: microchip,sama7g5-shdwc
+ - const: syscon
+ - enum:
+ - atmel,sama5d2-shdwc
+ - microchip,sam9x60-shdwc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ debounce-delay-us:
+ description:
+ Minimum wake-up inputs debouncer period in microseconds. It is usually a
+ board-related property.
+
+ atmel,wakeup-rtc-timer:
+ description: enable real-time clock wake-up
+ type: boolean
+
+ atmel,wakeup-rtt-timer:
+ description: enable real-time timer wake-up
+ type: boolean
+
+patternProperties:
+ "^input@[0-15]$":
+ description:
+ Wake-up input nodes. These are usually described in the "board" part of
+ the Device Tree. Note also that input 0 is linked to the wake-up pin and
+ is frequently used.
+ type: object
+ properties:
+ reg:
+ description: contains the wake-up input index
+ minimum: 0
+ maximum: 15
+
+ atmel,wakeup-active-high:
+ description:
+ The corresponding wake-up input described by the child forces the
+ wake-up of the core power supply on a high level. The default is to
+ be active low.
+ type: boolean
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,sama5d2-shdwc
+ then:
+ properties:
+ atmel,wakeup-rtt-timer: false
+
+additionalProperties: false
+
+examples:
+ - |
+ shdwc: poweroff@f8048010 {
+ compatible = "atmel,sama5d2-shdwc";
+ reg = <0xf8048010 0x10>;
+ clocks = <&clk32k>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ atmel,wakeup-rtc-timer;
+ debounce-delay-us = <976>;
+
+ input@0 {
+ reg = <0>;
+ };
+
+ input@1 {
+ reg = <1>;
+ atmel,wakeup-active-high;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt b/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt
deleted file mode 100644
index 93f31ca..0000000
--- a/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Broadcom Kona Family Reset Manager
-----------------------------------
-
-The reset manager is used on the Broadcom BCM21664 SoC.
-
-Required properties:
- - compatible: brcm,bcm21664-resetmgr
- - reg: memory address & range
-
-Example:
- brcm,resetmgr@35001f00 {
- compatible = "brcm,bcm21664-resetmgr";
- reg = <0x35001f00 0x24>;
- };
diff --git a/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml b/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml
new file mode 100644
index 0000000..3e28a59
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/brcm,bcm21664-resetmgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family reset manager
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,bcm21664-resetmgr
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ reset-controller@35001f00 {
+ compatible = "brcm,bcm21664-resetmgr";
+ reg = <0x35001f00 0x24>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt
deleted file mode 100644
index 752d612..0000000
--- a/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-NVMEM reboot mode driver
-
-This driver gets reboot mode magic value from reboot-mode driver
-and stores it in a NVMEM cell named "reboot-mode". Then the bootloader
-can read it and take different action according to the magic
-value stored.
-
-Required properties:
-- compatible: should be "nvmem-reboot-mode".
-- nvmem-cells: A phandle to the reboot mode provided by a nvmem device.
-- nvmem-cell-names: Should be "reboot-mode".
-
-The rest of the properties should follow the generic reboot-mode description
-found in reboot-mode.txt
-
-Example:
- reboot-mode {
- compatible = "nvmem-reboot-mode";
- nvmem-cells = <&reboot_mode>;
- nvmem-cell-names = "reboot-mode";
-
- mode-normal = <0xAAAA5501>;
- mode-bootloader = <0xBBBB5500>;
- mode-recovery = <0xCCCC5502>;
- mode-test = <0xDDDD5503>;
- };
diff --git a/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml
new file mode 100644
index 0000000..14a262b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/nvmem-reboot-mode.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic NVMEM reboot mode
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description:
+ This driver gets the reboot mode magic value from the reboot-mode driver
+ and stores it in the NVMEM cell named "reboot-mode". The bootloader can
+ then read it and take different action according to the value.
+
+properties:
+ compatible:
+ const: nvmem-reboot-mode
+
+ nvmem-cells:
+ description:
+ A phandle pointing to the nvmem-cells node where the vendor-specific
+ magic value representing the reboot mode is stored.
+ maxItems: 1
+
+ nvmem-cell-names:
+ items:
+ - const: reboot-mode
+
+patternProperties:
+ "^mode-.+":
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Vendor-specific mode value written to the mode register
+
+required:
+ - compatible
+ - nvmem-cells
+ - nvmem-cell-names
+
+additionalProperties: false
+
+examples:
+ - |
+ reboot-mode {
+ compatible = "nvmem-reboot-mode";
+ nvmem-cells = <&reboot_reason>;
+ nvmem-cell-names = "reboot-mode";
+ mode-recovery = <0x01>;
+ mode-bootloader = <0x02>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
index d96170e..5e46012 100644
--- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
+++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
@@ -19,6 +19,7 @@
compatible:
enum:
- qcom,pm8916-pon
+ - qcom,pm8941-pon
- qcom,pms405-pon
- qcom,pm8998-pon
- qcom,pmk8350-pon
@@ -56,7 +57,6 @@
unevaluatedProperties: false
allOf:
- - $ref: reboot-mode.yaml#
- if:
properties:
compatible:
@@ -66,12 +66,30 @@
- qcom,pms405-pon
- qcom,pm8998-pon
then:
+ allOf:
+ - $ref: reboot-mode.yaml#
+
properties:
reg:
maxItems: 1
reg-names:
items:
- const: pon
+
+ # Special case for pm8941, which doesn't store reset mode
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,pm8941-pon
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ reg-names:
+ items:
+ - const: pon
+
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
index 1f9a2aa..f2ffdd2 100644
--- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
+++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/reset/restart-handler.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Restart and shutdown handler generic binding
+title: Restart and shutdown handler Common Properties
maintainers:
- Sebastian Reichel <sre@kernel.org>
diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
index 11f1f98..45792e2 100644
--- a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
@@ -7,7 +7,7 @@
title: Xilinx Zynq MPSoC Power Management
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
description: |
The zynqmp-power node describes the power management configurations.
diff --git a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
index 82f382a..4fe9c370 100644
--- a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
@@ -68,11 +68,29 @@
Interrupt sends an active low, 256 μs pulse to host to report the charger
device status and faults.
+ ti,no-thermistor:
+ type: boolean
+ description: Indicates that no thermistor is connected to the TS pin
+
required:
- compatible
- reg
- monitored-battery
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,bq25600
+ - ti,bq25601
+ - ti,bq25600d
+ - ti,bq25601d
+ then:
+ properties:
+ ti,no-thermistor: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml
new file mode 100644
index 0000000..277c47e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/qcom,pmi8998-charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PMI8998/PM660 Switch-Mode Battery Charger "2"
+
+maintainers:
+ - Caleb Connolly <caleb.connolly@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - qcom,pmi8998-charger
+ - qcom,pm660-charger
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 4
+
+ interrupt-names:
+ items:
+ - const: usb-plugin
+ - const: bat-ov
+ - const: wdog-bark
+ - const: usbin-icl-change
+
+ io-channels:
+ items:
+ - description: USB in current in uA
+ - description: USB in voltage in uV
+
+ io-channel-names:
+ items:
+ - const: usbin_i
+ - const: usbin_v
+
+ monitored-battery:
+ description: phandle to the simple-battery node
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - io-channels
+ - io-channel-names
+ - monitored-battery
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #interrupt-cells = <4>;
+
+ charger@1000 {
+ compatible = "qcom,pmi8998-charger";
+ reg = <0x1000>;
+
+ interrupts = <0x2 0x12 0x2 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x13 0x4 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x13 0x6 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x16 0x1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "usb-plugin", "bat-ov", "wdog-bark", "usbin-icl-change";
+
+ io-channels = <&pmi8998_rradc 3>,
+ <&pmi8998_rradc 4>;
+ io-channel-names = "usbin_i",
+ "usbin_v";
+
+ monitored-battery = <&battery>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml
index 756c16d..b5d8888 100644
--- a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml
@@ -26,7 +26,7 @@
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
new file mode 100644
index 0000000..5b3edd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/richtek,rt5033-charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT5033 PMIC Battery Charger
+
+maintainers:
+ - Jakob Hauser <jahau@rocketmail.com>
+
+description:
+ The battery charger of the multifunction device RT5033 has to be instantiated
+ under sub-node named "charger" using the following format.
+
+properties:
+ compatible:
+ const: richtek,rt5033-charger
+
+ monitored-battery:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Phandle to the monitored battery according to battery.yaml. The battery
+ node needs to contain five parameters.
+
+ precharge-current-microamp:
+ Current of pre-charge mode. The pre-charge current levels are 350 mA
+ to 650 mA programmed by I2C per 100 mA.
+
+ constant-charge-current-max-microamp:
+ Current of fast-charge mode. The fast-charge current levels are 700 mA
+ to 2000 mA programmed by I2C per 100 mA.
+
+ charge-term-current-microamp:
+ This property is end of charge current. Its level ranges from 150 mA
+ to 600 mA. Between 150 mA and 300 mA in 50 mA steps, between 300 mA and
+ 600 mA in 100 mA steps.
+
+ precharge-upper-limit-microvolt:
+ Voltage of pre-charge mode. If the battery voltage is below the pre-charge
+ threshold voltage, the charger is in pre-charge mode with pre-charge
+ current. Its levels are 2.3 V to 3.8 V programmed by I2C per 0.1 V.
+
+ constant-charge-voltage-max-microvolt:
+ Battery regulation voltage of constant voltage mode. This voltage levels
+ from 3.65 V to 4.4 V by I2C per 0.025 V.
+
+ richtek,usb-connector:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to a USB connector according to usb-connector.yaml. The connector
+ should be a child of the extcon device.
+
+required:
+ - monitored-battery
+
+additionalProperties: false
+
+examples:
+ - |
+ charger {
+ compatible = "richtek,rt5033-charger";
+ monitored-battery = <&battery>;
+ richtek,usb-connector = <&usb_con>;
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml
index 3ce648d..34b7959 100644
--- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml
+++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml
@@ -22,6 +22,7 @@
compatible:
oneOf:
- enum:
+ - x-powers,axp192-usb-power-supply
- x-powers,axp202-usb-power-supply
- x-powers,axp221-usb-power-supply
- x-powers,axp223-usb-power-supply
diff --git a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml
index ab45df8..d84268b 100644
--- a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml
@@ -11,7 +11,7 @@
- Claudiu Beznea <claudiu.beznea@microchip.com>
allOf:
- - $ref: "pwm.yaml#"
+ - $ref: pwm.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
index b3da4e6..c01dff3 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
@@ -43,6 +43,7 @@
- fsl,imx8mn-pwm
- fsl,imx8mp-pwm
- fsl,imx8mq-pwm
+ - fsl,imx8qxp-pwm
- const: fsl,imx27-pwm
reg:
@@ -61,6 +62,9 @@
interrupts:
maxItems: 1
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
index 8e176ba..0fbe8a6 100644
--- a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
@@ -22,6 +22,7 @@
- mediatek,mt7623-pwm
- mediatek,mt7628-pwm
- mediatek,mt7629-pwm
+ - mediatek,mt7981-pwm
- mediatek,mt7986-pwm
- mediatek,mt8183-pwm
- mediatek,mt8365-pwm
diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
index 0088bc8..153e146d 100644
--- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
+++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
@@ -22,7 +22,9 @@
- mediatek,mt8173-disp-pwm
- mediatek,mt8183-disp-pwm
- items:
- - const: mediatek,mt8167-disp-pwm
+ - enum:
+ - mediatek,mt6795-disp-pwm
+ - mediatek,mt8167-disp-pwm
- const: mediatek,mt8173-disp-pwm
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml
index a34cbc1..6ffbed2 100644
--- a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml
@@ -25,7 +25,7 @@
const: 3
fsl,pwm-number:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the number of PWM devices
required:
diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
deleted file mode 100644
index f5753b3..0000000
--- a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-BCM2835 PWM controller (Raspberry Pi controller)
-
-Required properties:
-- compatible: should be "brcm,bcm2835-pwm"
-- reg: physical base address and length of the controller's registers
-- clocks: This clock defines the base clock frequency of the PWM hardware
- system, the period and the duty_cycle of the PWM signal is a multiple of
- the base period.
-- #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of
- the cells format.
-
-Examples:
-
-pwm@2020c000 {
- compatible = "brcm,bcm2835-pwm";
- reg = <0x2020c000 0x28>;
- clocks = <&clk_pwm>;
- #pwm-cells = <3>;
-};
-
-clocks {
- ....
- clk_pwm: pwm {
- compatible = "fixed-clock";
- reg = <3>;
- #clock-cells = <0>;
- clock-frequency = <9200000>;
- };
- ....
-};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml
new file mode 100644
index 0000000..15e7fd9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-bcm2835.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BCM2835 PWM controller (Raspberry Pi controller)
+
+maintainers:
+ - Stefan Wahren <stefan.wahren@i2se.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: brcm,bcm2835-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#pwm-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm@2020c000 {
+ compatible = "brcm,bcm2835-pwm";
+ reg = <0x2020c000 0x28>;
+ clocks = <&clk_pwm>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml
index 3c01f85..abd9fa8 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm.yaml
@@ -13,7 +13,7 @@
properties:
$nodename:
- pattern: "^pwm(@.*|-[0-9a-f])*$"
+ pattern: "^pwm(@.*|-([0-9]|[1-9][0-9]+))?$"
"#pwm-cells":
description:
diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
index 4c80970..6b6a302 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
+++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
@@ -35,6 +35,7 @@
- renesas,pwm-r8a77980 # R-Car V3H
- renesas,pwm-r8a77990 # R-Car E3
- renesas,pwm-r8a77995 # R-Car D3
+ - renesas,pwm-r8a779a0 # R-Car V3U
- renesas,pwm-r8a779g0 # R-Car V4H
- const: renesas,pwm-rcar
diff --git a/Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml b/Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml
new file mode 100644
index 0000000..9e36d54
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/adi,max77541-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Buck Converter for MAX77540/MAX77541
+
+maintainers:
+ - Okan Sahin <okan.sahin@analog.com>
+
+description: |
+ This is a part of device tree bindings for ADI MAX77540/MAX77541
+
+ The buck converter is represented as a sub-node of the PMIC node on the device tree.
+
+ The device has two buck regulators.
+ See also Documentation/devicetree/bindings/mfd/adi,max77541.yaml for
+ additional information and example.
+
+patternProperties:
+ "^buck[12]$":
+ type: object
+ $ref: regulator.yaml#
+ additionalProperties: false
+ description: |
+ Buck regulator.
+
+ properties:
+ regulator-name: true
+ regulator-always-on: true
+ regulator-boot-on: true
+ regulator-min-microvolt:
+ minimum: 300000
+ regulator-max-microvolt:
+ maximum: 5200000
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
index 7034cdc..b638430 100644
--- a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
@@ -8,15 +8,14 @@
The valid names for regulators are::
BUCK:
- buck_vdram1, buck_vcore, buck_vcore_sshub, buck_vpa, buck_vproc11,
- buck_vproc12, buck_vgpu, buck_vs2, buck_vmodem, buck_vs1
+ buck_vdram1, buck_vcore, buck_vpa, buck_vproc11, buck_vproc12, buck_vgpu,
+ buck_vs2, buck_vmodem, buck_vs1
LDO:
ldo_vdram2, ldo_vsim1, ldo_vibr, ldo_vrf12, ldo_vio18, ldo_vusb, ldo_vcamio,
ldo_vcamd, ldo_vcn18, ldo_vfe28, ldo_vsram_proc11, ldo_vcn28, ldo_vsram_others,
- ldo_vsram_others_sshub, ldo_vsram_gpu, ldo_vxo22, ldo_vefuse, ldo_vaux18,
- ldo_vmch, ldo_vbif28, ldo_vsram_proc12, ldo_vcama1, ldo_vemc, ldo_vio28, ldo_va12,
- ldo_vrf18, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_vcama2, ldo_vmc, ldo_vldo28, ldo_vaud28,
- ldo_vsim2
+ ldo_vsram_gpu, ldo_vxo22, ldo_vefuse, ldo_vaux18, ldo_vmch, ldo_vbif28,
+ ldo_vsram_proc12, ldo_vcama1, ldo_vemc, ldo_vio28, ldo_va12, ldo_vrf18,
+ ldo_vcn33, ldo_vcama2, ldo_vmc, ldo_vldo28, ldo_vaud28, ldo_vsim2
Example:
@@ -305,15 +304,8 @@
regulator-enable-ramp-delay = <120>;
};
- mt6358_vcn33_bt_reg: ldo_vcn33_bt {
- regulator-name = "vcn33_bt";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3500000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vcn33_wifi_reg: ldo_vcn33_wifi {
- regulator-name = "vcn33_wifi";
+ mt6358_vcn33_reg: ldo_vcn33 {
+ regulator-name = "vcn33";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3500000>;
regulator-enable-ramp-delay = <270>;
@@ -354,17 +346,5 @@
regulator-max-microvolt = <3100000>;
regulator-enable-ramp-delay = <540>;
};
-
- mt6358_vcore_sshub_reg: buck_vcore_sshub {
- regulator-name = "vcore_sshub";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- };
-
- mt6358_vsram_others_sshub_reg: ldo_vsram_others_sshub {
- regulator-name = "vsram_others_sshub";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- };
};
};
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.yaml b/Documentation/devicetree/bindings/regulator/pfuze100.yaml
index 67a30b2..e384e49 100644
--- a/Documentation/devicetree/bindings/regulator/pfuze100.yaml
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.yaml
@@ -36,6 +36,9 @@
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
fsl,pfuze-support-disable-sw:
$ref: /schemas/types.yaml#/definitions/flag
description: |
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml b/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml
index 7e58471..80ecf93 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml
@@ -64,6 +64,7 @@
defined, <100> is assumed, meaning that
pwm-dutycycle-range contains values expressed in
percent.
+ $ref: /schemas/types.yaml#/definitions/uint32
default: 100
pwm-dutycycle-range:
diff --git a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
index b1cff3a..89c564d 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -14,6 +14,9 @@
regulator will be enabled in situations where the device is required to
provide power to the connected peripheral.
+allOf:
+ - $ref: regulator.yaml#
+
properties:
compatible:
enum:
@@ -25,8 +28,11 @@
required:
- compatible
+ - reg
+ - regulator-min-microamp
+ - regulator-max-microamp
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -36,6 +42,8 @@
pm8150b_vbus: usb-vbus-regulator@1100 {
compatible = "qcom,pm8150b-vbus-reg";
reg = <0x1100>;
+ regulator-min-microamp = <500000>;
+ regulator-max-microamp = <3000000>;
};
};
...
diff --git a/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml b/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml
new file mode 100644
index 0000000..97cff71
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/renesas,raa215300.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RAA215300 Power Management Integrated Circuit (PMIC)
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ The RAA215300 is a high-performance, low-cost 9-channel PMIC designed for
+ 32-bit and 64-bit MCU and MPU applications. It supports DDR3, DDR3L, DDR4,
+ and LPDDR4 memory power requirements. The internally compensated regulators,
+ built-in Real-Time Clock (RTC), 32kHz crystal oscillator, and coin cell
+ battery charger provide a highly integrated, small footprint power solution
+ ideal for System-On-Module (SOM) applications. A spread spectrum feature
+ provides an ease-of-use solution for noise-sensitive audio or RF applications.
+
+ This device exposes two devices via I2C. One for the integrated RTC IP, and
+ one for everything else.
+
+ Link to datasheet:
+ https://www.renesas.com/in/en/products/power-power-management/multi-channel-power-management-ics-pmics/ssdsoc-power-management-ics-pmic-and-pmus/raa215300-high-performance-9-channel-pmic-supporting-ddr-memory-built-charger-and-rtc
+
+properties:
+ compatible:
+ enum:
+ - renesas,raa215300
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: main
+ - const: rtc
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description: |
+ The clocks are optional. The RTC is disabled, if no clocks are
+ provided(either xin or clkin).
+ maxItems: 1
+
+ clock-names:
+ description: |
+ Use xin, if connected to an external crystal.
+ Use clkin, if connected to an external clock signal.
+ enum:
+ - xin
+ - clkin
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ /* 32.768kHz crystal */
+ x2: x2-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ raa215300: pmic@12 {
+ compatible = "renesas,raa215300";
+ reg = <0x12>, <0x6f>;
+ reg-names = "main", "rtc";
+
+ clocks = <&x2>;
+ clock-names = "xin";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62870.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62870.yaml
new file mode 100644
index 0000000..3869895
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ti,tps62870.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/ti,tps62870.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TPS62870/TPS62871/TPS62872/TPS62873 voltage regulator
+
+maintainers:
+ - Mårten Lindahl <marten.lindahl@axis.com>
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,tps62870
+ - ti,tps62871
+ - ti,tps62872
+ - ti,tps62873
+
+ reg:
+ maxItems: 1
+
+ regulator-initial-mode:
+ enum: [ 1, 2 ]
+ description: 1 - Forced PWM mode, 2 - Low power mode
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@41 {
+ compatible = "ti,tps62873";
+ reg = <0x41>;
+ regulator-name = "+0.75V";
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1675000>;
+ regulator-initial-mode = <1>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
index 3100cb8..76e8ca4 100644
--- a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
@@ -75,7 +75,7 @@
examples:
- |
remoteproc@1c {
- compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
+ compatible = "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
reg = <0x1c 0x8>, <0x38 0x8>;
reg-names = "remap", "cpu";
resets = <&media_cpu_reset>;
diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
index 959a56f..370af61 100644
--- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
@@ -25,7 +25,14 @@
maxItems: 3
resets:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: mcu_rst
+ - const: hold_boot
+ minItems: 1
st,syscfg-holdboot:
description: remote processor reset hold boot
@@ -37,6 +44,7 @@
- description: The field mask of the hold boot
st,syscfg-tz:
+ deprecated: true
description:
Reference to the system configuration which holds the RCC trust zone mode
$ref: /schemas/types.yaml#/definitions/phandle-array
@@ -135,22 +143,48 @@
- compatible
- reg
- resets
- - st,syscfg-holdboot
- - st,syscfg-tz
+
+allOf:
+ - if:
+ properties:
+ reset-names:
+ not:
+ contains:
+ const: hold_boot
+ then:
+ required:
+ - st,syscfg-holdboot
+ else:
+ properties:
+ st,syscfg-holdboot: false
additionalProperties: false
examples:
- |
#include <dt-bindings/reset/stm32mp1-resets.h>
- m4_rproc: m4@10000000 {
+ m4@10000000 {
compatible = "st,stm32mp1-m4";
reg = <0x10000000 0x40000>,
<0x30000000 0x40000>,
<0x38000000 0x10000>;
resets = <&rcc MCU_R>;
+ reset-names = "mcu_rst";
+ /* Hold boot managed using system config*/
st,syscfg-holdboot = <&rcc 0x10C 0x1>;
- st,syscfg-tz = <&rcc 0x000 0x1>;
+ st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
+ st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
+ };
+ - |
+ #include <dt-bindings/reset/stm32mp1-resets.h>
+ m4@10000000 {
+ compatible = "st,stm32mp1-m4";
+ reg = <0x10000000 0x40000>,
+ <0x30000000 0x40000>,
+ <0x38000000 0x10000>;
+ /* Hold boot managed using SCMI reset controller */
+ resets = <&scmi MCU_R>, <&scmi MCU_HOLD_BOOT_R>;
+ reset-names = "mcu_rst", "hold_boot";
st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
};
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
index c6d8696..35f0bb3 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common TI PRU Consumer Binding
+title: TI PRU Consumer Common Properties
maintainers:
- Suman Anna <s-anna@ti.com>
diff --git a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
index 05b6648..851ec24 100644
--- a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/reserved-memory/framebuffer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: /reserved-memory framebuffer node bindings
+title: /reserved-memory framebuffer node
maintainers:
- devicetree-spec@vger.kernel.org
diff --git a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
new file mode 100644
index 0000000..34c5c1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 Reset Controller
+
+maintainers:
+ - Chi-Fang Li <cfli0@nuvoton.com>
+ - Jacky Huang <ychuang3@nuvoton.com>
+
+description:
+ The system reset controller can be used to reset various peripheral
+ controllers in MA35D1 SoC.
+
+properties:
+ compatible:
+ items:
+ - const: nuvoton,ma35d1-reset
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ # system reset controller node:
+ - |
+
+ system-management@40460000 {
+ compatible = "nuvoton,ma35d1-reset";
+ reg = <0x40460000 0x200>;
+ #reset-cells = <1>;
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/reset/oxnas,reset.txt b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
deleted file mode 100644
index d27ccb5..0000000
--- a/Documentation/devicetree/bindings/reset/oxnas,reset.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Oxford Semiconductor OXNAS SoC Family RESET Controller
-================================================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required properties:
-- compatible: For OX810SE, should be "oxsemi,ox810se-reset"
- For OX820, should be "oxsemi,ox820-reset"
-- #reset-cells: 1, see below
-
-Parent node should have the following properties :
-- compatible: For OX810SE, should be :
- "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
- For OX820, should be :
- "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
-
-Reset indices are in dt-bindings include files :
-- For OX810SE: include/dt-bindings/reset/oxsemi,ox810se.h
-- For OX820: include/dt-bindings/reset/oxsemi,ox820.h
-
-example:
-
-sys: sys-ctrl@000000 {
- compatible = "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd";
- reg = <0x000000 0x100000>;
-
- reset: reset-controller {
- compatible = "oxsemi,ox810se-reset";
- #reset-cells = <1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
deleted file mode 100644
index ed83686..0000000
--- a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
+++ /dev/null
@@ -1,55 +0,0 @@
---------------------------------------------------------------------------
- = Zynq UltraScale+ MPSoC and Versal reset driver binding =
---------------------------------------------------------------------------
-The Zynq UltraScale+ MPSoC and Versal has several different resets.
-
-See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information
-about zynqmp resets.
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required Properties:
-- compatible: "xlnx,zynqmp-reset" for Zynq UltraScale+ MPSoC platform
- "xlnx,versal-reset" for Versal platform
-- #reset-cells: Specifies the number of cells needed to encode reset
- line, should be 1
-
--------
-Example
--------
-
-firmware {
- zynqmp_firmware: zynqmp-firmware {
- compatible = "xlnx,zynqmp-firmware";
- method = "smc";
-
- zynqmp_reset: reset-controller {
- compatible = "xlnx,zynqmp-reset";
- #reset-cells = <1>;
- };
- };
-};
-
-Specifying reset lines connected to IP modules
-==============================================
-
-Device nodes that need access to reset lines should
-specify them as a reset phandle in their corresponding node as
-specified in reset.txt.
-
-For list of all valid reset indices for Zynq UltraScale+ MPSoC see
-<dt-bindings/reset/xlnx-zynqmp-resets.h>
-For list of all valid reset indices for Versal see
-<dt-bindings/reset/xlnx-versal-resets.h>
-
-Example:
-
-serdes: zynqmp_phy@fd400000 {
- ...
-
- resets = <&zynqmp_reset ZYNQMP_RESET_SATA>;
- reset-names = "sata_rst";
-
- ...
-};
diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml
new file mode 100644
index 0000000..0d50f6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/xlnx,zynqmp-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zynq UltraScale+ MPSoC and Versal reset
+
+maintainers:
+ - Piyush Mehta <piyush.mehta@amd.com>
+
+description: |
+ The Zynq UltraScale+ MPSoC and Versal has several different resets.
+
+ The PS reset subsystem is responsible for handling the external reset
+ input to the device and that all internal reset requirements are met
+ for the system (as a whole) and for the functional units.
+
+ Please also refer to reset.txt in this directory for common reset
+ controller binding usage. Device nodes that need access to reset
+ lines should specify them as a reset phandle in their corresponding
+ node as specified in reset.txt.
+
+ For list of all valid reset indices for Zynq UltraScale+ MPSoC
+ <dt-bindings/reset/xlnx-zynqmp-resets.h>
+
+ For list of all valid reset indices for Versal
+ <dt-bindings/reset/xlnx-versal-resets.h>
+
+properties:
+ compatible:
+ enum:
+ - xlnx,zynqmp-reset
+ - xlnx,versal-reset
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ zynqmp_reset: reset-controller {
+ compatible = "xlnx,zynqmp-reset";
+ #reset-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index 3d2934b..38c0b52 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -23,6 +23,10 @@
two cores, each of which has two hyperthreads, could be described as
having four harts.
+allOf:
+ - $ref: /schemas/cpu.yaml#
+ - $ref: extensions.yaml
+
properties:
compatible:
oneOf:
@@ -61,7 +65,7 @@
hart. These values originate from the RISC-V Privileged
Specification document, available from
https://riscv.org/specifications/
- $ref: "/schemas/types.yaml#/definitions/string"
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- riscv,sv32
- riscv,sv39
@@ -79,25 +83,9 @@
description:
The blocksize in bytes for the Zicboz cache operations.
- riscv,isa:
- description:
- Identifies the specific RISC-V instruction set architecture
- supported by the hart. These are documented in the RISC-V
- User-Level ISA document, available from
- https://riscv.org/specifications/
-
- Due to revisions of the ISA specification, some deviations
- have arisen over time.
- Notably, riscv,isa was defined prior to the creation of the
- Zicsr and Zifencei extensions and thus "i" implies
- "zicsr_zifencei".
-
- While the isa strings in ISA specification are case
- insensitive, letters in the riscv,isa string must be all
- lowercase to simplify parsing.
- $ref: "/schemas/types.yaml#/definitions/string"
- pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$
-
+ # RISC-V has multiple properties for cache op block sizes as the sizes
+ # differ between individual CBO extensions
+ cache-op-block-size: false
# RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
timebase-frequency: false
@@ -120,7 +108,7 @@
- interrupt-controller
cpu-idle-states:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
maxItems: 1
description: |
@@ -133,11 +121,20 @@
DMIPS/MHz, relative to highest capacity-dmips-mhz
in the system.
+anyOf:
+ - required:
+ - riscv,isa
+ - required:
+ - riscv,isa-base
+
+dependencies:
+ riscv,isa-base: [ "riscv,isa-extensions" ]
+ riscv,isa-extensions: [ "riscv,isa-base" ]
+
required:
- - riscv,isa
- interrupt-controller
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
@@ -154,7 +151,9 @@
i-cache-sets = <128>;
i-cache-size = <16384>;
reg = <0>;
- riscv,isa = "rv64imac";
+ riscv,isa-base = "rv64i";
+ riscv,isa-extensions = "i", "m", "a", "c";
+
cpu_intc0: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
@@ -177,8 +176,10 @@
i-tlb-size = <32>;
mmu-type = "riscv,sv39";
reg = <1>;
- riscv,isa = "rv64imafdc";
tlb-split;
+ riscv,isa-base = "rv64i";
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
+
cpu_intc1: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
@@ -196,8 +197,10 @@
device_type = "cpu";
reg = <0>;
compatible = "riscv";
- riscv,isa = "rv64imafdc";
mmu-type = "riscv,sv48";
+ riscv,isa-base = "rv64i";
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
+
interrupt-controller {
#interrupt-cells = <1>;
interrupt-controller;
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
new file mode 100644
index 0000000..cc1f546
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -0,0 +1,250 @@
+# SPDX-License-Identifier: (GPL-2.0 OR MIT)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/extensions.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V ISA extensions
+
+maintainers:
+ - Paul Walmsley <paul.walmsley@sifive.com>
+ - Palmer Dabbelt <palmer@sifive.com>
+ - Conor Dooley <conor@kernel.org>
+
+description: |
+ RISC-V has a large number of extensions, some of which are "standard"
+ extensions, meaning they are ratified by RISC-V International, and others
+ are "vendor" extensions.
+ This document defines properties that indicate whether a hart supports a
+ given extension.
+
+ Once a standard extension has been ratified, no changes in behaviour can be
+ made without the creation of a new extension.
+ The properties for standard extensions therefore map to their originally
+ ratified states, with the exception of the I, Zicntr & Zihpm extensions.
+ See the "i" property for more information.
+
+select:
+ properties:
+ compatible:
+ contains:
+ const: riscv
+
+properties:
+ riscv,isa:
+ description:
+ Identifies the specific RISC-V instruction set architecture
+ supported by the hart. These are documented in the RISC-V
+ User-Level ISA document, available from
+ https://riscv.org/specifications/
+
+ Due to revisions of the ISA specification, some deviations
+ have arisen over time.
+ Notably, riscv,isa was defined prior to the creation of the
+ Zicntr, Zicsr, Zifencei and Zihpm extensions and thus "i"
+ implies "zicntr_zicsr_zifencei_zihpm".
+
+ While the isa strings in ISA specification are case
+ insensitive, letters in the riscv,isa string must be all
+ lowercase.
+ $ref: /schemas/types.yaml#/definitions/string
+ pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$
+ deprecated: true
+
+ riscv,isa-base:
+ description:
+ The base ISA implemented by this hart, as described by the 20191213
+ version of the unprivileged ISA specification.
+ enum:
+ - rv32i
+ - rv64i
+
+ riscv,isa-extensions:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ minItems: 1
+ description: Extensions supported by the hart.
+ items:
+ anyOf:
+ # single letter extensions, in canonical order
+ - const: i
+ description: |
+ The base integer instruction set, as ratified in the 20191213
+ version of the unprivileged ISA specification.
+
+ This does not include Chapter 10, "Counters", which was moved into
+ the Zicntr and Zihpm extensions after the ratification of the
+ 20191213 version of the unprivileged specification.
+
+ - const: m
+ description:
+ The standard M extension for integer multiplication and division, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: a
+ description:
+ The standard A extension for atomic instructions, as ratified in the
+ 20191213 version of the unprivileged ISA specification.
+
+ - const: f
+ description:
+ The standard F extension for single-precision floating point, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: d
+ description:
+ The standard D extension for double-precision floating-point, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: q
+ description:
+ The standard Q extension for quad-precision floating-point, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: c
+ description:
+ The standard C extension for compressed instructions, as ratified in
+ the 20191213 version of the unprivileged ISA specification.
+
+ - const: v
+ description:
+ The standard V extension for vector operations, as ratified
+ in-and-around commit 7a6c8ae ("Fix text that describes vfmv.v.f
+ encoding") of the riscv-v-spec.
+
+ - const: h
+ description:
+ The standard H extension for hypervisors as ratified in the 20191213
+ version of the privileged ISA specification.
+
+ # multi-letter extensions, sorted alphanumerically
+ - const: smaia
+ description: |
+ The standard Smaia supervisor-level extension for the advanced
+ interrupt architecture for machine-mode-visible csr and behavioural
+ changes to interrupts as frozen at commit ccbddab ("Merge pull
+ request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
+
+ - const: ssaia
+ description: |
+ The standard Ssaia supervisor-level extension for the advanced
+ interrupt architecture for supervisor-mode-visible csr and
+ behavioural changes to interrupts as frozen at commit ccbddab
+ ("Merge pull request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
+
+ - const: sscofpmf
+ description: |
+ The standard Sscofpmf supervisor-level extension for count overflow
+ and mode-based filtering as ratified at commit 01d1df0 ("Add ability
+ to manually trigger workflow. (#2)") of riscv-count-overflow.
+
+ - const: sstc
+ description: |
+ The standard Sstc supervisor-level extension for time compare as
+ ratified at commit 3f9ed34 ("Add ability to manually trigger
+ workflow. (#2)") of riscv-time-compare.
+
+ - const: svinval
+ description:
+ The standard Svinval supervisor-level extension for fine-grained
+ address-translation cache invalidation as ratified in the 20191213
+ version of the privileged ISA specification.
+
+ - const: svnapot
+ description:
+ The standard Svnapot supervisor-level extensions for napot
+ translation contiguity as ratified in the 20191213 version of the
+ privileged ISA specification.
+
+ - const: svpbmt
+ description:
+ The standard Svpbmt supervisor-level extensions for page-based
+ memory types as ratified in the 20191213 version of the privileged
+ ISA specification.
+
+ - const: zba
+ description: |
+ The standard Zba bit-manipulation extension for address generation
+ acceleration instructions as ratified at commit 6d33919 ("Merge pull
+ request #158 from hirooih/clmul-fix-loop-end-condition") of
+ riscv-bitmanip.
+
+ - const: zbb
+ description: |
+ The standard Zbb bit-manipulation extension for basic bit-manipulation
+ as ratified at commit 6d33919 ("Merge pull request #158 from
+ hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+
+ - const: zbc
+ description: |
+ The standard Zbc bit-manipulation extension for carry-less
+ multiplication as ratified at commit 6d33919 ("Merge pull request
+ #158 from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+
+ - const: zbs
+ description: |
+ The standard Zbs bit-manipulation extension for single-bit
+ instructions as ratified at commit 6d33919 ("Merge pull request #158
+ from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+
+ - const: zicbom
+ description:
+ The standard Zicbom extension for base cache management operations as
+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+
+ - const: zicbop
+ description:
+ The standard Zicbop extension for cache-block prefetch instructions
+ as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of
+ riscv-CMOs.
+
+ - const: zicboz
+ description:
+ The standard Zicboz extension for cache-block zeroing as ratified
+ in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+
+ - const: zicntr
+ description:
+ The standard Zicntr extension for base counters and timers, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: zicsr
+ description: |
+ The standard Zicsr extension for control and status register
+ instructions, as ratified in the 20191213 version of the
+ unprivileged ISA specification.
+
+ This does not include Chapter 10, "Counters", which documents
+ special case read-only CSRs, that were moved into the Zicntr and
+ Zihpm extensions after the ratification of the 20191213 version of
+ the unprivileged specification.
+
+ - const: zifencei
+ description:
+ The standard Zifencei extension for instruction-fetch fence, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: zihintpause
+ description:
+ The standard Zihintpause extension for pause hints, as ratified in
+ commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual.
+
+ - const: zihpm
+ description:
+ The standard Zihpm extension for hardware performance counters, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: ztso
+ description:
+ The standard Ztso extension for total store ordering, as ratified
+ in commit 2e5236 ("Ztso is now ratified.") of the
+ riscv-isa-manual.
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/riscv/thead.yaml b/Documentation/devicetree/bindings/riscv/thead.yaml
new file mode 100644
index 0000000..e62f682
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/thead.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/thead.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-HEAD SoC-based boards
+
+maintainers:
+ - Jisheng Zhang <jszhang@kernel.org>
+
+description:
+ T-HEAD SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Sipeed Lichee Pi 4A board for the Sipeed Lichee Module 4A
+ items:
+ - enum:
+ - sipeed,lichee-pi-4a
+ - const: sipeed,lichee-module-4a
+ - const: thead,th1520
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl1208.txt b/Documentation/devicetree/bindings/rtc/isil,isl1208.txt
deleted file mode 100644
index 51f0030..0000000
--- a/Documentation/devicetree/bindings/rtc/isil,isl1208.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Intersil ISL1209/19 I2C RTC/Alarm chip with event in
-
-ISL12X9 have additional pins EVIN and #EVDET for tamper detection, while the
-ISL1208 and ISL1218 do not. They are all use the same driver with the bindings
-described here, with chip specific properties as noted.
-
-Required properties supported by the device:
- - "compatible": Should be one of the following:
- - "isil,isl1208"
- - "isil,isl1209"
- - "isil,isl1218"
- - "isil,isl1219"
- - "reg": I2C bus address of the device
-
-Optional properties:
- - "interrupt-names": list which may contains "irq" and "evdet"
- evdet applies to isl1209 and isl1219 only
- - "interrupts": list of interrupts for "irq" and "evdet"
- evdet applies to isl1209 and isl1219 only
- - "isil,ev-evienb": Enable or disable internal pull on EVIN pin
- Applies to isl1209 and isl1219 only
- Possible values are 0 and 1
- Value 0 enables internal pull-up on evin pin, 1 disables it.
- Default will leave the non-volatile configuration of the pullup
- as is.
-
-Example isl1219 node with #IRQ pin connected to SoC gpio1 pin12 and #EVDET pin
-connected to SoC gpio2 pin 24 and internal pull-up enabled in EVIN pin.
-
- isl1219: rtc@68 {
- compatible = "isil,isl1219";
- reg = <0x68>;
- interrupt-names = "irq", "evdet";
- interrupts-extended = <&gpio1 12 IRQ_TYPE_EDGE_FALLING>,
- <&gpio2 24 IRQ_TYPE_EDGE_FALLING>;
- isil,ev-evienb = <1>;
- };
-
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl1208.yaml b/Documentation/devicetree/bindings/rtc/isil,isl1208.yaml
new file mode 100644
index 0000000..11f7378
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/isil,isl1208.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/isil,isl1208.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intersil ISL1209/19 I2C RTC/Alarm chip with event in
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+ - Trent Piepho <tpiepho@gmail.com>
+
+description:
+ ISL12X9 have additional pins EVIN and EVDET for tamper detection, while the
+ ISL1208 and ISL1218 do not.
+
+properties:
+ compatible:
+ enum:
+ - isil,isl1208
+ - isil,isl1209
+ - isil,isl1218
+ - isil,isl1219
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description: |
+ Use xin, if connected to an external crystal.
+ Use clkin, if connected to an external clock signal.
+ enum:
+ - xin
+ - clkin
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: irq
+ - const: evdet
+
+ isil,ev-evienb:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: |
+ Enable or disable internal pull on EVIN pin
+ Default will leave the non-volatile configuration of the pullup
+ as is.
+ <0> : Enables internal pull-up on evin pin
+ <1> : Disables internal pull-up on evin pin
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: rtc.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - isil,isl1209
+ - isil,isl1219
+ then:
+ properties:
+ interrupts:
+ maxItems: 2
+ interrupt-names:
+ items:
+ - const: irq
+ - const: evdet
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+ interrupt-names:
+ items:
+ - const: irq
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc_twi: rtc@6f {
+ compatible = "isil,isl1208";
+ reg = <0x6f>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
new file mode 100644
index 0000000..f89c1f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/loongson,rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson Real-Time Clock
+
+description:
+ The Loongson family chips use an on-chip counter 0 (Time Of Year
+ counter) as the RTC.
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - loongson,ls1b-rtc
+ - loongson,ls1c-rtc
+ - loongson,ls7a-rtc
+ - loongson,ls2k1000-rtc
+ - items:
+ - enum:
+ - loongson,ls2k2000-rtc
+ - loongson,ls2k0500-rtc
+ - const: loongson,ls7a-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ rtc@1fe27800 {
+ compatible = "loongson,ls2k1000-rtc";
+ reg = <0x1fe27800 0x100>;
+
+ interrupt-parent = <&liointc1>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml
index c6fff54..efb66df 100644
--- a/Documentation/devicetree/bindings/rtc/rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/rtc.yaml
@@ -15,7 +15,7 @@
properties:
$nodename:
- pattern: "^rtc(@.*|-[0-9a-f])*$"
+ pattern: "^rtc(@.*|-([0-9]|[1-9][0-9]+))?$"
aux-voltage-chargeable:
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index a3603e6..9af77f2 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -47,8 +47,6 @@
- isil,isl1218
# Intersil ISL12022 Real-time Clock
- isil,isl12022
- # Loongson-2K Socs/LS7A bridge Real-time Clock
- - loongson,ls2x-rtc
# Real Time Clock Module with I2C-Bus
- microcrystal,rv3029
# Real Time Clock
diff --git a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml
index 7ed0230..d1f5eb99 100644
--- a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml
@@ -11,7 +11,7 @@
The RTC controller has separate IRQ lines for seconds and alarm.
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
allOf:
- $ref: rtc.yaml#
diff --git a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
index 30b2131..65cb2e5 100644
--- a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
+++ b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
@@ -16,7 +16,6 @@
- enum:
- atmel,at91rm9200-usart
- atmel,at91sam9260-usart
- - microchip,sam9x60-usart
- items:
- const: atmel,at91rm9200-dbgu
- const: atmel,at91rm9200-usart
@@ -24,6 +23,9 @@
- const: atmel,at91sam9260-dbgu
- const: atmel,at91sam9260-usart
- items:
+ - const: microchip,sam9x60-usart
+ - const: atmel,at91sam9260-usart
+ - items:
- const: microchip,sam9x60-dbgu
- const: microchip,sam9x60-usart
- const: atmel,at91sam9260-dbgu
diff --git a/Documentation/devicetree/bindings/serial/cavium-uart.txt b/Documentation/devicetree/bindings/serial/cavium-uart.txt
deleted file mode 100644
index 87a6c37..0000000
--- a/Documentation/devicetree/bindings/serial/cavium-uart.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* Universal Asynchronous Receiver/Transmitter (UART)
-
-- compatible: "cavium,octeon-3860-uart"
-
- Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
-
-- reg: The base address of the UART register bank.
-
-- interrupts: A single interrupt specifier.
-
-- current-speed: Optional, the current bit rate in bits per second.
-
-Example:
- uart1: serial@1180000000c00 {
- compatible = "cavium,octeon-3860-uart","ns16550";
- reg = <0x11800 0x00000c00 0x0 0x400>;
- current-speed = <115200>;
- interrupts = <0 35>;
- };
diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
index a8b323d..e35ad11 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
@@ -7,7 +7,7 @@
title: Cadence UART Controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml b/Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml
new file mode 100644
index 0000000..a76af0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/nuvoton,ma35d1-serial.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 Universal Asynchronous Receiver/Transmitter (UART)
+
+maintainers:
+ - Min-Jen Chen <mjchen@nuvoton.com>
+ - Jacky Huang <ychuang3@nuvoton.com>
+
+allOf:
+ - $ref: serial.yaml
+
+properties:
+ compatible:
+ const: nuvoton,ma35d1-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+
+ serial@40700000 {
+ compatible = "nuvoton,ma35d1-uart";
+ reg = <0x40700000 0x100>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk UART0_GATE>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt b/Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt
deleted file mode 100644
index 04e23e6..0000000
--- a/Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* NXP LPC1850 UART
-
-Required properties:
-- compatible : "nxp,lpc1850-uart", "ns16550a".
-- reg : offset and length of the register set for the device.
-- interrupts : should contain uart interrupt.
-- clocks : phandle to the input clocks.
-- clock-names : required elements: "uartclk", "reg".
-
-Optional properties:
-- dmas : Two or more DMA channel specifiers following the
- convention outlined in bindings/dma/dma.txt
-- dma-names : Names for the dma channels, if present. There must
- be at least one channel named "tx" for transmit
- and named "rx" for receive.
-
-Since it's also possible to also use the of_serial.c driver all
-parameters from 8250.txt also apply but are optional.
-
-Example:
-uart0: serial@40081000 {
- compatible = "nxp,lpc1850-uart", "ns16550a";
- reg = <0x40081000 0x1000>;
- reg-shift = <2>;
- interrupts = <24>;
- clocks = <&ccu2 CLK_APB0_UART0>, <&ccu1 CLK_CPU_UART0>;
- clock-names = "uartclk", "reg";
-};
diff --git a/Documentation/devicetree/bindings/slimbus/slimbus.yaml b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
index 22513fb..3b8cae9 100644
--- a/Documentation/devicetree/bindings/slimbus/slimbus.yaml
+++ b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
@@ -15,7 +15,7 @@
properties:
$nodename:
- pattern: "^slim(@.*|-[0-9a-f])*$"
+ pattern: "^slim(@.*|-([0-9]|[1-9][0-9]+))?$"
"#address-cells":
const: 2
diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml
new file mode 100644
index 0000000..1a952f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/bcm/brcm,bcm23550-cdc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM23550 Cluster Dormant Control
+
+description:
+ The Cluster Dormant Control block keeps the CPU in idle state. A command
+ needs to be sent to this block to bring the CPU into running state.
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,bcm23550-cdc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ cdc@3fe0e000 {
+ compatible = "brcm,bcm23550-cdc";
+ reg = <0x3fe0e000 0x78>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
index 3fefd63..a06ac21 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
@@ -33,6 +33,7 @@
- mediatek,mt2701-pwrap
- mediatek,mt6765-pwrap
- mediatek,mt6779-pwrap
+ - mediatek,mt6795-pwrap
- mediatek,mt6797-pwrap
- mediatek,mt6873-pwrap
- mediatek,mt7622-pwrap
diff --git a/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml
new file mode 100644
index 0000000..23e7e4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/nuvoton/nuvoton,npcm-gcr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Global Control Registers block in Nuvoton SoCs
+
+maintainers:
+ - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
+ - Tomer Maimon <tmaimon77@gmail.com>
+
+description:
+ The Global Control Registers (GCR) are a block of registers in Nuvoton SoCs
+ that expose misc functionality such as chip model and version information or
+ pinmux settings.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nuvoton,wpcm450-gcr
+ - nuvoton,npcm750-gcr
+ - nuvoton,npcm845-gcr
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties:
+ type: object
+
+examples:
+ - |
+ gcr: syscon@800000 {
+ compatible = "nuvoton,npcm750-gcr", "syscon", "simple-mfd";
+ reg = <0x800000 0x1000>;
+
+ mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x38 0x07>;
+ idle-states = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
index 798f155..9dc8e48 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
@@ -26,6 +26,7 @@
items:
- enum:
- qcom,qdu1000-aoss-qmp
+ - qcom,sa8775p-aoss-qmp
- qcom,sc7180-aoss-qmp
- qcom,sc7280-aoss-qmp
- qcom,sc8180x-aoss-qmp
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
index 14dd294..f2c5ec7 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
@@ -55,9 +55,10 @@
examples:
- |
eud@88e0000 {
- compatible = "qcom,sc7280-eud","qcom,eud";
+ compatible = "qcom,sc7280-eud", "qcom,eud";
reg = <0x88e0000 0x2000>,
<0x88e2000 0x1000>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -67,6 +68,7 @@
remote-endpoint = <&usb2_role_switch>;
};
};
+
port@1 {
reg = <1>;
eud_con: endpoint {
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml
new file mode 100644
index 0000000..0318009
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,rpm-master-stats.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. (QTI) RPM Master Stats
+
+maintainers:
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+
+description: |
+ The Qualcomm RPM (Resource Power Manager) architecture includes a concept
+ of "RPM Masters". They can be thought of as "the local gang leaders", usually
+ spanning a single subsystem (e.g. APSS, ADSP, CDSP). All of the RPM decisions
+ (particularly around entering hardware-driven low power modes: XO shutdown
+ and total system-wide power collapse) are first made at Master-level, and
+ only then aggregated for the entire system.
+
+ The Master Stats provide a few useful bits that can be used to assess whether
+ our device has entered the desired low-power mode, how long it took to do so,
+ the duration of that residence, how long it took to come back online,
+ how many times a given sleep state was entered and which cores are actively
+ voting for staying awake.
+
+ This scheme has been used on various SoCs in the 2013-2023 era, with some
+ newer or higher-end designs providing this information through an SMEM query.
+
+properties:
+ compatible:
+ const: qcom,rpm-master-stats
+
+ qcom,rpm-msg-ram:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: Phandle to an RPM MSG RAM slice containing the master stats
+ minItems: 1
+ maxItems: 5
+
+ qcom,master-names:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ The name of the RPM Master which owns the MSG RAM slice where this
+ instance of Master Stats resides
+ minItems: 1
+ maxItems: 5
+
+required:
+ - compatible
+ - qcom,rpm-msg-ram
+ - qcom,master-names
+
+additionalProperties: false
+
+examples:
+ - |
+ stats {
+ compatible = "qcom,rpm-master-stats";
+ qcom,rpm-msg-ram = <&apss_master_stats>,
+ <&mpss_master_stats>,
+ <&adsp_master_stats>,
+ <&cdsp_master_stats>,
+ <&tz_master_stats>;
+ qcom,master-names = "APSS",
+ "MPSS",
+ "ADSP",
+ "CDSP",
+ "TZ";
+ };
+...
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
index a4046ba..af632d0 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
@@ -124,6 +124,7 @@
- qcom,tcs-offset
- reg
- reg-names
+ - power-domains
additionalProperties: false
@@ -179,6 +180,7 @@
<SLEEP_TCS 1>,
<WAKE_TCS 1>,
<CONTROL_TCS 0>;
+ power-domains = <&CLUSTER_PD>;
};
- |
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
index ea86569..65c02a7 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
@@ -81,6 +81,7 @@
contains:
enum:
- qcom,rpm-apq8084
+ - qcom,rpm-msm8226
- qcom,rpm-msm8916
- qcom,rpm-msm8936
- qcom,rpm-msm8974
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml
index 7ab8cff..96a7f18 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Technologies, Inc. (QTI) Stats
maintainers:
- - Maulik Shah <mkshah@codeaurora.org>
+ - Maulik Shah <quic_mkshah@quicinc.com>
description:
Always On Processor/Resource Power Manager maintains statistics of the SoC
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 65a2d5a..e4fa6a0 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -24,6 +24,7 @@
- rockchip,rk3588-bigcore1-grf
- rockchip,rk3588-ioc
- rockchip,rk3588-php-grf
+ - rockchip,rk3588-pipe-phy-grf
- rockchip,rk3588-sys-grf
- rockchip,rk3588-pcie3-phy-grf
- rockchip,rk3588-pcie3-pipe-grf
@@ -52,6 +53,7 @@
- rockchip,rk3399-pmugrf
- rockchip,rk3568-grf
- rockchip,rk3568-pmugrf
+ - rockchip,rk3588-usb2phy-grf
- rockchip,rv1108-grf
- rockchip,rv1108-pmugrf
- rockchip,rv1126-grf
@@ -119,7 +121,7 @@
usbphy:
type: object
- $ref: "/schemas/phy/rockchip-usb-phy.yaml#"
+ $ref: /schemas/phy/rockchip-usb-phy.yaml#
unevaluatedProperties: false
@@ -134,14 +136,14 @@
gpio:
type: object
- $ref: "/schemas/gpio/rockchip,rk3328-grf-gpio.yaml#"
+ $ref: /schemas/gpio/rockchip,rk3328-grf-gpio.yaml#
unevaluatedProperties: false
power-controller:
type: object
- $ref: "/schemas/power/rockchip,power-controller.yaml#"
+ $ref: /schemas/power/rockchip,power-controller.yaml#
unevaluatedProperties: false
@@ -156,7 +158,7 @@
mipi-dphy-rx0:
type: object
- $ref: "/schemas/phy/rockchip-mipi-dphy-rx0.yaml#"
+ $ref: /schemas/phy/rockchip-mipi-dphy-rx0.yaml#
unevaluatedProperties: false
@@ -184,7 +186,7 @@
reboot-mode:
type: object
- $ref: "/schemas/power/reset/syscon-reboot-mode.yaml#"
+ $ref: /schemas/power/reset/syscon-reboot-mode.yaml#
unevaluatedProperties: false
@@ -199,6 +201,7 @@
- rockchip,rk3308-usb2phy-grf
- rockchip,rk3328-usb2phy-grf
- rockchip,rk3399-grf
+ - rockchip,rk3588-usb2phy-grf
- rockchip,rv1108-grf
then:
@@ -238,7 +241,7 @@
io-domains:
type: object
- $ref: "/schemas/power/rockchip-io-domain.yaml#"
+ $ref: /schemas/power/rockchip-io-domain.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index 5d8d949..e1d716d 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -17,6 +17,7 @@
enum:
- samsung,exynos3250-pmu
- samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
- samsung,exynos4412-pmu
- samsung,exynos5250-pmu
- samsung,exynos5260-pmu
@@ -36,6 +37,7 @@
- enum:
- samsung,exynos3250-pmu
- samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
- samsung,exynos4412-pmu
- samsung,exynos5250-pmu
- samsung,exynos5260-pmu
@@ -50,6 +52,7 @@
- enum:
- samsung,exynos3250-pmu
- samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
- samsung,exynos4412-pmu
- samsung,exynos5250-pmu
- samsung,exynos5420-pmu
@@ -125,6 +128,7 @@
enum:
- samsung,exynos3250-pmu
- samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
- samsung,exynos4412-pmu
- samsung,exynos5250-pmu
- samsung,exynos5410-pmu
@@ -143,6 +147,7 @@
enum:
- samsung,exynos3250-pmu
- samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
- samsung,exynos4412-pmu
- samsung,exynos5250-pmu
- samsung,exynos5420-pmu
diff --git a/Documentation/devicetree/bindings/sound/adi,max98388.yaml b/Documentation/devicetree/bindings/sound/adi,max98388.yaml
new file mode 100644
index 0000000..93ccd59
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,max98388.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,max98388.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX98388 Speaker Amplifier
+
+maintainers:
+ - Ryan Lee <ryans.lee@analog.com>
+
+description:
+ The MAX98388 is a mono Class-D speaker amplifier with I/V feedback.
+ The device provides a PCM interface for audio data and a standard
+ I2C interface for control data communication.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,max98388
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ adi,vmon-slot-no:
+ description: slot number of the voltage feedback monitor
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ default: 0
+
+ adi,imon-slot-no:
+ description: slot number of the current feedback monitor
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ default: 1
+
+ adi,interleave-mode:
+ description:
+ For cases where a single combined channel for the I/V feedback data
+ is not sufficient, the device can also be configured to share
+ a single data output channel on alternating frames.
+ In this configuration, the current and voltage data will be frame
+ interleaved on a single output channel.
+ type: boolean
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ max98388: amplifier@39 {
+ compatible = "adi,max98388";
+ reg = <0x39>;
+ #sound-dai-cells = <0>;
+ adi,vmon-slot-no = <0>;
+ adi,imon-slot-no = <1>;
+ adi,interleave-mode;
+ reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml b/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml
new file mode 100644
index 0000000..f3f3254
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,ssm2518.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices SSM2518 audio amplifier
+
+maintainers:
+ - Lars-Peter Clausen <lars@metafoo.de>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: adi,ssm2518
+
+ reg:
+ maxItems: 1
+ description: |
+ I2C address of the device. This will either be 0x34 (ADDR pin low)
+ or 0x35 (ADDR pin high)
+
+ gpios:
+ maxItems: 1
+ description: |
+ GPIO connected to the nSD pin. If the property is not present
+ it is assumed that the nSD pin is hardwired to always on.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@34 {
+ compatible = "adi,ssm2518";
+ reg = <0x34>;
+ gpios = <&gpio 5 0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/adi,ssm3515.yaml b/Documentation/devicetree/bindings/sound/adi,ssm3515.yaml
new file mode 100644
index 0000000..144450d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,ssm3515.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,ssm3515.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices SSM3515 Audio Amplifier
+
+maintainers:
+ - Martin Povišer <povik+lin@cutebit.org>
+
+description: |
+ SSM3515 is a mono Class-D audio amplifier with digital input.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/SSM3515.pdf
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,ssm3515
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@14 {
+ compatible = "adi,ssm3515";
+ reg = <0x14>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "Left Tweeter";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml
index 3de7b36..d3ce4de 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml
@@ -39,22 +39,4 @@
additionalProperties: false
-examples:
- - |
- sound {
- compatible = "audio-graph-card2";
-
- links = <&cpu_port>;
- };
-
- cpu {
- compatible = "cpu-driver";
-
- cpu_port: port { cpu_ep: endpoint { remote-endpoint = <&codec_ep>; }; };
- };
-
- codec {
- compatible = "codec-driver";
-
- port { codec_ep: endpoint { remote-endpoint = <&cpu_ep>; }; };
- };
+...
diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
index c87eb91..ed31e04 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
@@ -24,7 +24,11 @@
connection's sink, the second being the connection's source.
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
widgets:
- description: User specified audio sound widgets.
+ description: |
+ User specified audio sound widgets.
+ Each entry is a pair of strings, the first being the type of
+ widget ("Microphone", "Line", "Headphone", "Speaker"), the
+ second being the machine specific name for the widget.
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
convert-rate:
$ref: /schemas/sound/dai-params.yaml#/$defs/dai-sample-rate
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml
index 2ab74f9..4c9acb8 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml
@@ -62,7 +62,7 @@
GPIO pin direction. Valid only when 'gpio-ctrl' is 1
0 = Output
1 = Input
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1
default: 1
@@ -71,7 +71,7 @@
GPIO level. Valid only when 'gpio-ctrl' is 1 and 'gpio-dir' is 0
0 = Low
1 = High
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1
default: 0
@@ -80,7 +80,7 @@
GPIO level. Valid only when 'gpio-ctrl' is 1 and 'gpio-dir' is 0
0 = CMOS
1 = Open Drain
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1
default: 0
@@ -90,7 +90,7 @@
and 'gpio-dir' is 0
0 = Non-inverted, Active High
1 = Inverted, Active Low
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1
default: 0
@@ -114,7 +114,7 @@
0 = High impedance input
1 = Pin acts as a GPIO, direction controlled by 'gpio-dir'
2-7 = Reserved
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 7
default: 0
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml
index 670b67e..f7bafbd 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml
@@ -44,6 +44,10 @@
VAHP-supply:
description: phandle to voltage regulator of headphone
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -69,6 +73,13 @@
VA-supply = <®_audio>;
VAHP-supply = <®_audio>;
reset-gpios = <&gpiog 9 GPIO_ACTIVE_LOW>;
+
+ /* assume audio-graph */
+ port {
+ cpu_endpoint: endpoint {
+ remote-endpoint = <&cpu_endpoint>;
+ };
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/sound/da7219.txt b/Documentation/devicetree/bindings/sound/da7219.txt
deleted file mode 100644
index add1caf..0000000
--- a/Documentation/devicetree/bindings/sound/da7219.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-Dialog Semiconductor DA7219 Audio Codec bindings
-
-DA7219 is an audio codec with advanced accessory detect features.
-
-======
-
-Required properties:
-- compatible : Should be "dlg,da7219"
-- reg: Specifies the I2C slave address
-
-- interrupts : IRQ line info for DA7219.
- (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
- further information relating to interrupt properties)
-
-- VDD-supply: VDD power supply for the device
-- VDDMIC-supply: VDDMIC power supply for the device
-- VDDIO-supply: VDDIO power supply for the device
- (See Documentation/devicetree/bindings/regulator/regulator.txt for further
- information relating to regulators)
-
-Optional properties:
-- interrupt-names : Name associated with interrupt line. Should be "wakeup" if
- interrupt is to be used to wake system, otherwise "irq" should be used.
-- wakeup-source: Flag to indicate this device can wake system (suspend/resume).
-
-- #clock-cells : Should be set to '<1>', two clock sources provided;
-- clock-output-names : Names given for DAI clock outputs (WCLK & BCLK);
-
-- clocks : phandle and clock specifier for codec MCLK.
-- clock-names : Clock name string for 'clocks' attribute, should be "mclk".
-
-- dlg,micbias-lvl : Voltage (mV) for Mic Bias
- [<1600>, <1800>, <2000>, <2200>, <2400>, <2600>]
-- dlg,mic-amp-in-sel : Mic input source type
- ["diff", "se_p", "se_n"]
-
-Deprecated properties:
-- dlg,ldo-lvl : Required internal LDO voltage (mV) level for digital engine
- (LDO unavailable in production HW so property no longer required).
-
-======
-
-Child node - 'da7219_aad':
-
-Optional properties:
-- dlg,micbias-pulse-lvl : Mic bias higher voltage pulse level (mV).
- [<2800>, <2900>]
-- dlg,micbias-pulse-time : Mic bias higher voltage pulse duration (ms)
-- dlg,btn-cfg : Periodic button press measurements for 4-pole jack (ms)
- [<2>, <5>, <10>, <50>, <100>, <200>, <500>]
-- dlg,mic-det-thr : Impedance threshold for mic detection measurement (Ohms)
- [<200>, <500>, <750>, <1000>]
-- dlg,jack-ins-deb : Debounce time for jack insertion (ms)
- [<5>, <10>, <20>, <50>, <100>, <200>, <500>, <1000>]
-- dlg,jack-det-rate: Jack type detection latency (3/4 pole)
- ["32ms_64ms", "64ms_128ms", "128ms_256ms", "256ms_512ms"]
-- dlg,jack-rem-deb : Debounce time for jack removal (ms)
- [<1>, <5>, <10>, <20>]
-- dlg,a-d-btn-thr : Impedance threshold between buttons A and D
- [0x0 - 0xFF]
-- dlg,d-b-btn-thr : Impedance threshold between buttons D and B
- [0x0 - 0xFF]
-- dlg,b-c-btn-thr : Impedance threshold between buttons B and C
- [0x0 - 0xFF]
-- dlg,c-mic-btn-thr : Impedance threshold between button C and Mic
- [0x0 - 0xFF]
-- dlg,btn-avg : Number of 8-bit readings for averaged button measurement
- [<1>, <2>, <4>, <8>]
-- dlg,adc-1bit-rpt : Repeat count for 1-bit button measurement
- [<1>, <2>, <4>, <8>]
-
-======
-
-Example:
-
- codec: da7219@1a {
- compatible = "dlg,da7219";
- reg = <0x1a>;
-
- interrupt-parent = <&gpio6>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
-
- VDD-supply = <®_audio>;
- VDDMIC-supply = <®_audio>;
- VDDIO-supply = <®_audio>;
-
- #clock-cells = <1>;
- clock-output-names = "dai-wclk", "dai-bclk";
-
- clocks = <&clks 201>;
- clock-names = "mclk";
-
- dlg,ldo-lvl = <1200>;
- dlg,micbias-lvl = <2600>;
- dlg,mic-amp-in-sel = "diff";
-
- da7219_aad {
- dlg,btn-cfg = <50>;
- dlg,mic-det-thr = <500>;
- dlg,jack-ins-deb = <20>;
- dlg,jack-det-rate = "32ms_64ms";
- dlg,jack-rem-deb = <1>;
-
- dlg,a-d-btn-thr = <0xa>;
- dlg,d-b-btn-thr = <0x16>;
- dlg,b-c-btn-thr = <0x21>;
- dlg,c-mic-btn-thr = <0x3E>;
-
- dlg,btn-avg = <4>;
- dlg,adc-1bit-rpt = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/dialog,da7219.yaml b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
new file mode 100644
index 0000000..bb5af48
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
@@ -0,0 +1,237 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/dialog,da7219.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog Semiconductor DA7219 Audio Codec
+
+maintainers:
+ - David Rau <David.Rau.opensource@dm.renesas.com>
+
+description:
+ The DA7219 is an ultra low-power audio codec with
+ in-built advanced accessory detection (AAD) for mobile
+ computing and accessory applications, which supports
+ sample rates up to 96 kHz at 24-bit resolution.
+
+properties:
+ compatible:
+ const: dlg,da7219
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ VDD-supply:
+ description:
+ VDD power supply for the device.
+
+ VDDMIC-supply:
+ description:
+ VDDMIC power supply for the device.
+
+ VDDIO-supply:
+ description:
+ VDDIO power supply for the device.
+
+ interrupt-names:
+ description:
+ Should be "wakeup" if interrupt is to be used to wake system,
+ otherwise "irq" should be used.
+ enum:
+ - wakeup
+ - irq
+
+ wakeup-source:
+ type: boolean
+ description:
+ Flag to indicate this device can wake system (suspend/resume).
+
+ "#clock-cells":
+ const: 1
+
+ clock-output-names:
+ minItems: 2
+ maxItems: 2
+ description:
+ Name given for DAI WCLK and BCLK outputs.
+
+ clocks:
+ maxItems: 1
+ description:
+ phandle and clock specifier for codec MCLK.
+
+ clock-names:
+ const: mclk
+
+ dlg,micbias-lvl:
+ enum: [1600, 1800, 2000, 2200, 2400, 2600]
+ description:
+ Voltage (mV) for Mic Bias.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,mic-amp-in-sel:
+ enum: ["diff", "se_p", "se_n"]
+ description:
+ Mic input source type.
+
+ diff - Differential.
+
+ se_p - MIC_P.
+ Positive differential analog microphone input.
+
+ se_n - MIC_N.
+ Negative differential analog microphone input.
+ $ref: /schemas/types.yaml#/definitions/string
+
+ da7219_aad:
+ type: object
+ description:
+ Configuration of advanced accessory detection.
+ properties:
+ dlg,micbias-pulse-lvl:
+ enum: [2800, 2900]
+ description:
+ Mic bias higher voltage pulse level (mV).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,micbias-pulse-time:
+ description:
+ Mic bias higher voltage pulse duration (ms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+
+ dlg,btn-cfg:
+ enum: [2, 5, 10, 50, 100, 200, 500]
+ description:
+ Periodic button press measurements for 4-pole jack (ms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,mic-det-thr:
+ enum: [200, 500, 750, 1000]
+ description:
+ Impedance threshold for mic detection measurement (Ohms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,jack-ins-deb:
+ enum: [5, 10, 20, 50, 100, 200, 500, 1000]
+ description:
+ Debounce time for jack insertion (ms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,jack-ins-det-pty:
+ enum: ["low", "high"]
+ description:
+ Polarity for jack insertion detection.
+ $ref: /schemas/types.yaml#/definitions/string
+
+ dlg,jack-det-rate:
+ enum: ["32_64", "64_128", "128_256", "256_512"]
+ description:
+ Jack type (3/4 pole) detection latency (ms).
+ $ref: /schemas/types.yaml#/definitions/string
+
+ dlg,jack-rem-deb:
+ enum: [1, 5, 10, 20]
+ description:
+ Debounce time for jack removal (ms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,a-d-btn-thr:
+ description:
+ Impedance threshold between buttons A and D.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+
+ dlg,d-b-btn-thr:
+ description:
+ Impedance threshold between buttons D and B.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+
+ dlg,b-c-btn-thr:
+ description:
+ Impedance threshold between buttons B and C.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+
+ dlg,c-mic-btn-thr:
+ description:
+ Impedance threshold between button C and Mic.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+
+ dlg,btn-avg:
+ enum: [1, 2, 4, 8]
+ description:
+ Number of 8-bit readings for averaged button measurement.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,adc-1bit-rpt:
+ enum: [1, 2, 4, 8]
+ description:
+ Repeat count for 1-bit button measurement.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - VDD-supply
+ - VDDMIC-supply
+ - VDDIO-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec: da7219@1a {
+ compatible = "dlg,da7219";
+ reg = <0x1a>;
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+
+ VDD-supply = <&vdd_reg>;
+ VDDMIC-supply = <&vddmic_reg>;
+ VDDIO-supply = <&vddio_reg>;
+
+ #clock-cells = <1>;
+ clock-output-names = "da7219-dai-wclk", "da7219-dai-bclk";
+
+ clocks = <&clks 201>;
+ clock-names = "mclk";
+
+ dlg,micbias-lvl = <2600>;
+ dlg,mic-amp-in-sel = "diff";
+
+ da7219_aad {
+ dlg,btn-cfg = <50>;
+ dlg,mic-det-thr = <500>;
+ dlg,jack-ins-deb = <20>;
+ dlg,jack-ins-det-pty = "low";
+ dlg,jack-det-rate = "32_64";
+ dlg,jack-rem-deb = <1>;
+
+ dlg,a-d-btn-thr = <0xa>;
+ dlg,d-b-btn-thr = <0x16>;
+ dlg,b-c-btn-thr = <0x21>;
+ dlg,c-mic-btn-thr = <0x3E>;
+
+ dlg,btn-avg = <4>;
+ dlg,adc-1bit-rpt = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index 8b4f401..4e8dbc5 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -46,6 +46,8 @@
"fsl,imx-audio-wm8958"
+ "fsl,imx-audio-nau8822"
+
Required properties:
- compatible : Contains one of entries in the compatible list.
diff --git a/Documentation/devicetree/bindings/sound/google,chv3-codec.yaml b/Documentation/devicetree/bindings/sound/google,chv3-codec.yaml
new file mode 100644
index 0000000..5329dc1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/google,chv3-codec.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/google,chv3-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Chameleon v3 audio codec
+
+maintainers:
+ - Paweł Anikiel <pan@semihalf.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: google,chv3-codec
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ audio-codec {
+ compatible = "google,chv3-codec";
+ };
diff --git a/Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml b/Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml
new file mode 100644
index 0000000..3ce910f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/google,chv3-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Chameleon v3 I2S device
+
+maintainers:
+ - Paweł Anikiel <pan@semihalf.com>
+
+description: |
+ I2S device for the Google Chameleon v3. The device handles both RX
+ and TX using a producer/consumer ring buffer design.
+
+properties:
+ compatible:
+ const: google,chv3-i2s
+
+ reg:
+ items:
+ - description: core registers
+ - description: irq registers
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2s@c0060300 {
+ compatible = "google,chv3-i2s";
+ reg = <0xc0060300 0x100>,
+ <0xc0060f00 0x10>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
index 67ccddd..ba5b772 100644
--- a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
+++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
@@ -7,7 +7,7 @@
title: Google SC7180-Trogdor ASoC sound card driver
maintainers:
- - Rohit kumar <rohitkr@codeaurora.org>
+ - Rohit kumar <quic_rohkumar@quicinc.com>
- Cheng-Yi Chiang <cychiang@chromium.org>
description:
@@ -74,7 +74,8 @@
properties:
sound-dai:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
required:
- link-name
diff --git a/Documentation/devicetree/bindings/sound/ingenic,aic.yaml b/Documentation/devicetree/bindings/sound/ingenic,aic.yaml
index c59a7cd..d15c000 100644
--- a/Documentation/devicetree/bindings/sound/ingenic,aic.yaml
+++ b/Documentation/devicetree/bindings/sound/ingenic,aic.yaml
@@ -23,6 +23,7 @@
- ingenic,jz4760-i2s
- ingenic,jz4770-i2s
- ingenic,jz4780-i2s
+ - ingenic,x1000-i2s
- items:
- const: ingenic,jz4725b-i2s
- const: ingenic,jz4740-i2s
diff --git a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
new file mode 100644
index 0000000..61e8bab
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/loongson,ls-audio-card.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson 7axxx/2kxxx ASoC audio sound card driver
+
+maintainers:
+ - Yingkun Meng <mengyingkun@loongson.cn>
+
+description:
+ The binding describes the sound card present in loongson
+ 7axxx/2kxxx platform. The sound card is an ASoC component
+ which uses Loongson I2S controller to transfer the audio data.
+
+properties:
+ compatible:
+ const: loongson,ls-audio-card
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+ mclk-fs:
+ $ref: simple-card.yaml#/definitions/mclk-fs
+
+ cpu:
+ description: Holds subnode which indicates cpu dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ maxItems: 1
+ required:
+ - sound-dai
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ maxItems: 1
+ required:
+ - sound-dai
+
+required:
+ - compatible
+ - model
+ - mclk-fs
+ - cpu
+ - codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "loongson,ls-audio-card";
+ model = "loongson-audio";
+ mclk-fs = <512>;
+
+ cpu {
+ sound-dai = <&i2s>;
+ };
+ codec {
+ sound-dai = <&es8323>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
index 82ccb32..e6cb711 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
@@ -29,6 +29,10 @@
$ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek topckgen controller
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the mediatek infracfg controller
+
power-domains:
maxItems: 1
@@ -52,6 +56,11 @@
- description: mux for i2si1_mck
- description: mux for i2si2_mck
- description: audio 26m clock
+ - description: audio pll1 divide 4
+ - description: audio pll2 divide 4
+ - description: clock divider for iec
+ - description: mux for a2sys clock
+ - description: mux for aud_iec
clock-names:
items:
@@ -63,16 +72,21 @@
- const: apll12_div2
- const: apll12_div3
- const: apll12_div9
- - const: a1sys_hp_sel
- - const: aud_intbus_sel
- - const: audio_h_sel
- - const: audio_local_bus_sel
- - const: dptx_m_sel
- - const: i2so1_m_sel
- - const: i2so2_m_sel
- - const: i2si1_m_sel
- - const: i2si2_m_sel
+ - const: top_a1sys_hp
+ - const: top_aud_intbus
+ - const: top_audio_h
+ - const: top_audio_local_bus
+ - const: top_dptx
+ - const: top_i2so1
+ - const: top_i2so2
+ - const: top_i2si1
+ - const: top_i2si2
- const: adsp_audio_26m
+ - const: apll1_d4
+ - const: apll2_d4
+ - const: apll12_div4
+ - const: top_a2sys
+ - const: top_aud_iec
mediatek,etdm-in1-cowork-source:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -144,6 +158,7 @@
- resets
- reset-names
- mediatek,topckgen
+ - mediatek,infracfg
- power-domains
- clocks
- clock-names
@@ -162,6 +177,7 @@
resets = <&watchdog 14>;
reset-names = "audiosys";
mediatek,topckgen = <&topckgen>;
+ mediatek,infracfg = <&infracfg_ao>;
power-domains = <&spm 13>; //MT8188_POWER_DOMAIN_AUDIO
mediatek,etdm-in2-cowork-source = <2>;
mediatek,etdm-out2-cowork-source = <0>;
@@ -184,7 +200,12 @@
<&topckgen 78>, //CLK_TOP_I2SO2
<&topckgen 79>, //CLK_TOP_I2SI1
<&topckgen 80>, //CLK_TOP_I2SI2
- <&adsp_audio26m 0>; //CLK_AUDIODSP_AUDIO26M
+ <&adsp_audio26m 0>, //CLK_AUDIODSP_AUDIO26M
+ <&topckgen 132>, //CLK_TOP_APLL1_D4
+ <&topckgen 133>, //CLK_TOP_APLL2_D4
+ <&topckgen 183>, //CLK_TOP_APLL12_CK_DIV4
+ <&topckgen 84>, //CLK_TOP_A2SYS
+ <&topckgen 82>; //CLK_TOP_AUD_IEC>;
clock-names = "clk26m",
"apll1",
"apll2",
@@ -193,16 +214,21 @@
"apll12_div2",
"apll12_div3",
"apll12_div9",
- "a1sys_hp_sel",
- "aud_intbus_sel",
- "audio_h_sel",
- "audio_local_bus_sel",
- "dptx_m_sel",
- "i2so1_m_sel",
- "i2so2_m_sel",
- "i2si1_m_sel",
- "i2si2_m_sel",
- "adsp_audio_26m";
+ "top_a1sys_hp",
+ "top_aud_intbus",
+ "top_audio_h",
+ "top_audio_local_bus",
+ "top_dptx",
+ "top_i2so1",
+ "top_i2so2",
+ "top_i2si1",
+ "top_i2si2",
+ "adsp_audio_26m",
+ "apll1_d4",
+ "apll2_d4",
+ "apll12_div4",
+ "top_a2sys",
+ "top_aud_iec";
};
...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
index 6640272..05e532b 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
@@ -11,7 +11,9 @@
properties:
compatible:
- const: mediatek,mt8188-mt6359-evb
+ enum:
+ - mediatek,mt8188-mt6359-evb
+ - mediatek,mt8188-nau8825
model:
$ref: /schemas/types.yaml#/definitions/string
@@ -42,7 +44,6 @@
we are going to update parameters in this node.
items:
enum:
- - ADDA_BE
- DPTX_BE
- ETDM1_IN_BE
- ETDM2_IN_BE
@@ -62,11 +63,28 @@
required:
- sound-dai
+ dai-format:
+ description: audio format.
+ items:
+ enum:
+ - i2s
+ - right_j
+ - left_j
+ - dsp_a
+ - dsp_b
+
+ mediatek,clk-provider:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Indicates dai-link clock master.
+ items:
+ enum:
+ - cpu
+ - codec
+
additionalProperties: false
required:
- link-name
- - codec
additionalProperties: false
@@ -87,7 +105,8 @@
"AIN1", "Headset Mic";
dai-link-0 {
link-name = "ETDM3_OUT_BE";
-
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
codec {
sound-dai = <&hdmi0>;
};
diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml
index 9b40268..9aa65c9 100644
--- a/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml
+++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml
@@ -56,13 +56,9 @@
items:
items:
- description: value for DS line
+ enum: [0, 1]
- description: value for sampling edge
- anyOf:
- - enum:
- - [0, 0]
- - [0, 1]
- - [1, 0]
- - [1, 1]
+ enum: [0, 1]
minItems: 1
maxItems: 4
uniqueItems: true
diff --git a/Documentation/devicetree/bindings/sound/nau8315.txt b/Documentation/devicetree/bindings/sound/nau8315.txt
deleted file mode 100644
index 1cd9451..0000000
--- a/Documentation/devicetree/bindings/sound/nau8315.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Nuvoton NAU8315 Mono Class-D Amplifier
-
-Required properties:
-- compatible : "nuvoton,nau8315"
- "nuvoton,nau8318"
-
-Optional properties:
-- enable-gpios : GPIO specifier for the chip's device enable input(EN) pin.
- If this option is not specified then driver does not manage
- the pin state (e.g. chip is always on).
-
-Example:
-
-#include <dt-bindings/gpio/gpio.h>
-
-nau8315 {
- compatible = "nuvoton,nau8315";
- enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
-};
-
-nau8318 {
- compatible = "nuvoton,nau8318";
- enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nau8540.txt b/Documentation/devicetree/bindings/sound/nau8540.txt
deleted file mode 100644
index 307a765..0000000
--- a/Documentation/devicetree/bindings/sound/nau8540.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-NAU85L40 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "nuvoton,nau8540"
-
- - reg : the I2C address of the device.
-
-Example:
-
-codec: nau8540@1c {
- compatible = "nuvoton,nau8540";
- reg = <0x1c>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nau8810.txt b/Documentation/devicetree/bindings/sound/nau8810.txt
deleted file mode 100644
index 7deaa45..0000000
--- a/Documentation/devicetree/bindings/sound/nau8810.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-NAU8810/NAU8812/NAU8814 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : One of "nuvoton,nau8810" or "nuvoton,nau8812" or
- "nuvoton,nau8814"
-
- - reg : the I2C address of the device.
-
-Example:
-
-codec: nau8810@1a {
- compatible = "nuvoton,nau8810";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nau8824.txt b/Documentation/devicetree/bindings/sound/nau8824.txt
deleted file mode 100644
index e0058b9..0000000
--- a/Documentation/devicetree/bindings/sound/nau8824.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-Nuvoton NAU8824 audio codec
-
-This device supports I2C only.
-
-Required properties:
- - compatible : Must be "nuvoton,nau8824"
-
- - reg : the I2C address of the device. This is either 0x1a (CSB=0) or 0x1b (CSB=1).
-
-Optional properties:
- - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low.
-
- - nuvoton,vref-impedance: VREF Impedance selection
- 0 - Open
- 1 - 25 kOhm
- 2 - 125 kOhm
- 3 - 2.5 kOhm
-
- - nuvoton,micbias-voltage: Micbias voltage level.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,sar-threshold-num: Number of buttons supported
- - nuvoton,sar-threshold: Impedance threshold for each button. Array that contains up to 8 buttons configuration. SAR value is calculated as
- SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R)
- where MICBIAS is configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by 'nuvoton,sar-voltage', R - button impedance.
- Refer datasheet section 10.2 for more information about threshold calculation.
-
- - nuvoton,sar-hysteresis: Button impedance measurement hysteresis.
-
- - nuvoton,sar-voltage: Reference voltage for button impedance measurement.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,sar-compare-time: SAR compare time
- 0 - 500 ns
- 1 - 1 us
- 2 - 2 us
- 3 - 4 us
-
- - nuvoton,sar-sampling-time: SAR sampling time
- 0 - 2 us
- 1 - 4 us
- 2 - 8 us
- 3 - 16 us
-
- - nuvoton,short-key-debounce: Button short key press debounce time.
- 0 - 30 ms
- 1 - 50 ms
- 2 - 100 ms
-
- - nuvoton,jack-eject-debounce: Jack ejection debounce time.
- 0 - 0 ms
- 1 - 1 ms
- 2 - 10 ms
-
-
-Example:
-
- headset: nau8824@1a {
- compatible = "nuvoton,nau8824";
- reg = <0x1a>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(E, 6) IRQ_TYPE_LEVEL_LOW>;
- nuvoton,vref-impedance = <2>;
- nuvoton,micbias-voltage = <6>;
- // Setup 4 buttons impedance according to Android specification
- nuvoton,sar-threshold-num = <4>;
- nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>;
- nuvoton,sar-hysteresis = <0>;
- nuvoton,sar-voltage = <6>;
- nuvoton,sar-compare-time = <1>;
- nuvoton,sar-sampling-time = <1>;
- nuvoton,short-key-debounce = <0>;
- nuvoton,jack-eject-debounce = <1>;
- };
diff --git a/Documentation/devicetree/bindings/sound/nau8825.txt b/Documentation/devicetree/bindings/sound/nau8825.txt
deleted file mode 100644
index a9c3452..0000000
--- a/Documentation/devicetree/bindings/sound/nau8825.txt
+++ /dev/null
@@ -1,111 +0,0 @@
-Nuvoton NAU8825 audio codec
-
-This device supports I2C only.
-
-Required properties:
- - compatible : Must be "nuvoton,nau8825"
-
- - reg : the I2C address of the device. This is either 0x1a (CSB=0) or 0x1b (CSB=1).
-
-Optional properties:
- - nuvoton,jkdet-enable: Enable jack detection via JKDET pin.
- - nuvoton,jkdet-pull-enable: Enable JKDET pin pull. If set - pin pull enabled,
- otherwise pin in high impedance state.
- - nuvoton,jkdet-pull-up: Pull-up JKDET pin. If set then JKDET pin is pull up, otherwise pull down.
- - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low.
-
- - nuvoton,vref-impedance: VREF Impedance selection
- 0 - Open
- 1 - 25 kOhm
- 2 - 125 kOhm
- 3 - 2.5 kOhm
-
- - nuvoton,micbias-voltage: Micbias voltage level.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,sar-threshold-num: Number of buttons supported
- - nuvoton,sar-threshold: Impedance threshold for each button. Array that contains up to 8 buttons configuration. SAR value is calculated as
- SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R)
- where MICBIAS is configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by 'nuvoton,sar-voltage', R - button impedance.
- Refer datasheet section 10.2 for more information about threshold calculation.
-
- - nuvoton,sar-hysteresis: Button impedance measurement hysteresis.
-
- - nuvoton,sar-voltage: Reference voltage for button impedance measurement.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,sar-compare-time: SAR compare time
- 0 - 500 ns
- 1 - 1 us
- 2 - 2 us
- 3 - 4 us
-
- - nuvoton,sar-sampling-time: SAR sampling time
- 0 - 2 us
- 1 - 4 us
- 2 - 8 us
- 3 - 16 us
-
- - nuvoton,short-key-debounce: Button short key press debounce time.
- 0 - 30 ms
- 1 - 50 ms
- 2 - 100 ms
- 3 - 30 ms
-
- - nuvoton,jack-insert-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms
- - nuvoton,jack-eject-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms
-
- - nuvoton,crosstalk-enable: make crosstalk function enable if set.
-
- - nuvoton,adcout-drive-strong: make the drive strength of ADCOUT IO PIN strong if set.
- Otherwise, the drive keeps normal strength.
-
- - nuvoton,adc-delay-ms: Delay (in ms) to make input path stable and avoid pop noise. The
- default value is 125 and range between 125 to 500 ms.
-
- - clocks: list of phandle and clock specifier pairs according to common clock bindings for the
- clocks described in clock-names
- - clock-names: should include "mclk" for the MCLK master clock
-
-Example:
-
- headset: nau8825@1a {
- compatible = "nuvoton,nau8825";
- reg = <0x1a>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(E, 6) IRQ_TYPE_LEVEL_LOW>;
- nuvoton,jkdet-enable;
- nuvoton,jkdet-pull-enable;
- nuvoton,jkdet-pull-up;
- nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>;
- nuvoton,vref-impedance = <2>;
- nuvoton,micbias-voltage = <6>;
- // Setup 4 buttons impedance according to Android specification
- nuvoton,sar-threshold-num = <4>;
- nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>;
- nuvoton,sar-hysteresis = <1>;
- nuvoton,sar-voltage = <0>;
- nuvoton,sar-compare-time = <0>;
- nuvoton,sar-sampling-time = <0>;
- nuvoton,short-key-debounce = <2>;
- nuvoton,jack-insert-debounce = <7>;
- nuvoton,jack-eject-debounce = <7>;
- nuvoton,crosstalk-enable;
-
- clock-names = "mclk";
- clocks = <&tegra_pmc TEGRA_PMC_CLK_OUT_2>;
- };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml
new file mode 100644
index 0000000..24006e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8315.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8315/NAU8318 Mono Class-D Amplifier
+
+maintainers:
+ - David Lin <CTLIN0@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nau8315
+ - nuvoton,nau8318
+
+ '#sound-dai-cells':
+ const: 0
+
+ enable-gpios:
+ maxItems: 1
+ description:
+ GPIO specifier for the chip's device enable input(EN) pin.
+ If this option is not specified then driver does not manage
+ the pin state (e.g. chip is always on).
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ codec {
+ compatible = "nuvoton,nau8315";
+ #sound-dai-cells = <0>;
+ enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8540.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8540.yaml
new file mode 100644
index 0000000..7ccfbb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8540.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8540.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton Technology Corporation NAU85L40 Audio CODEC
+
+maintainers:
+ - John Hsu <KCHSU0@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: nuvoton,nau8540
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1c {
+ compatible = "nuvoton,nau8540";
+ reg = <0x1c>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8810.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8810.yaml
new file mode 100644
index 0000000..d9696f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8810.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8810.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8810/NAU8812/NAU8814 audio CODEC
+
+maintainers:
+ - David Lin <CTLIN0@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nau8810
+ - nuvoton,nau8812
+ - nuvoton,nau8814
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ #sound-dai-cells = <0>;
+ compatible = "nuvoton,nau8810";
+ reg = <0x1a>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml
new file mode 100644
index 0000000..3dbf438
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml
@@ -0,0 +1,182 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8824.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8824 audio CODEC
+
+maintainers:
+ - John Hsu <KCHSU0@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nau8824
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ nuvoton,jkdet-polarity:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ JKDET pin polarity.
+ enum:
+ - 0 # active high
+ - 1 # active low
+ default: 1
+
+ nuvoton,vref-impedance:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ VREF Impedance selection.
+ enum:
+ - 0 # Open
+ - 1 # 25 kOhm
+ - 2 # 125 kOhm
+ - 3 # 2.5 kOhm
+ default: 2
+
+ nuvoton,micbias-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Micbias voltage level.
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,sar-threshold-num:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of buttons supported.
+ minimum: 1
+ maximum: 8
+ default: 4
+
+ nuvoton,sar-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Impedance threshold for each button. Array that contains up to 8 buttons
+ configuration. SAR value is calculated as
+ SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R) where MICBIAS is
+ configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by
+ 'nuvoton,sar-voltage', R - button impedance.
+ Refer datasheet section 10.2 for more information about threshold
+ calculation.
+ minItems: 1
+ maxItems: 8
+ items:
+ minimum: 0
+ maximum: 255
+
+ nuvoton,sar-hysteresis:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Button impedance measurement hysteresis.
+ default: 0
+
+ nuvoton,sar-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Reference voltage for button impedance measurement.
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,sar-compare-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ SAR compare time.
+ enum:
+ - 0 # 500ns
+ - 1 # 1us
+ - 2 # 2us
+ - 3 # 4us
+ default: 1
+
+ nuvoton,sar-sampling-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ SAR sampling time.
+ enum:
+ - 0 # 2us
+ - 1 # 4us
+ - 2 # 8us
+ - 3 # 16us
+ default: 1
+
+ nuvoton,short-key-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Button short key press debounce time.
+ enum:
+ - 0 # 30 ms
+ - 1 # 50 ms
+ - 2 # 100 ms
+ default: 0
+
+ nuvoton,jack-eject-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Jack ejection debounce time.
+ enum:
+ - 0 # 0 ms
+ - 1 # 1 ms
+ - 2 # 10 ms
+ default: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1a {
+ #sound-dai-cells = <0>;
+ compatible = "nuvoton,nau8824";
+ reg = <0x1a>;
+ interrupt-parent = <&gpio>;
+ interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
+ nuvoton,vref-impedance = <2>;
+ nuvoton,micbias-voltage = <6>;
+ nuvoton,sar-threshold-num = <4>;
+ // Setup 4 buttons impedance according to Android specification
+ nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>;
+ nuvoton,sar-hysteresis = <0>;
+ nuvoton,sar-voltage = <6>;
+ nuvoton,sar-compare-time = <1>;
+ nuvoton,sar-sampling-time = <1>;
+ nuvoton,short-key-debounce = <0>;
+ nuvoton,jack-eject-debounce = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml
new file mode 100644
index 0000000..a54f194
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml
@@ -0,0 +1,239 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8825.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8825 audio CODEC
+
+maintainers:
+ - John Hsu <KCHSU0@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nau8825
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ nuvoton,jkdet-enable:
+ description:
+ Enable jack detection via JKDET pin.
+ type: boolean
+
+ nuvoton,jkdet-pull-enable:
+ description:
+ Enable JKDET pin pull.
+ If set - pin pull enabled, otherwise pin in high impedance state.
+ type: boolean
+
+ nuvoton,jkdet-pull-up:
+ description:
+ Pull-up JKDET pin.
+ If set then JKDET pin is pull up, otherwise pull down.
+ type: boolean
+
+ nuvoton,jkdet-polarity:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ JKDET pin polarity.
+ enum:
+ - 0 # active high
+ - 1 # active low
+ default: 1
+
+ nuvoton,vref-impedance:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ VREF Impedance selection.
+ enum:
+ - 0 # Open
+ - 1 # 25 kOhm
+ - 2 # 125 kOhm
+ - 3 # 2.5 kOhm
+ default: 2
+
+ nuvoton,micbias-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Micbias voltage level.
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,sar-threshold-num:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of buttons supported.
+ minimum: 1
+ maximum: 4
+ default: 4
+
+ nuvoton,sar-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Impedance threshold for each button. Array that contains up to 8 buttons
+ configuration. SAR value is calculated as
+ SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R) where MICBIAS is
+ configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by
+ 'nuvoton,sar-voltage', R - button impedance.
+ Refer datasheet section 10.2 for more information about threshold
+ calculation.
+ minItems: 1
+ maxItems: 4
+ items:
+ minimum: 0
+ maximum: 255
+
+ nuvoton,sar-hysteresis:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Button impedance measurement hysteresis.
+ default: 0
+
+ nuvoton,sar-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Reference voltage for button impedance measurement.
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,sar-compare-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ SAR compare time.
+ enum:
+ - 0 # 500 ns
+ - 1 # 1 us
+ - 2 # 2 us
+ - 3 # 4 us
+ default: 1
+
+ nuvoton,sar-sampling-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ SAR sampling time.
+ enum:
+ - 0 # 2 us
+ - 1 # 4 us
+ - 2 # 8 us
+ - 3 # 16 us
+ default: 1
+
+ nuvoton,short-key-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Button short key press debounce time.
+ enum:
+ - 0 # 30 ms
+ - 1 # 50 ms
+ - 2 # 100 ms
+ - 3 # 30 ms
+ default: 3
+
+ nuvoton,jack-insert-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ number from 0 to 7 that sets debounce time to 2^(n+2) ms.
+ maximum: 7
+ default: 7
+
+ nuvoton,jack-eject-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ number from 0 to 7 that sets debounce time to 2^(n+2) ms
+ maximum: 7
+ default: 0
+
+ nuvoton,crosstalk-enable:
+ description:
+ make crosstalk function enable if set.
+ type: boolean
+
+ nuvoton,adcout-drive-strong:
+ description:
+ make the drive strength of ADCOUT IO PIN strong if set.
+ Otherwise, the drive keeps normal strength.
+ type: boolean
+
+ nuvoton,adc-delay-ms:
+ description:
+ Delay (in ms) to make input path stable and avoid pop noise.
+ The default value is 125 and range between 125 to 500 ms.
+ minimum: 125
+ maximum: 500
+ default: 125
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mclk
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1a {
+ #sound-dai-cells = <0>;
+ compatible = "nuvoton,nau8825";
+ reg = <0x1a>;
+ interrupt-parent = <&gpio>;
+ interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
+ nuvoton,jkdet-enable;
+ nuvoton,jkdet-pull-enable;
+ nuvoton,jkdet-pull-up;
+ nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>;
+ nuvoton,vref-impedance = <2>;
+ nuvoton,micbias-voltage = <6>;
+ // Setup 4 buttons impedance according to Android specification
+ nuvoton,sar-threshold-num = <4>;
+ nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>;
+ nuvoton,sar-hysteresis = <1>;
+ nuvoton,sar-voltage = <0>;
+ nuvoton,sar-compare-time = <0>;
+ nuvoton,sar-sampling-time = <0>;
+ nuvoton,short-key-debounce = <2>;
+ nuvoton,jack-insert-debounce = <7>;
+ nuvoton,jack-eject-debounce = <7>;
+ nuvoton,crosstalk-enable;
+
+ clock-names = "mclk";
+ clocks = <&tegra_pmc 1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml
index 7c1e989..2588589 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/nvidia,tegra-audio-common.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common properties for NVIDIA Tegra audio complexes
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
index 6cc8f86..3a559bd 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
@@ -8,7 +8,7 @@
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
- - Rohit kumar <rohitkr@codeaurora.org>
+ - Rohit kumar <quic_rohkumar@quicinc.com>
description: |
Qualcomm Technologies Inc. SOC Low-Power Audio SubSystem (LPASS) that consist
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
index cdbb409..9e5b30d 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/qcom,q6apm-dai.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/qcom,q6apm-dai.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Audio Process Manager Digital Audio Interfaces
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml
index 1168410..3552c44 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-clocks.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-clocks.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm DSP LPASS Clock Controller
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml
index 044e777..08c618e 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-ports.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-ports.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm DSP LPASS(Low Power Audio SubSystem) Audio Ports
diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml
new file mode 100644
index 0000000..e6723c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,wsa8840.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm WSA8840/WSA8845/WSA8845H smart speaker amplifier
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ WSA884X is a family of Qualcomm Aqstic smart speaker amplifiers using
+ SoundWire digital audio interface.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: sdw20217020400
+
+ reg:
+ maxItems: 1
+
+ powerdown-gpios:
+ description: Powerdown/Shutdown line to use (pin SD_N)
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ vdd-1p8-supply: true
+ vdd-io-supply: true
+
+required:
+ - compatible
+ - reg
+ - powerdown-gpios
+ - '#sound-dai-cells'
+ - vdd-1p8-supply
+ - vdd-io-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ soundwire-controller {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ speaker@0,1 {
+ compatible = "sdw20217020400";
+ reg = <0 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spkr_2_sd_n_active>;
+ powerdown-gpios = <&lpass_tlmm 18 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "SpkrRight";
+ vdd-1p8-supply = <&vreg_l15b_1p8>;
+ vdd-io-supply = <&vreg_l3g_1p2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1016.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1016.yaml
new file mode 100644
index 0000000..5287e9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt1016.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt1016.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Reaktek RT1016 Stereo Class D Audio Amplifier
+
+maintainers:
+ - oder_chiou@realtek.com
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: realtek,rt1016
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1a {
+ compatible = "realtek,rt1016";
+ reg = <0x1a>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/rt1016.txt b/Documentation/devicetree/bindings/sound/rt1016.txt
deleted file mode 100644
index 2310f8f..0000000
--- a/Documentation/devicetree/bindings/sound/rt1016.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-RT1016 Stereo Class D Audio Amplifier
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "realtek,rt1016".
-
-- reg : The I2C address of the device.
-
-
-Example:
-
-rt1016: codec@1a {
- compatible = "realtek,rt1016";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml
index 56e623d..a970fd2 100644
--- a/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml
@@ -36,7 +36,8 @@
const: i2sclk
resets:
- maxItems: 1
+ items:
+ - description: Optional controller resets
dmas:
items:
diff --git a/Documentation/devicetree/bindings/sound/ssm2518.txt b/Documentation/devicetree/bindings/sound/ssm2518.txt
deleted file mode 100644
index 59381a7..0000000
--- a/Documentation/devicetree/bindings/sound/ssm2518.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-SSM2518 audio amplifier
-
-This device supports I2C only.
-
-Required properties:
- - compatible : Must be "adi,ssm2518"
- - reg : the I2C address of the device. This will either be 0x34 (ADDR pin low)
- or 0x35 (ADDR pin high)
-
-Optional properties:
- - gpios : GPIO connected to the nSD pin. If the property is not present it is
- assumed that the nSD pin is hardwired to always on.
-
-Example:
-
- ssm2518: ssm2518@34 {
- compatible = "adi,ssm2518";
- reg = <0x34>;
- gpios = <&gpio 5 0>;
- };
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
index a040d4d..b9111d3 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
@@ -61,6 +61,10 @@
description: Configure the I2S device as MCLK clock provider.
const: 0
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- "#sound-dai-cells"
@@ -89,6 +93,13 @@
dma-names = "rx", "tx";
pinctrl-names = "default";
pinctrl-0 = <&i2s2_pins_a>;
+
+ /* assume audio-graph */
+ port {
+ codec_endpoint: endpoint {
+ remote-endpoint = <&codec_endpoint>;
+ };
+ };
};
...
diff --git a/Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml b/Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml
new file mode 100644
index 0000000..abb373f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/starfive,jh7110-tdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 TDM Controller
+
+description: |
+ The TDM Controller is a Time Division Multiplexed audio interface
+ integrated in StarFive JH7110 SoC, allowing up to 8 channels of
+ audio over a serial interface. The TDM controller can operate both
+ in master and slave mode.
+
+maintainers:
+ - Walker Chen <walker.chen@starfivetech.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - starfive,jh7110-tdm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: TDM AHB Clock
+ - description: TDM APB Clock
+ - description: TDM Internal Clock
+ - description: TDM Clock
+ - description: Inner MCLK
+ - description: TDM External Clock
+
+ clock-names:
+ items:
+ - const: tdm_ahb
+ - const: tdm_apb
+ - const: tdm_internal
+ - const: tdm
+ - const: mclk_inner
+ - const: tdm_ext
+
+ resets:
+ items:
+ - description: tdm ahb reset line
+ - description: tdm apb reset line
+ - description: tdm core reset line
+
+ dmas:
+ items:
+ - description: RX DMA Channel
+ - description: TX DMA Channel
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - dmas
+ - dma-names
+ - "#sound-dai-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ tdm@10090000 {
+ compatible = "starfive,jh7110-tdm";
+ reg = <0x10090000 0x1000>;
+ clocks = <&syscrg 184>,
+ <&syscrg 185>,
+ <&syscrg 186>,
+ <&syscrg 187>,
+ <&syscrg 17>,
+ <&tdm_ext>;
+ clock-names = "tdm_ahb", "tdm_apb",
+ "tdm_internal", "tdm",
+ "mclk_inner", "tdm_ext";
+ resets = <&syscrg 105>,
+ <&syscrg 107>,
+ <&syscrg 106>;
+ dmas = <&dma 20>, <&dma 21>;
+ dma-names = "rx","tx";
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml b/Documentation/devicetree/bindings/sound/tas2562.yaml
index 31a3024..f01c0dd 100644
--- a/Documentation/devicetree/bindings/sound/tas2562.yaml
+++ b/Documentation/devicetree/bindings/sound/tas2562.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2019 Texas Instruments Incorporated
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/tas2562.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/tas2562.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments TAS2562 Smart PA
diff --git a/Documentation/devicetree/bindings/sound/tas2770.yaml b/Documentation/devicetree/bindings/sound/tas2770.yaml
index 8908bf1..be2536e 100644
--- a/Documentation/devicetree/bindings/sound/tas2770.yaml
+++ b/Documentation/devicetree/bindings/sound/tas2770.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2019-20 Texas Instruments Incorporated
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/tas2770.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/tas2770.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments TAS2770 Smart PA
diff --git a/Documentation/devicetree/bindings/sound/tas27xx.yaml b/Documentation/devicetree/bindings/sound/tas27xx.yaml
index a876545..f2d878f 100644
--- a/Documentation/devicetree/bindings/sound/tas27xx.yaml
+++ b/Documentation/devicetree/bindings/sound/tas27xx.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2020-2022 Texas Instruments Incorporated
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/tas27xx.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/tas27xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments TAS2764/TAS2780 Smart PA
diff --git a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
new file mode 100644
index 0000000..8d60e4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 - 2023 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tas2781.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TAS2781 SmartAMP
+
+maintainers:
+ - Shenghao Ding <shenghao-ding@ti.com>
+
+description:
+ The TAS2781 is a mono, digital input Class-D audio amplifier
+ optimized for efficiently driving high peak power into small
+ loudspeakers. An integrated on-chip DSP supports Texas Instruments
+ Smart Amp speaker protection algorithm. The integrated speaker
+ voltage and current sense provides for real time
+ monitoring of loudspeaker behavior.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,tas2781
+
+ reg:
+ description:
+ I2C address, in multiple tas2781s case, all the i2c address
+ aggreate as one Audio Device to support multiple audio slots.
+ maxItems: 8
+ minItems: 1
+ items:
+ minimum: 0x38
+ maximum: 0x3f
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ /* example with quad tas2781s, such as tablet or pad device */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ quad_tas2781: tas2781@38 {
+ compatible = "ti,tas2781";
+ reg = <0x38>, /* Audio slot 0 */
+ <0x3a>, /* Audio slot 1 */
+ <0x39>, /* Audio slot 2 */
+ <0x3b>; /* Audio slot 3 */
+
+ #sound-dai-cells = <0>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <15>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml
new file mode 100644
index 0000000..a7cc9aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tlv320aic32x4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TLV320AIC32x4 Stereo Audio codec
+
+maintainers:
+ - Alexander Stein <alexander.stein@ew.tq-group.com>
+
+description: |
+ The TLV320AIC32x4 audio codec can be accessed using I2C or SPI
+
+properties:
+ compatible:
+ enum:
+ - ti,tas2505
+ - ti,tlv320aic32x4
+ - ti,tlv320aic32x6
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Master clock
+
+ clock-names:
+ items:
+ - const: mclk
+
+ av-supply:
+ description: Analog core power supply
+
+ dv-supply:
+ description: Digital core power supply
+
+ iov-supply:
+ description: Digital IO power supply
+
+ ldoin-supply:
+ description: LDO power supply
+
+ reset-gpios:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ aic32x4-gpio-func:
+ description: |
+ GPIO function configuration for pins MFP1-MFP5.
+ Types are defined in include/sound/tlv320aic32x4.h
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 5
+ maxItems: 5
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - iov-supply
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ not:
+ required:
+ - ldoin-supply
+ then:
+ required:
+ - av-supply
+ - dv-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@18 {
+ compatible = "ti,tlv320aic32x4";
+ reg = <0x18>;
+ iov-supply = <®_3v3>;
+ ldoin-supply = <®_3v3>;
+ clocks = <&clks 201>;
+ clock-names = "mclk";
+ aic32x4-gpio-func= <
+ 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
+ 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
+ 0x04 /* MFP3 AIC32X4_MFP3_GPIO_ENABLED */
+ 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
+ 0x08 /* MFP5 AIC32X4_MFP5_GPIO_INPUT */
+ >;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml
index e8ca9f3..206f6d6 100644
--- a/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml
@@ -61,6 +61,7 @@
GPIO specification for the active low RESET input.
gpio-reset:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
maxItems: 1
description:
Deprecated, please use reset-gpios instead.
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt
deleted file mode 100644
index 0b4e21b..0000000
--- a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Texas Instruments - tlv320aic32x4 Codec module
-
-The tlv320aic32x4 serial control bus communicates through I2C protocols
-
-Required properties:
- - compatible - "string" - One of:
- "ti,tlv320aic32x4" TLV320AIC3204
- "ti,tlv320aic32x6" TLV320AIC3206, TLV320AIC3256
- "ti,tas2505" TAS2505, TAS2521
- - reg: I2C slave address
- - *-supply: Required supply regulators are:
- "iov" - digital IO power supply
- "ldoin" - LDO power supply
- "dv" - Digital core power supply
- "av" - Analog core power supply
- If you supply ldoin, dv and av are optional. Otherwise they are required
- See regulator/regulator.txt for more information about the detailed binding
- format.
-
-Optional properties:
- - reset-gpios: Reset-GPIO phandle with args as described in gpio/gpio.txt
- - clocks/clock-names: Clock named 'mclk' for the master clock of the codec.
- See clock/clock-bindings.txt for information about the detailed format.
- - aic32x4-gpio-func - <array of 5 int>
- - Types are defined in include/sound/tlv320aic32x4.h
-
-
-Example:
-
-codec: tlv320aic32x4@18 {
- compatible = "ti,tlv320aic32x4";
- reg = <0x18>;
- clocks = <&clks 201>;
- clock-names = "mclk";
- aic32x4-gpio-func= <
- 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
- 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
- 0x04 /* MFP3 AIC32X4_MFP3_GPIO_ENABLED */
- 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
- 0x08 /* MFP5 AIC32X4_MFP5_GPIO_INPUT */
- >;
-};
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml
index 7105ed5..4cfa66f 100644
--- a/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/wlf,wm8903.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/wlf,wm8903.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: WM8903 audio codec
diff --git a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
index e4dba82..fb44b89 100644
--- a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
+++ b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
@@ -21,6 +21,7 @@
- qcom,soundwire-v1.5.1
- qcom,soundwire-v1.6.0
- qcom,soundwire-v1.7.0
+ - qcom,soundwire-v2.0.0
reg:
maxItems: 1
@@ -80,18 +81,29 @@
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 8
+ maxItems: 16
qcom,ports-sinterval-low:
$ref: /schemas/types.yaml#/definitions/uint8-array
description:
- Sample interval low of each data port.
+ Sample interval (only lowest byte) of each data port.
Out ports followed by In ports. Used for Sample Interval calculation.
Value of 0xff indicates that this option is not implemented
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 8
+ maxItems: 16
+
+ qcom,ports-sinterval:
+ $ref: /schemas/types.yaml#/definitions/uint16-array
+ description:
+ Sample interval of each data port.
+ Out ports followed by In ports. Used for Sample Interval calculation.
+ Value of 0xffff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
qcom,ports-offset1:
$ref: /schemas/types.yaml#/definitions/uint8-array
@@ -102,7 +114,7 @@
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 8
+ maxItems: 16
qcom,ports-offset2:
$ref: /schemas/types.yaml#/definitions/uint8-array
@@ -113,7 +125,7 @@
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 8
+ maxItems: 16
qcom,ports-lane-control:
$ref: /schemas/types.yaml#/definitions/uint8-array
@@ -124,7 +136,7 @@
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 8
+ maxItems: 16
qcom,ports-block-pack-mode:
$ref: /schemas/types.yaml#/definitions/uint8-array
@@ -137,7 +149,7 @@
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 8
+ maxItems: 16
items:
oneOf:
- minimum: 0
@@ -154,7 +166,7 @@
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 8
+ maxItems: 16
items:
oneOf:
- minimum: 0
@@ -171,7 +183,7 @@
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 8
+ maxItems: 16
items:
oneOf:
- minimum: 0
@@ -187,7 +199,7 @@
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 8
+ maxItems: 16
items:
oneOf:
- minimum: 0
@@ -219,10 +231,15 @@
- '#size-cells'
- qcom,dout-ports
- qcom,din-ports
- - qcom,ports-sinterval-low
- qcom,ports-offset1
- qcom,ports-offset2
+oneOf:
+ - required:
+ - qcom,ports-sinterval-low
+ - required:
+ - qcom,ports-sinterval
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
index 2155478..a6f34bd 100644
--- a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
@@ -14,9 +14,6 @@
- Maxime Ripard <mripard@kernel.org>
properties:
- "#address-cells": true
- "#size-cells": true
-
compatible:
const: allwinner,sun4i-a10-spi
@@ -46,12 +43,9 @@
- const: rx
- const: tx
- num-cs: true
-
patternProperties:
"^.*@[0-9a-f]+":
type: object
- additionalProperties: true
properties:
reg:
items:
@@ -71,7 +65,7 @@
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
index de36c6a..28b8ace 100644
--- a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
@@ -14,11 +14,9 @@
- Maxime Ripard <mripard@kernel.org>
properties:
- "#address-cells": true
- "#size-cells": true
-
compatible:
oneOf:
+ - const: allwinner,sun50i-r329-spi
- const: allwinner,sun6i-a31-spi
- const: allwinner,sun8i-h3-spi
- items:
@@ -28,6 +26,15 @@
- allwinner,sun50i-h616-spi
- allwinner,suniv-f1c100s-spi
- const: allwinner,sun8i-h3-spi
+ - items:
+ - enum:
+ - allwinner,sun20i-d1-spi
+ - allwinner,sun50i-r329-spi-dbi
+ - const: allwinner,sun50i-r329-spi
+ - items:
+ - const: allwinner,sun20i-d1-spi-dbi
+ - const: allwinner,sun50i-r329-spi-dbi
+ - const: allwinner,sun50i-r329-spi
reg:
maxItems: 1
@@ -58,12 +65,9 @@
- const: rx
- const: tx
- num-cs: true
-
patternProperties:
"^.*@[0-9a-f]+":
type: object
- additionalProperties: true
properties:
reg:
items:
@@ -83,7 +87,7 @@
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml b/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml
index 6c57dd6..5836758 100644
--- a/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml
@@ -20,6 +20,10 @@
- items:
- const: microchip,sam9x60-spi
- const: atmel,at91rm9200-spi
+ - items:
+ - const: microchip,sam9x7-spi
+ - const: microchip,sam9x60-spi
+ - const: atmel,at91rm9200-spi
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
index b310069..4f15f9a 100644
--- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -46,12 +46,28 @@
maxItems: 2
items:
enum: [ qspi, qspi-ocp ]
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: amd,pensando-elba-qspi
+ then:
+ properties:
+ cdns,fifo-depth:
+ enum: [ 128, 256, 1024 ]
+ default: 1024
+ else:
+ properties:
+ cdns,fifo-depth:
+ enum: [ 128, 256 ]
+ default: 128
properties:
compatible:
oneOf:
- items:
- enum:
+ - amd,pensando-elba-qspi
- ti,k2g-qspi
- ti,am654-ospi
- intel,lgm-qspi
@@ -76,8 +92,6 @@
description:
Size of the data FIFO in words.
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 128, 256 ]
- default: 128
cdns,fifo-width:
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
index ee8f7ea..1696ac4 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
@@ -29,6 +29,9 @@
reg:
maxItems: 1
+ iommus:
+ maxItems: 1
+
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml
new file mode 100644
index 0000000..e59183e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/renesas,rzv2m-csi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2M Clocked Serial Interface (CSI)
+
+maintainers:
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: renesas,rzv2m-csi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The clock used to generate the output clock (CSICLK)
+ - description: Internal clock to access the registers (PCLK)
+
+ clock-names:
+ items:
+ - const: csiclk
+ - const: pclk
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - power-domains
+ - '#address-cells'
+ - '#size-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/r9a09g011-cpg.h>
+ csi4: spi@a4020200 {
+ compatible = "renesas,rzv2m-csi";
+ reg = <0xa4020200 0x80>;
+ interrupts = <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A09G011_CSI4_CLK>,
+ <&cpg CPG_MOD R9A09G011_CPERI_GRPH_PCLK>;
+ clock-names = "csiclk", "pclk";
+ resets = <&cpg R9A09G011_CSI_GPH_PRESETN>;
+ power-domains = <&cpg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/samsung,spi.yaml b/Documentation/devicetree/bindings/spi/samsung,spi.yaml
index e0a465d7..79da99c 100644
--- a/Documentation/devicetree/bindings/spi/samsung,spi.yaml
+++ b/Documentation/devicetree/bindings/spi/samsung,spi.yaml
@@ -35,8 +35,6 @@
minItems: 2
maxItems: 3
- cs-gpios: true
-
dmas:
minItems: 2
maxItems: 2
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
index 12ca108..a47cb14 100644
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -74,6 +74,8 @@
const: intel,keembay-ssi
- description: Intel Thunder Bay SPI Controller
const: intel,thunderbay-ssi
+ - description: Intel Mount Evans Integrated Management Complex SPI Controller
+ const: intel,mountevans-imc-ssi
- description: AMD Pensando Elba SoC SPI Controller
const: amd,pensando-elba-spi
- description: Baikal-T1 SPI Controller
diff --git a/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml b/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml
index 597fc4e..c96131e 100644
--- a/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml
@@ -17,9 +17,6 @@
- $ref: spi-controller.yaml#
properties:
- "#address-cells": true
- "#size-cells": true
-
compatible:
const: socionext,uniphier-scssi
diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.yaml b/Documentation/devicetree/bindings/spi/spi-cadence.yaml
index b0f83b5..b755273 100644
--- a/Documentation/devicetree/bindings/spi/spi-cadence.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-cadence.yaml
@@ -7,7 +7,7 @@
title: Cadence SPI controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
allOf:
- $ref: spi-controller.yaml#
diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml
index 90945f5..524f6fe 100644
--- a/Documentation/devicetree/bindings/spi/spi-controller.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
@@ -17,7 +17,7 @@
properties:
$nodename:
- pattern: "^spi(@.*|-[0-9a-f])*$"
+ pattern: "^spi(@.*|-([0-9]|[1-9][0-9]+))?$"
"#address-cells":
enum: [0, 1]
diff --git a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
index 6bd8383..4beb3af 100644
--- a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
@@ -7,7 +7,7 @@
title: Xilinx SPI controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
allOf:
- $ref: spi-controller.yaml#
diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml
index 20f7724..e5199b1 100644
--- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml
@@ -7,7 +7,7 @@
title: Xilinx Zynq UltraScale+ MPSoC GQSPI controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
allOf:
- $ref: spi-controller.yaml#
@@ -32,6 +32,12 @@
clocks:
maxItems: 2
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
index 83e8fb4..7ea8fb4 100644
--- a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
@@ -14,7 +14,7 @@
- $ref: spi-controller.yaml#
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
# Everything else is described in the common file
properties:
diff --git a/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
index abcbbe1..ac99883 100644
--- a/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
+++ b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
@@ -14,13 +14,18 @@
for multiple SoCs to control a single SPMI master.
allOf:
- - $ref: "spmi.yaml"
+ - $ref: spmi.yaml
properties:
compatible:
- enum:
- - mediatek,mt6873-spmi
- - mediatek,mt8195-spmi
+ oneOf:
+ - enum:
+ - mediatek,mt6873-spmi
+ - mediatek,mt8195-spmi
+ - items:
+ - enum:
+ - mediatek,mt8186-spmi
+ - const: mediatek,mt8195-spmi
reg:
maxItems: 2
diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index 0548e8e..8025a85 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
@@ -18,8 +18,10 @@
items:
- enum:
- qcom,apq8064-imem
+ - qcom,msm8226-imem
- qcom,msm8974-imem
- qcom,qcs404-imem
+ - qcom,qdu1000-imem
- qcom,sc7180-imem
- qcom,sc7280-imem
- qcom,sdm630-imem
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 993430b..0922d1f 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -94,6 +94,7 @@
- samsung,exynos4210-sysram
- samsung,exynos4210-sysram-ns
- socionext,milbeaut-smp-sram
+ - stericsson,u8500-esram
reg:
description:
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index b0bee7e..ab8b8fc 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -8,6 +8,7 @@
* marvell,armada380-thermal
* marvell,armadaxp-thermal
* marvell,armada-ap806-thermal
+ * marvell,armada-ap807-thermal
* marvell,armada-cp110-thermal
Note: these bindings are deprecated for AP806/CP110 and should instead
diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
deleted file mode 100644
index a3e9ec5..0000000
--- a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Binding for Thermal Sensor driver for BCM2835 SoCs.
-
-Required parameters:
--------------------
-
-compatible: should be one of: "brcm,bcm2835-thermal",
- "brcm,bcm2836-thermal" or "brcm,bcm2837-thermal"
-reg: Address range of the thermal registers.
-clocks: Phandle of the clock used by the thermal sensor.
-#thermal-sensor-cells: should be 0 (see Documentation/devicetree/bindings/thermal/thermal-sensor.yaml)
-
-Example:
-
-thermal-zones {
- cpu_thermal: cpu-thermal {
- polling-delay-passive = <0>;
- polling-delay = <1000>;
-
- thermal-sensors = <&thermal>;
-
- trips {
- cpu-crit {
- temperature = <80000>;
- hysteresis = <0>;
- type = "critical";
- };
- };
-
- coefficients = <(-538) 407000>;
-
- cooling-maps {
- };
- };
-};
-
-thermal: thermal@7e212000 {
- compatible = "brcm,bcm2835-thermal";
- reg = <0x7e212000 0x8>;
- clocks = <&clocks BCM2835_CLOCK_TSENS>;
- #thermal-sensor-cells = <0>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml
new file mode 100644
index 0000000..2b6026d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/brcm,bcm2835-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 thermal sensor
+
+maintainers:
+ - Stefan Wahren <stefan.wahren@i2se.com>
+
+allOf:
+ - $ref: thermal-sensor.yaml#
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-thermal
+ - brcm,bcm2836-thermal
+ - brcm,bcm2837-thermal
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 0
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#thermal-sensor-cells'
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+
+ thermal@7e212000 {
+ compatible = "brcm,bcm2835-thermal";
+ reg = <0x7e212000 0x8>;
+ clocks = <&clocks BCM2835_CLOCK_TSENS>;
+ #thermal-sensor-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index d1ec963..27e9e16 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -29,6 +29,8 @@
items:
- enum:
- qcom,mdm9607-tsens
+ - qcom,msm8226-tsens
+ - qcom,msm8909-tsens
- qcom,msm8916-tsens
- qcom,msm8939-tsens
- qcom,msm8974-tsens
@@ -48,6 +50,7 @@
- qcom,msm8953-tsens
- qcom,msm8996-tsens
- qcom,msm8998-tsens
+ - qcom,qcm2290-tsens
- qcom,sc7180-tsens
- qcom,sc7280-tsens
- qcom,sc8180x-tsens
@@ -56,6 +59,7 @@
- qcom,sdm845-tsens
- qcom,sm6115-tsens
- qcom,sm6350-tsens
+ - qcom,sm6375-tsens
- qcom,sm8150-tsens
- qcom,sm8250-tsens
- qcom,sm8350-tsens
@@ -67,6 +71,12 @@
enum:
- qcom,ipq8074-tsens
+ - description: v2 of TSENS with combined interrupt
+ items:
+ - enum:
+ - qcom,ipq9574-tsens
+ - const: qcom,ipq8074-tsens
+
reg:
items:
- description: TM registers
@@ -223,12 +233,7 @@
contains:
enum:
- qcom,ipq8064-tsens
- - qcom,mdm9607-tsens
- - qcom,msm8916-tsens
- qcom,msm8960-tsens
- - qcom,msm8974-tsens
- - qcom,msm8976-tsens
- - qcom,qcs404-tsens
- qcom,tsens-v0_1
- qcom,tsens-v1
then:
@@ -244,22 +249,7 @@
properties:
compatible:
contains:
- enum:
- - qcom,msm8953-tsens
- - qcom,msm8996-tsens
- - qcom,msm8998-tsens
- - qcom,sc7180-tsens
- - qcom,sc7280-tsens
- - qcom,sc8180x-tsens
- - qcom,sc8280xp-tsens
- - qcom,sdm630-tsens
- - qcom,sdm845-tsens
- - qcom,sm6350-tsens
- - qcom,sm8150-tsens
- - qcom,sm8250-tsens
- - qcom,sm8350-tsens
- - qcom,sm8450-tsens
- - qcom,tsens-v2
+ const: qcom,tsens-v2
then:
properties:
interrupts:
diff --git a/Documentation/devicetree/bindings/timer/brcm,kona-timer.txt b/Documentation/devicetree/bindings/timer/brcm,kona-timer.txt
deleted file mode 100644
index 39adf54..0000000
--- a/Documentation/devicetree/bindings/timer/brcm,kona-timer.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Broadcom Kona Family timer
------------------------------------------------------
-This timer is used in the following Broadcom SoCs:
- BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
-
-Required properties:
-- compatible : "brcm,kona-timer"
-- DEPRECATED: compatible : "bcm,kona-timer"
-- reg : Register range for the timer
-- interrupts : interrupt for the timer
-- clocks: phandle + clock specifier pair of the external clock
-- clock-frequency: frequency that the clock operates
-
-Only one of clocks or clock-frequency should be specified.
-
-Refer to clocks/clock-bindings.txt for generic clock consumer properties.
-
-Example:
- timer@35006000 {
- compatible = "brcm,kona-timer";
- reg = <0x35006000 0x1000>;
- interrupts = <0x0 7 0x4>;
- clocks = <&hub_timer_clk>;
- };
-
diff --git a/Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml b/Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml
new file mode 100644
index 0000000..d6af838
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/brcm,kona-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family timer
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,kona-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency: true
+
+oneOf:
+ - required:
+ - clocks
+ - required:
+ - clock-frequency
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm281xx.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ timer@35006000 {
+ compatible = "brcm,kona-timer";
+ reg = <0x35006000 0x1000>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&aon_ccu BCM281XX_AON_CCU_HUB_TIMER>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml
index bc5e6f2..dbba780 100644
--- a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml
+++ b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml
@@ -7,7 +7,7 @@
title: Cadence TTC - Triple Timer Counter
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
index 716c6af..dbe1267 100644
--- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
+++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
@@ -31,9 +31,13 @@
- enum:
- fsl,imx6sl-gpt
- fsl,imx6sx-gpt
+ - fsl,imx8mp-gpt
- fsl,imxrt1050-gpt
- fsl,imxrt1170-gpt
- const: fsl,imx6dl-gpt
+ - items:
+ - const: fsl,imx6ul-gpt
+ - const: fsl,imx6sx-gpt
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml b/Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml
new file mode 100644
index 0000000..ad61ae5
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/loongson,ls1x-pwmtimer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1 PWM timer
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+description:
+ Loongson-1 PWM timer can be used for system clock source
+ and clock event timers.
+
+properties:
+ compatible:
+ const: loongson,ls1b-pwmtimer
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/loongson,ls1x-clk.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ clocksource: timer@1fe5c030 {
+ compatible = "loongson,ls1b-pwmtimer";
+ reg = <0x1fe5c030 0x10>;
+
+ clocks = <&clkc LS1X_CLKID_APB>;
+ interrupt-parent = <&intc0>;
+ interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml b/Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml
new file mode 100644
index 0000000..daa7832
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/ralink,rt2880-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Timer present in Ralink family SoCs
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+properties:
+ compatible:
+ const: ralink,rt2880-timer
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@100 {
+ compatible = "ralink,rt2880-timer";
+ reg = <0x100 0x20>;
+
+ clocks = <&sysc 3>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index 94bef94..a0185e1 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -29,14 +29,15 @@
oneOf:
- items:
- enum:
- - sifive,fu540-c000-clint
- - starfive,jh7100-clint
- - starfive,jh7110-clint
- - canaan,k210-clint
- - const: sifive,clint0
+ - canaan,k210-clint # Canaan Kendryte K210
+ - sifive,fu540-c000-clint # SiFive FU540
+ - starfive,jh7100-clint # StarFive JH7100
+ - starfive,jh7110-clint # StarFive JH7110
+ - const: sifive,clint0 # SiFive CLINT v0 IP block
- items:
- enum:
- allwinner,sun20i-d1-clint
+ - thead,th1520-clint
- const: thead,c900-clint
- items:
- const: sifive,clint0
@@ -45,14 +46,9 @@
description: For the QEMU virt machine only
description:
- Should be "<vendor>,<chip>-clint" and "sifive,clint<version>".
- Supported compatible strings are -
- "sifive,fu540-c000-clint" for the SiFive CLINT v0 as integrated
- onto the SiFive FU540 chip, "canaan,k210-clint" for the SiFive
- CLINT v0 as integrated onto the Canaan Kendryte K210 chip, and
- "sifive,clint0" for the SiFive CLINT v0 IP block with no chip
- integration tweaks.
- Please refer to sifive-blocks-ip-versioning.txt for details
+ Should be "<vendor>,<chip>-clint", followed by "sifive,clint<version>"
+ when compatible with a SiFive CLINT. Please refer to
+ sifive-blocks-ip-versioning.txt for details regarding the latter.
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml b/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml
index fd6a7b5..95f42ac 100644
--- a/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml
+++ b/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml
@@ -17,7 +17,7 @@
properties:
$nodename:
- pattern: "^timestamp(@.*|-[0-9a-f])?$"
+ pattern: "^timestamp(@.*|-([0-9]|[1-9][0-9]+))?$"
"#timestamp-cells":
description:
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 246863a..ba2bfb5 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -139,6 +139,8 @@
- infineon,ir38164
# Infineon IR38263 Voltage Regulator
- infineon,ir38263
+ # Infineon IRPS5401 Voltage Regulator (PMIC)
+ - infineon,irps5401
# Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
- infineon,slb9635tt
# Infineon SLB9645 I2C TPM (new protocol, max 400khz)
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index c5a06c0..bdfa86a 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -26,6 +26,7 @@
- qcom,msm8994-ufshc
- qcom,msm8996-ufshc
- qcom,msm8998-ufshc
+ - qcom,sa8775p-ufshc
- qcom,sc8280xp-ufshc
- qcom,sdm845-ufshc
- qcom,sm6350-ufshc
@@ -70,6 +71,10 @@
power-domains:
maxItems: 1
+ qcom,ice:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the Inline Crypto Engine node
+
reg:
minItems: 1
maxItems: 2
@@ -105,6 +110,7 @@
contains:
enum:
- qcom,msm8998-ufshc
+ - qcom,sa8775p-ufshc
- qcom,sc8280xp-ufshc
- qcom,sm8250-ufshc
- qcom,sm8350-ufshc
@@ -187,6 +193,25 @@
# TODO: define clock bindings for qcom,msm8994-ufshc
+ - if:
+ required:
+ - qcom,ice
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ clocks:
+ minItems: 8
+ maxItems: 8
+ else:
+ properties:
+ reg:
+ minItems: 1
+ maxItems: 2
+ clocks:
+ minItems: 8
+ maxItems: 11
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
index a998879..88cc1e3 100644
--- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
@@ -54,7 +54,7 @@
const: ufs-phy
samsung,sysreg:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description: Should be phandle/offset pair. The phandle to the syscon node
which indicates the FSYSx sysreg interface and the offset of
the control register for UFS io coherency setting.
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
index b26d26c..7824028 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
@@ -45,7 +45,9 @@
- fsl,vf610-usb
- const: fsl,imx27-usb
- items:
- - const: fsl,imx8dxl-usb
+ - enum:
+ - fsl,imx8dxl-usb
+ - fsl,imx8ulp-usb
- const: fsl,imx7ulp-usb
- const: fsl,imx6ul-usb
- items:
diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml
index d350609..0a5c98e 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
@@ -53,6 +53,7 @@
- amlogic,meson8b-usb
- amlogic,meson-gxbb-usb
- amlogic,meson-g12a-usb
+ - amlogic,meson-a1-usb
- intel,socfpga-agilex-hsotg
- const: snps,dwc2
- const: amcc,dwc-otg
diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
index 098b731..bb373eb 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
@@ -7,7 +7,7 @@
title: Xilinx SuperSpeed DWC3 USB SoC controller
maintainers:
- - Manish Narani <manish.narani@xilinx.com>
+ - Piyush Mehta <piyush.mehta@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml
new file mode 100644
index 0000000..ceb7639
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 NXP
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/fsl,imx8qm-cdns3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP iMX8QM Soc USB Controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qm-usb3
+
+ reg:
+ items:
+ - description: Register set for iMX USB3 Platform Control
+
+ "#address-cells":
+ enum: [ 1, 2 ]
+
+ "#size-cells":
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ clocks:
+ items:
+ - description: Standby clock. Used during ultra low power states.
+ - description: USB bus clock for usb3 controller.
+ - description: AXI clock for AXI interface.
+ - description: ipg clock for register access.
+ - description: Core clock for usb3 controller.
+
+ clock-names:
+ items:
+ - const: lpm
+ - const: bus
+ - const: aclk
+ - const: ipg
+ - const: core
+
+ power-domains:
+ maxItems: 1
+
+# Required child node:
+
+patternProperties:
+ "^usb@[0-9a-f]+$":
+ $ref: cdns,usb3.yaml#
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb@5b110000 {
+ compatible = "fsl,imx8qm-usb3";
+ reg = <0x5b110000 0x10000>;
+ ranges;
+ clocks = <&usb3_lpcg IMX_LPCG_CLK_1>,
+ <&usb3_lpcg IMX_LPCG_CLK_0>,
+ <&usb3_lpcg IMX_LPCG_CLK_7>,
+ <&usb3_lpcg IMX_LPCG_CLK_4>,
+ <&usb3_lpcg IMX_LPCG_CLK_5>;
+ clock-names = "lpm", "bus", "aclk", "ipg", "core";
+ assigned-clocks = <&clk IMX_SC_R_USB_2 IMX_SC_PM_CLK_MST_BUS>;
+ assigned-clock-rates = <250000000>;
+ power-domains = <&pd IMX_SC_R_USB_2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ usb@5b120000 {
+ compatible = "cdns,usb3";
+ reg = <0x5b120000 0x10000>, /* memory area for OTG/DRD registers */
+ <0x5b130000 0x10000>, /* memory area for HOST registers */
+ <0x5b140000 0x10000>; /* memory area for DEVICE registers */
+ reg-names = "otg", "xhci", "dev";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "host", "peripheral", "otg", "wakeup";
+ phys = <&usb3_phy>;
+ phy-names = "cdns3,usb3-phy";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index 9445764..b956bb5 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -61,6 +61,7 @@
- ibm,476gtr-ehci
- nxp,lpc1850-ehci
- qca,ar7100-ehci
+ - rockchip,rk3588-ehci
- snps,hsdk-v1.0-ehci
- socionext,uniphier-ehci
- const: generic-ehci
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index d06d1e7..be268e2 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -44,6 +44,7 @@
- hpe,gxp-ohci
- ibm,476gtr-ohci
- ingenic,jz4740-ohci
+ - rockchip,rk3588-ohci
- snps,hsdk-v1.0-ohci
- const: generic-ohci
- enum:
@@ -69,7 +70,7 @@
clocks:
minItems: 1
- maxItems: 3
+ maxItems: 4
description: |
In case the Renesas R-Car Gen3 SoCs:
- if a host only channel: first clock should be host.
@@ -147,6 +148,20 @@
then:
properties:
transceiver: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3588-ohci
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ else:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 3
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
index 478214a..a59d912 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
@@ -304,7 +304,7 @@
# Dual role switch with type-c
- |
usb@11201000 {
- compatible ="mediatek,mt8183-mtu3", "mediatek,mtu3";
+ compatible = "mediatek,mt8183-mtu3", "mediatek,mtu3";
reg = <0x11201000 0x2e00>, <0x11203e00 0x0100>;
reg-names = "mac", "ippc";
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>;
diff --git a/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
new file mode 100644
index 0000000..ff3a170
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/microchip,usb5744.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip USB5744 4-port Hub Controller
+
+description:
+ Microchip's USB5744 SmartHubTM IC is a 4 port, SuperSpeed (SS)/Hi-Speed (HS),
+ low power, low pin count configurable and fully compliant with the USB 3.1
+ Gen 1 specification. The USB5744 also supports Full Speed (FS) and Low Speed
+ (LS) USB signaling, offering complete coverage of all defined USB operating
+ speeds. The new SuperSpeed hubs operate in parallel with the USB 2.0
+ controller, so 5 Gbps SuperSpeed data transfers are not affected by slower
+ USB 2.0 traffic.
+
+maintainers:
+ - Piyush Mehta <piyush.mehta@amd.com>
+ - Michal Simek <michal.simek@amd.com>
+
+properties:
+ compatible:
+ enum:
+ - usb424,2744
+ - usb424,5744
+ - microchip,usb5744
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO controlling the GRST# pin.
+
+ vdd-supply:
+ description:
+ VDD power supply to the hub
+
+ peer-hub:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the peer hub on the controller.
+
+ i2c-bus:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle of an usb hub connected via i2c bus.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,usb5744
+ then:
+ properties:
+ reset-gpios: false
+ vdd-supply: false
+ peer-hub: false
+ i2c-bus: false
+ else:
+ $ref: /schemas/usb/usb-device.yaml
+ required:
+ - peer-hub
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c: i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hub: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
+ };
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb424,2744";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ i2c-bus = <&hub>;
+ reset-gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb424,5744";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ i2c-bus = <&hub>;
+ reset-gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
index e2270ce..c6e661e 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
@@ -91,6 +91,7 @@
phys:
minItems: 1
+ maxItems: 2
description:
Must contain an entry for each entry in phy-names.
See ../phy/phy-bindings.txt for details.
@@ -99,13 +100,7 @@
minItems: 1
items:
- const: usb2-0
- - const: usb2-1
- - const: usb2-2
- - const: usb2-3
- const: usb3-0
- - const: usb3-1
- - const: usb3-2
- - const: usb3-3
avddio-usb-supply:
description: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
diff --git a/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml
new file mode 100644
index 0000000..c0201da
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/onnn,nb7vpq904m.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ON Semiconductor Type-C DisplayPort ALT Mode Linear Redriver
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - onnn,nb7vpq904m
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description: power supply (1.8V)
+
+ enable-gpios: true
+
+ retimer-switch:
+ description: Flag the port as possible handle of SuperSpeed signals retiming
+ type: boolean
+
+ orientation-switch:
+ description: Flag the port as possible handler of orientation switching
+ type: boolean
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Super Speed (SS) Output endpoint to the Type-C connector
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description: Super Speed (SS) Input endpoint from the Super-Speed PHY
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ An array of physical data lane indexes. Position determines how
+ lanes are connected to the redriver, It is assumed the same order
+ is kept on the other side of the redriver.
+ Lane number represents the following
+ - 0 is RX2 lane
+ - 1 is TX2 lane
+ - 2 is TX1 lane
+ - 3 is RX1 lane
+ The position determines the physical port of the redriver, in the
+ order A, B, C & D.
+ oneOf:
+ - items:
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+ description: |
+ This is the lanes default layout
+ - Port A to RX2 lane
+ - Port B to TX2 lane
+ - Port C to TX1 lane
+ - Port D to RX1 lane
+ - items:
+ - const: 3
+ - const: 2
+ - const: 1
+ - const: 0
+ description: |
+ This is the USBRX2/USBTX2 and USBRX1/USBTX1 swapped lanes layout
+ - Port A to RX1 lane
+ - Port B to TX1 lane
+ - Port C to TX2 lane
+ - Port D to RX2 lane
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Sideband Use (SBU) AUX lines endpoint to the Type-C connector for the purpose of
+ handling altmode muxing and orientation switching.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec-mux@32 {
+ compatible = "onnn,nb7vpq904m";
+ reg = <0x32>;
+
+ vcc-supply = <&vreg_l15b_1p8>;
+
+ retimer-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usb_con_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ phy_con_ss: endpoint {
+ remote-endpoint = <&usb_phy_ss>;
+ data-lanes = <3 2 1 0>;
+ };
+ };
+ port@2 {
+ reg = <2>;
+ usb_con_sbu: endpoint {
+ remote-endpoint = <&typec_dp_aux>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index d842819..ae24dac 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -17,12 +17,14 @@
- qcom,ipq6018-dwc3
- qcom,ipq8064-dwc3
- qcom,ipq8074-dwc3
+ - qcom,ipq9574-dwc3
- qcom,msm8953-dwc3
- qcom,msm8994-dwc3
- qcom,msm8996-dwc3
- qcom,msm8998-dwc3
- qcom,qcm2290-dwc3
- qcom,qcs404-dwc3
+ - qcom,sa8775p-dwc3
- qcom,sc7180-dwc3
- qcom,sc7280-dwc3
- qcom,sc8280xp-dwc3
@@ -133,7 +135,6 @@
- "#address-cells"
- "#size-cells"
- ranges
- - power-domains
- clocks
- clock-names
- interrupts
@@ -177,9 +178,11 @@
compatible:
contains:
enum:
+ - qcom,ipq9574-dwc3
- qcom,msm8953-dwc3
- qcom,msm8996-dwc3
- qcom,msm8998-dwc3
+ - qcom,sa8775p-dwc3
- qcom,sc7180-dwc3
- qcom,sc7280-dwc3
- qcom,sdm670-dwc3
@@ -455,6 +458,25 @@
- const: dm_hs_phy_irq
- const: ss_phy_irq
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-dwc3
+ then:
+ properties:
+ interrupts:
+ minItems: 3
+ maxItems: 4
+ interrupt-names:
+ minItems: 3
+ items:
+ - const: pwr_event
+ - const: dp_hs_phy_irq
+ - const: dm_hs_phy_irq
+ - const: ss_phy_irq
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index 0000000..55df312
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,190 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PMIC based USB Type-C block
+
+maintainers:
+ - Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+description:
+ Qualcomm PMIC Type-C block
+
+properties:
+ compatible:
+ enum:
+ - qcom,pm8150b-typec
+
+ connector:
+ type: object
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
+ reg:
+ description: Type-C port and pdphy SPMI register base offsets
+ maxItems: 2
+
+ interrupts:
+ items:
+ - description: Type-C CC attach notification, VBUS error, tCCDebounce done
+ - description: Type-C VCONN powered
+ - description: Type-C CC state change
+ - description: Type-C VCONN over-current
+ - description: Type-C VBUS state change
+ - description: Type-C Attach/detach notification
+ - description: Type-C Legacy cable detect
+ - description: Type-C Try.Src Try.Snk state change
+ - description: Power Domain Signal TX - HardReset or CableReset signal TX
+ - description: Power Domain Signal RX - HardReset or CableReset signal RX
+ - description: Power Domain TX complete
+ - description: Power Domain RX complete
+ - description: Power Domain TX fail
+ - description: Power Domain TX message discard
+ - description: Power Domain RX message discard
+ - description: Power Domain Fast Role Swap event
+
+ interrupt-names:
+ items:
+ - const: or-rid-detect-change
+ - const: vpd-detect
+ - const: cc-state-change
+ - const: vconn-oc
+ - const: vbus-change
+ - const: attach-detach
+ - const: legacy-cable-detect
+ - const: try-snk-src-detect
+ - const: sig-tx
+ - const: sig-rx
+ - const: msg-tx
+ - const: msg-rx
+ - const: msg-tx-failed
+ - const: msg-tx-discarded
+ - const: msg-rx-discarded
+ - const: fr-swap
+
+ vdd-vbus-supply:
+ description: VBUS power supply.
+
+ vdd-pdphy-supply:
+ description: VDD regulator supply to the PDPHY.
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Contains a port which produces data-role switching messages.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - vdd-vbus-supply
+ - vdd-pdphy-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/usb/pd.h>
+
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pm8150b_typec: typec@1500 {
+ compatible = "qcom,pm8150b-typec";
+ reg = <0x1500>,
+ <0x1700>;
+
+ interrupts = <0x2 0x15 0x00 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x15 0x01 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x15 0x02 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x15 0x03 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x15 0x04 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x15 0x05 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x15 0x06 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x15 0x07 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x00 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x01 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x02 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x03 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x04 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x05 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x06 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x07 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "or-rid-detect-change",
+ "vpd-detect",
+ "cc-state-change",
+ "vconn-oc",
+ "vbus-change",
+ "attach-detach",
+ "legacy-cable-detect",
+ "try-snk-src-detect",
+ "sig-tx",
+ "sig-rx",
+ "msg-tx",
+ "msg-rx",
+ "msg-tx-failed",
+ "msg-tx-discarded",
+ "msg-rx-discarded",
+ "fr-swap";
+
+ vdd-vbus-supply = <&pm8150b_vbus>;
+ vdd-pdphy-supply = <&vreg_l2a_3p1>;
+
+ connector {
+ compatible = "usb-c-connector";
+
+ power-role = "source";
+ data-role = "dual";
+ self-powered;
+
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_DUAL_ROLE |
+ PDO_FIXED_USB_COMM | PDO_FIXED_DATA_SWAP)>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ pmic_typec_mux_out: endpoint {
+ remote-endpoint = <&usb_phy_typec_mux_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ pmic_typec_role_switch_out: endpoint {
+ remote-endpoint = <&usb_role_switch_in>;
+ };
+ };
+ };
+ };
+ };
+ };
+
+ usb {
+ dr_mode = "otg";
+ usb-role-switch;
+ port {
+ usb_role_switch_in: endpoint {
+ remote-endpoint = <&pmic_typec_role_switch_out>;
+ };
+ };
+ };
+
+ usb-phy {
+ orientation-switch;
+ port {
+ usb_phy_typec_mux_in: endpoint {
+ remote-endpoint = <&pmic_typec_mux_out>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index 4f76259..a696f23 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -44,15 +44,15 @@
It's either a single common DWC3 interrupt (dwc_usb3) or individual
interrupts for the host, gadget and DRD modes.
minItems: 1
- maxItems: 3
+ maxItems: 4
interrupt-names:
minItems: 1
- maxItems: 3
+ maxItems: 4
oneOf:
- const: dwc_usb3
- items:
- enum: [host, peripheral, otg]
+ enum: [host, peripheral, otg, wakeup]
clocks:
description:
diff --git a/Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml b/Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml
new file mode 100644
index 0000000..24aa9c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/starfive,jh7110-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 wrapper module for the Cadence USBSS-DRD controller
+
+maintainers:
+ - Minda Chen <minda.chen@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-usb
+
+ ranges: true
+
+ starfive,stg-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller stg_syscon node.
+ - description: dr mode register offset of STG_SYSCONSAIF__SYSCFG register for USB.
+ description:
+ The phandle to System Register Controller syscon node and the offset
+ of STG_SYSCONSAIF__SYSCFG register for USB.
+
+ dr_mode:
+ enum: [host, otg, peripheral]
+
+ "#address-cells":
+ enum: [1, 2]
+
+ "#size-cells":
+ enum: [1, 2]
+
+ clocks:
+ items:
+ - description: link power management clock
+ - description: standby clock
+ - description: APB clock
+ - description: AXI clock
+ - description: UTMI APB clock
+
+ clock-names:
+ items:
+ - const: lpm
+ - const: stb
+ - const: apb
+ - const: axi
+ - const: utmi_apb
+
+ resets:
+ items:
+ - description: Power up reset
+ - description: APB clock reset
+ - description: AXI clock reset
+ - description: UTMI APB clock reset
+
+ reset-names:
+ items:
+ - const: pwrup
+ - const: apb
+ - const: axi
+ - const: utmi_apb
+
+patternProperties:
+ "^usb@[0-9a-f]+$":
+ $ref: cdns,usb3.yaml#
+ description: Required child node
+
+required:
+ - compatible
+ - ranges
+ - starfive,stg-syscon
+ - '#address-cells'
+ - '#size-cells'
+ - dr_mode
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ usb@10100000 {
+ compatible = "starfive,jh7110-usb";
+ ranges = <0x0 0x10100000 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ starfive,stg-syscon = <&stg_syscon 0x4>;
+ clocks = <&syscrg 4>,
+ <&stgcrg 5>,
+ <&stgcrg 1>,
+ <&stgcrg 3>,
+ <&stgcrg 2>;
+ clock-names = "lpm", "stb", "apb", "axi", "utmi_apb";
+ resets = <&stgcrg 10>,
+ <&stgcrg 8>,
+ <&stgcrg 7>,
+ <&stgcrg 9>;
+ reset-names = "pwrup", "apb", "axi", "utmi_apb";
+ dr_mode = "host";
+
+ usb@0 {
+ compatible = "cdns,usb3";
+ reg = <0x0 0x10000>,
+ <0x10000 0x10000>,
+ <0x20000 0x10000>;
+ reg-names = "otg", "xhci", "dev";
+ interrupts = <100>, <108>, <110>;
+ interrupt-names = "host", "peripheral", "otg";
+ maximum-speed = "super-speed";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml
index d25fc70..fec5651 100644
--- a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml
@@ -92,7 +92,7 @@
usb@31100000 {
compatible = "snps,dwc3";
- reg =<0x00 0x31100000 0x00 0x50000>;
+ reg = <0x00 0x31100000 0x00 0x50000>;
interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>, /* irq.0 */
<GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>; /* irq.0 */
interrupt-names = "host", "peripheral";
diff --git a/Documentation/devicetree/bindings/usb/usb251xb.yaml b/Documentation/devicetree/bindings/usb/usb251xb.yaml
index 4d15308..ac5b997 100644
--- a/Documentation/devicetree/bindings/usb/usb251xb.yaml
+++ b/Documentation/devicetree/bindings/usb/usb251xb.yaml
@@ -231,7 +231,7 @@
power-on sequence to a port until the port has adequate power.
swap-dx-lanes:
- $ref: /schemas/types.yaml#/definitions/uint8-array
+ $ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Specifies the ports which will swap the differential-pair (D+/D-),
default is not-swapped.
diff --git a/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml b/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml
index 04c123c..868dffe 100644
--- a/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml
+++ b/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml
@@ -7,7 +7,7 @@
title: Xilinx udc controller
maintainers:
- - Manish Narani <manish.narani@xilinx.com>
+ - Piyush Mehta <piyush.mehta@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 82d39ab..af60bf1 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -388,6 +388,8 @@
description: EDIMAX Technology Co., Ltd
"^edt,.*":
description: Emerging Display Technologies
+ "^ees,.*":
+ description: Emtop Embedded Solutions
"^eeti,.*":
description: eGalax_eMPIA Technology Inc
"^einfochips,.*":
@@ -617,6 +619,8 @@
description: Integrated Micro-Electronics Inc.
"^incircuit,.*":
description: In-Circuit GmbH
+ "^indiedroid,.*":
+ description: Indiedroid
"^inet-tek,.*":
description: Shenzhen iNet Mobile Internet Technology Co., Ltd
"^infineon,.*":
@@ -781,6 +785,8 @@
description: Nanjing Loongmasses Ltd.
"^lsi,.*":
description: LSI Corp. (LSI Logic)
+ "^lunzn,.*":
+ description: Shenzhen Lunzn Technology Co., Ltd.
"^lwn,.*":
description: Liebherr-Werk Nenzing GmbH
"^lxa,.*":
@@ -1189,6 +1195,8 @@
description: SHIFT GmbH
"^shimafuji,.*":
description: Shimafuji Electric, Inc.
+ "^shineworld,.*":
+ description: ShineWorld Innovations
"^shiratech,.*":
description: Shiratech Solutions
"^si-en,.*":
@@ -1267,6 +1275,8 @@
description: SpinalHDL
"^sprd,.*":
description: Spreadtrum Communications Inc.
+ "^square,.*":
+ description: Square
"^ssi,.*":
description: SSI Computer Corp
"^sst,.*":
@@ -1339,6 +1349,8 @@
description: Technologic Systems
"^techstar,.*":
description: Shenzhen Techstar Electronics Co., Ltd.
+ "^teejet,.*":
+ description: TeeJet
"^teltonika,.*":
description: Teltonika Networks
"^tempo,.*":
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt b/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt
deleted file mode 100644
index 2b86a00..0000000
--- a/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Broadcom Kona Family Watchdog Timer
------------------------------------
-
-This watchdog timer is used in the following Broadcom SoCs:
- BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
-
-Required properties:
- - compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
- - reg: memory address & range
-
-Example:
- watchdog@35002f40 {
- compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
- reg = <0x35002f40 0x6c>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml b/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml
new file mode 100644
index 0000000..3d4403b
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/brcm,kona-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona Family Watchdog Timer
+
+description: |
+ This watchdog timer is used in the following Broadcom SoCs:
+ BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: brcm,bcm11351-wdt
+ - const: brcm,kona-wdt
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@35002f40 {
+ compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
+ reg = <0x35002f40 0x6c>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt b/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt
deleted file mode 100644
index 750a876..0000000
--- a/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Zynq Watchdog Device Tree Bindings
--------------------------------------------
-
-Required properties:
-- compatible : Should be "cdns,wdt-r1p2".
-- clocks : This is pclk (APB clock).
-- interrupts : This is wd_irq - watchdog timeout interrupt.
-
-Optional properties
-- reset-on-timeout : If this property exists, then a reset is done
- when watchdog times out.
-- timeout-sec : Watchdog timeout value (in seconds).
-
-Example:
- watchdog@f8005000 {
- compatible = "cdns,wdt-r1p2";
- clocks = <&clkc 45>;
- interrupt-parent = <&intc>;
- interrupts = <0 9 1>;
- reg = <0xf8005000 0x1000>;
- reset-on-timeout;
- timeout-sec = <10>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml b/Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml
new file mode 100644
index 0000000..3c17c58
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/cdns,wdt-r1p2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence watchdog timer controller
+
+maintainers:
+ - Neeli Srinivas <srinivas.neeli@amd.com>
+
+description:
+ The cadence watchdog timer is used to detect and recover from
+ system malfunctions. This watchdog contains 24 bit counter and
+ a programmable reset period. The timeout period varies from 1 ms
+ to 30 seconds while using a 100Mhz clock.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cdns,wdt-r1p2
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-on-timeout:
+ type: boolean
+ description: |
+ If this property exists, then a reset is done when watchdog
+ times out.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@f8005000 {
+ compatible = "cdns,wdt-r1p2";
+ reg = <0xf8005000 0x1000>;
+ clocks = <&clkc 45>;
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_EDGE_RISING>;
+ reset-on-timeout;
+ timeout-sec = <10>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml b/Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml
new file mode 100644
index 0000000..81690d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/loongson,ls1x-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1 Watchdog Timer
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls1b-wdt
+ - loongson,ls1c-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/loongson,ls1x-clk.h>
+ watchdog: watchdog@1fe5c060 {
+ compatible = "loongson,ls1b-wdt";
+ reg = <0x1fe5c060 0xc>;
+
+ clocks = <&clkc LS1X_CLKID_APB>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.yaml b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
index 519b488..f0a584a 100644
--- a/Documentation/devicetree/bindings/watchdog/watchdog.yaml
+++ b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
@@ -17,11 +17,11 @@
select:
properties:
$nodename:
- pattern: "^watchdog(@.*|-[0-9a-f])?$"
+ pattern: "^watchdog(@.*|-([0-9]|[1-9][0-9]+))?$"
properties:
$nodename:
- pattern: "^(timer|watchdog)(@.*|-[0-9a-f])?$"
+ pattern: "^(timer|watchdog)(@.*|-([0-9]|[1-9][0-9]+))?$"
timeout-sec:
description:
diff --git a/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
new file mode 100644
index 0000000..14b0695
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/xlnx,versal-wwdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal window watchdog timer controller
+
+maintainers:
+ - Neeli Srinivas <srinivas.neeli@amd.com>
+
+description:
+ Versal watchdog intellectual property uses window watchdog mode.
+ Window watchdog timer(WWDT) contains closed(first) and open(second)
+ window with 32 bit width. Write to the watchdog timer within
+ predefined window periods of time. This means a period that is not
+ too soon and a period that is not too late. The WWDT has to be
+ restarted within the open window time. If software tries to restart
+ WWDT outside of the open window time period, it generates a reset.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,versal-wwdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@fd4d0000 {
+ compatible = "xlnx,versal-wwdt";
+ reg = <0xfd4d0000 0x10000>;
+ clocks = <&clock25>;
+ timeout-sec = <30>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml b/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml
index 8444c56..dc1ff39 100644
--- a/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml
@@ -7,8 +7,8 @@
title: Xilinx AXI/PLB softcore and window Watchdog Timer
maintainers:
- - Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
- - Srinivas Neeli <srinivas.neeli@xilinx.com>
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
+ - Srinivas Neeli <srinivas.neeli@amd.com>
description:
The Timebase watchdog timer(WDT) is a free-running 32 bit counter.
diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst
index 23edb42..cd8ad79 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -313,9 +313,18 @@
function name exists. If you see ``c:func:`` use in a kernel document,
please feel free to remove it.
+Tables
+------
+
+ReStructuredText provides several options for table syntax. Kernel style for
+tables is to prefer *simple table* syntax or *grid table* syntax. See the
+`reStructuredText user reference for table syntax`_ for more details.
+
+.. _reStructuredText user reference for table syntax:
+ https://docutils.sourceforge.io/docs/user/rst/quickref.html#tables
list tables
------------
+~~~~~~~~~~~
The list-table formats can be useful for tables that are not easily laid
out in the usual Sphinx ASCII-art formats. These formats are nearly
diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst
index 4b4d8e2..7671b53 100644
--- a/Documentation/driver-api/basics.rst
+++ b/Documentation/driver-api/basics.rst
@@ -84,7 +84,13 @@
Atomics
-------
-.. kernel-doc:: arch/x86/include/asm/atomic.h
+.. kernel-doc:: include/linux/atomic/atomic-instrumented.h
+ :internal:
+
+.. kernel-doc:: include/linux/atomic/atomic-arch-fallback.h
+ :internal:
+
+.. kernel-doc:: include/linux/atomic/atomic-long.h
:internal:
Kernel objects manipulation
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index 4249eb4..8be086b 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -364,6 +364,7 @@
devm_kmalloc_array()
devm_kmemdup()
devm_krealloc()
+ devm_krealloc_array()
devm_kstrdup()
devm_kstrdup_const()
devm_kvasprintf()
diff --git a/Documentation/driver-api/edac.rst b/Documentation/driver-api/edac.rst
index b8c742a..f4f044b 100644
--- a/Documentation/driver-api/edac.rst
+++ b/Documentation/driver-api/edac.rst
@@ -106,6 +106,16 @@
This term is avoided because it is unclear when needing to distinguish
between chip-select rows and socket sets.
+* High Bandwidth Memory (HBM)
+
+HBM is a new memory type with low power consumption and ultra-wide
+communication lanes. It uses vertically stacked memory chips (DRAM dies)
+interconnected by microscopic wires called "through-silicon vias," or
+TSVs.
+
+Several stacks of HBM chips connect to the CPU or GPU through an ultra-fast
+interconnect called the "interposer". Therefore, HBM's characteristics
+are nearly indistinguishable from on-chip integrated RAM.
Memory Controllers
------------------
@@ -176,3 +186,113 @@
the L1 and L2 directories would be "edac_device_block's"
.. kernel-doc:: drivers/edac/edac_device.h
+
+
+Heterogeneous system support
+----------------------------
+
+An AMD heterogeneous system is built by connecting the data fabrics of
+both CPUs and GPUs via custom xGMI links. Thus, the data fabric on the
+GPU nodes can be accessed the same way as the data fabric on CPU nodes.
+
+The MI200 accelerators are data center GPUs. They have 2 data fabrics,
+and each GPU data fabric contains four Unified Memory Controllers (UMC).
+Each UMC contains eight channels. Each UMC channel controls one 128-bit
+HBM2e (2GB) channel (equivalent to 8 X 2GB ranks). This creates a total
+of 4096-bits of DRAM data bus.
+
+While the UMC is interfacing a 16GB (8high X 2GB DRAM) HBM stack, each UMC
+channel is interfacing 2GB of DRAM (represented as rank).
+
+Memory controllers on AMD GPU nodes can be represented in EDAC thusly:
+
+ GPU DF / GPU Node -> EDAC MC
+ GPU UMC -> EDAC CSROW
+ GPU UMC channel -> EDAC CHANNEL
+
+For example: a heterogeneous system with 1 AMD CPU is connected to
+4 MI200 (Aldebaran) GPUs using xGMI.
+
+Some more heterogeneous hardware details:
+
+- The CPU UMC (Unified Memory Controller) is mostly the same as the GPU UMC.
+ They have chip selects (csrows) and channels. However, the layouts are different
+ for performance, physical layout, or other reasons.
+- CPU UMCs use 1 channel, In this case UMC = EDAC channel. This follows the
+ marketing speak. CPU has X memory channels, etc.
+- CPU UMCs use up to 4 chip selects, So UMC chip select = EDAC CSROW.
+- GPU UMCs use 1 chip select, So UMC = EDAC CSROW.
+- GPU UMCs use 8 channels, So UMC channel = EDAC channel.
+
+The EDAC subsystem provides a mechanism to handle AMD heterogeneous
+systems by calling system specific ops for both CPUs and GPUs.
+
+AMD GPU nodes are enumerated in sequential order based on the PCI
+hierarchy, and the first GPU node is assumed to have a Node ID value
+following those of the CPU nodes after latter are fully populated::
+
+ $ ls /sys/devices/system/edac/mc/
+ mc0 - CPU MC node 0
+ mc1 |
+ mc2 |- GPU card[0] => node 0(mc1), node 1(mc2)
+ mc3 |
+ mc4 |- GPU card[1] => node 0(mc3), node 1(mc4)
+ mc5 |
+ mc6 |- GPU card[2] => node 0(mc5), node 1(mc6)
+ mc7 |
+ mc8 |- GPU card[3] => node 0(mc7), node 1(mc8)
+
+For example, a heterogeneous system with one AMD CPU is connected to
+four MI200 (Aldebaran) GPUs using xGMI. This topology can be represented
+via the following sysfs entries::
+
+ /sys/devices/system/edac/mc/..
+
+ CPU # CPU node
+ ├── mc 0
+
+ GPU Nodes are enumerated sequentially after CPU nodes have been populated
+ GPU card 1 # Each MI200 GPU has 2 nodes/mcs
+ ├── mc 1 # GPU node 0 == mc1, Each MC node has 4 UMCs/CSROWs
+ │ ├── csrow 0 # UMC 0
+ │ │ ├── channel 0 # Each UMC has 8 channels
+ │ │ ├── channel 1 # size of each channel is 2 GB, so each UMC has 16 GB
+ │ │ ├── channel 2
+ │ │ ├── channel 3
+ │ │ ├── channel 4
+ │ │ ├── channel 5
+ │ │ ├── channel 6
+ │ │ ├── channel 7
+ │ ├── csrow 1 # UMC 1
+ │ │ ├── channel 0
+ │ │ ├── ..
+ │ │ ├── channel 7
+ │ ├── .. ..
+ │ ├── csrow 3 # UMC 3
+ │ │ ├── channel 0
+ │ │ ├── ..
+ │ │ ├── channel 7
+ │ ├── rank 0
+ │ ├── .. ..
+ │ ├── rank 31 # total 32 ranks/dimms from 4 UMCs
+ ├
+ ├── mc 2 # GPU node 1 == mc2
+ │ ├── .. # each GPU has total 64 GB
+
+ GPU card 2
+ ├── mc 3
+ │ ├── ..
+ ├── mc 4
+ │ ├── ..
+
+ GPU card 3
+ ├── mc 5
+ │ ├── ..
+ ├── mc 6
+ │ ├── ..
+
+ GPU card 4
+ ├── mc 7
+ │ ├── ..
+ ├── mc 8
+ │ ├── ..
diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst
index 7837285..b650591 100644
--- a/Documentation/driver-api/gpio/legacy.rst
+++ b/Documentation/driver-api/gpio/legacy.rst
@@ -165,8 +165,7 @@
Those don't need to sleep, and can safely be done from inside hard
(nonthreaded) IRQ handlers and similar contexts.
-Use the following calls to access such GPIOs,
-for which gpio_cansleep() will always return false (see below)::
+Use the following calls to access such GPIOs::
/* GPIO INPUT: return zero or nonzero */
int gpio_get_value(unsigned gpio);
@@ -200,13 +199,6 @@
or SPI. Commands to read or write those GPIO values require waiting to
get to the head of a queue to transmit a command and get its response.
This requires sleeping, which can't be done from inside IRQ handlers.
-
-Platforms that support this type of GPIO distinguish them from other GPIOs
-by returning nonzero from this call (which requires a valid GPIO number,
-which should have been previously allocated with gpio_request)::
-
- int gpio_cansleep(unsigned gpio);
-
To access such GPIOs, a different set of accessors is defined::
/* GPIO INPUT: return zero or nonzero, might sleep */
@@ -215,7 +207,6 @@
/* GPIO OUTPUT, might sleep */
void gpio_set_value_cansleep(unsigned gpio, int value);
-
Accessing such GPIOs requires a context which may sleep, for example
a threaded IRQ handler, and those accessors must be used instead of
spinlock-safe accessors without the cansleep() name suffix.
@@ -319,11 +310,6 @@
* GPIOF_INIT_LOW - as output, set initial level to LOW
* GPIOF_INIT_HIGH - as output, set initial level to HIGH
- * GPIOF_OPEN_DRAIN - gpio pin is open drain type.
- * GPIOF_OPEN_SOURCE - gpio pin is open source type.
-
- * GPIOF_EXPORT_DIR_FIXED - export gpio to sysfs, keep direction
- * GPIOF_EXPORT_DIR_CHANGEABLE - also export, allow changing direction
since GPIOF_INIT_* are only valid when configured as output, so group valid
combinations as:
@@ -332,20 +318,6 @@
* GPIOF_OUT_INIT_LOW - configured as output, initial level LOW
* GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH
-When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is
-open drain type. Such pins will not be driven to 1 in output mode. It is
-require to connect pull-up on such pins. By enabling this flag, gpio lib will
-make the direction to input when it is asked to set value of 1 in output mode
-to make the pin HIGH. The pin is make to LOW by driving value 0 in output mode.
-
-When setting the flag as GPIOF_OPEN_SOURCE then it will assume that pins is
-open source type. Such pins will not be driven to 0 in output mode. It is
-require to connect pull-down on such pin. By enabling this flag, gpio lib will
-make the direction to input when it is asked to set value of 0 in output mode
-to make the pin LOW. The pin is make to HIGH by driving value 1 in output mode.
-
-In the future, these flags can be extended to support more properties.
-
Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is
introduced to encapsulate all three fields as::
@@ -556,7 +528,6 @@
#define gpio_get_value __gpio_get_value
#define gpio_set_value __gpio_set_value
- #define gpio_cansleep __gpio_cansleep
Fancier implementations could instead define those as inline functions with
logic optimizing access to specific SOC-based GPIOs. For example, if the
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index ff9aa1a..1e16a40d 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -113,6 +113,7 @@
xillybus
zorro
hte/index
+ wmi
.. only:: subproject and html
diff --git a/Documentation/driver-api/media/camera-sensor.rst b/Documentation/driver-api/media/camera-sensor.rst
index c7d4891..93f4f25 100644
--- a/Documentation/driver-api/media/camera-sensor.rst
+++ b/Documentation/driver-api/media/camera-sensor.rst
@@ -151,3 +151,25 @@
The function returns a non-zero value if it succeeded getting the power count or
runtime PM was disabled, in either of which cases the driver may proceed to
access the device.
+
+Rotation, orientation and flipping
+----------------------------------
+
+Some systems have the camera sensor mounted upside down compared to its natural
+mounting rotation. In such cases, drivers shall expose the information to
+userspace with the :ref:`V4L2_CID_CAMERA_SENSOR_ROTATION
+<v4l2-camera-sensor-rotation>` control.
+
+Sensor drivers shall also report the sensor's mounting orientation with the
+:ref:`V4L2_CID_CAMERA_SENSOR_ORIENTATION <v4l2-camera-sensor-orientation>`.
+
+Use ``v4l2_fwnode_device_parse()`` to obtain rotation and orientation
+information from system firmware and ``v4l2_ctrl_new_fwnode_properties()`` to
+register the appropriate controls.
+
+Sensor drivers that have any vertical or horizontal flips embedded in the
+register programming sequences shall initialize the V4L2_CID_HFLIP and
+V4L2_CID_VFLIP controls with the values programmed by the register sequences.
+The default values of these controls shall be 0 (disabled). Especially these
+controls shall not be inverted, independently of the sensor's mounting
+rotation.
diff --git a/Documentation/driver-api/ntb.rst b/Documentation/driver-api/ntb.rst
index 11577c2..e991d92 100644
--- a/Documentation/driver-api/ntb.rst
+++ b/Documentation/driver-api/ntb.rst
@@ -207,9 +207,9 @@
allows for passing MSI interrupts across NTB memory windows. The
test client is interacted with through the debugfs filesystem:
-* *debugfs*/ntb\_tool/*hw*/
+* *debugfs*/ntb\_msi\_test/*hw*/
A directory in debugfs will be created for each
- NTB device probed by the tool. This directory is shortened to *hw*
+ NTB device probed by the msi test. This directory is shortened to *hw*
below.
* *hw*/port
This file describes the local port number
diff --git a/Documentation/driver-api/ptp.rst b/Documentation/driver-api/ptp.rst
index 664838a..5e033c3 100644
--- a/Documentation/driver-api/ptp.rst
+++ b/Documentation/driver-api/ptp.rst
@@ -73,6 +73,22 @@
class driver, since the lock may also be needed by the clock
driver's interrupt service routine.
+PTP hardware clock requirements for '.adjphase'
+-----------------------------------------------
+
+ The 'struct ptp_clock_info' interface has a '.adjphase' function.
+ This function has a set of requirements from the PHC in order to be
+ implemented.
+
+ * The PHC implements a servo algorithm internally that is used to
+ correct the offset passed in the '.adjphase' call.
+ * When other PTP adjustment functions are called, the PHC servo
+ algorithm is disabled.
+
+ **NOTE:** '.adjphase' is not a simple time adjustment functionality
+ that 'jumps' the PHC clock time based on the provided offset. It
+ should correct the offset provided using an internal algorithm.
+
Supported hardware
==================
@@ -106,3 +122,16 @@
- LPF settings (bandwidth, phase limiting, automatic holdover, physical layer assist (per ITU-T G.8273.2))
- Programmable output PTP clocks, any frequency up to 1GHz (to other PHY/MAC time stampers, refclk to ASSPs/SoCs/FPGAs)
- Lock to GNSS input, automatic switching between GNSS and user-space PHC control (optional)
+
+ * NVIDIA Mellanox
+
+ - GPIO
+ - Certain variants of ConnectX-6 Dx and later products support one
+ GPIO which can time stamp external triggers and one GPIO to produce
+ periodic signals.
+ - Certain variants of ConnectX-5 and older products support one GPIO,
+ configured to either time stamp external triggers or produce
+ periodic signals.
+ - PHC instances
+ - All ConnectX devices have a free-running counter
+ - ConnectX-6 Dx and later devices have a UTC format counter
diff --git a/Documentation/driver-api/wmi.rst b/Documentation/driver-api/wmi.rst
new file mode 100644
index 0000000..6ca58c8
--- /dev/null
+++ b/Documentation/driver-api/wmi.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==============
+WMI Driver API
+==============
+
+The WMI driver core supports a more modern bus-based interface for interacting
+with WMI devices, and an older GUID-based interface. The latter interface is
+considered to be deprecated, so new WMI drivers should generally avoid it since
+it has some issues with multiple WMI devices and events sharing the same GUIDs
+and/or notification IDs. The modern bus-based interface instead maps each
+WMI device to a :c:type:`struct wmi_device <wmi_device>`, so it supports
+WMI devices sharing GUIDs and/or notification IDs. Drivers can then register
+a :c:type:`struct wmi_driver <wmi_driver>`, which will be bound to compatible
+WMI devices by the driver core.
+
+.. kernel-doc:: include/linux/wmi.h
+ :internal:
+
+.. kernel-doc:: drivers/platform/x86/wmi.c
+ :export:
diff --git a/Documentation/fault-injection/provoke-crashes.rst b/Documentation/fault-injection/provoke-crashes.rst
index 3abe842..1f087e5 100644
--- a/Documentation/fault-injection/provoke-crashes.rst
+++ b/Documentation/fault-injection/provoke-crashes.rst
@@ -29,7 +29,7 @@
cpoint_name
Where in the kernel to trigger the action. It can be
one of INT_HARDWARE_ENTRY, INT_HW_IRQ_EN, INT_TASKLET_ENTRY,
- FS_DEVRW, MEM_SWAPOUT, TIMERADD, SCSI_QUEUE_RQ, or DIRECT.
+ FS_SUBMIT_BH, MEM_SWAPOUT, TIMERADD, SCSI_QUEUE_RQ, or DIRECT.
cpoint_type
Indicates the action to be taken on hitting the crash point.
diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt
index 2328ead..94d9dec 100644
--- a/Documentation/features/core/jump-labels/arch-support.txt
+++ b/Documentation/features/core/jump-labels/arch-support.txt
@@ -13,7 +13,7 @@
| csky: | ok |
| hexagon: | TODO |
| ia64: | TODO |
- | loongarch: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/debug/kmemleak/arch-support.txt b/Documentation/features/debug/kmemleak/arch-support.txt
index 0cfa5f0..4e205ef 100644
--- a/Documentation/features/debug/kmemleak/arch-support.txt
+++ b/Documentation/features/debug/kmemleak/arch-support.txt
@@ -13,7 +13,7 @@
| csky: | ok |
| hexagon: | TODO |
| ia64: | TODO |
- | loongarch: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | ok |
| mips: | ok |
diff --git a/Documentation/filesystems/autofs-mount-control.rst b/Documentation/filesystems/autofs-mount-control.rst
index bf4b511..b5a379d 100644
--- a/Documentation/filesystems/autofs-mount-control.rst
+++ b/Documentation/filesystems/autofs-mount-control.rst
@@ -196,7 +196,7 @@
struct args_ismountpoint ismountpoint;
};
- char path[0];
+ char path[];
};
The ioctlfd field is a mount point file descriptor of an autofs mount
diff --git a/Documentation/filesystems/autofs.rst b/Documentation/filesystems/autofs.rst
index 4f490278..3b6e38e 100644
--- a/Documentation/filesystems/autofs.rst
+++ b/Documentation/filesystems/autofs.rst
@@ -467,7 +467,7 @@
struct args_ismountpoint ismountpoint;
};
- char path[0];
+ char path[];
};
For the **OPEN_MOUNT** and **IS_MOUNTPOINT** commands, the target
diff --git a/Documentation/filesystems/directory-locking.rst b/Documentation/filesystems/directory-locking.rst
index 504ba94..dccd61c 100644
--- a/Documentation/filesystems/directory-locking.rst
+++ b/Documentation/filesystems/directory-locking.rst
@@ -22,12 +22,11 @@
3) object removal. Locking rules: caller locks parent, finds victim,
locks victim and calls the method. Locks are exclusive.
-4) rename() that is _not_ cross-directory. Locking rules: caller locks
-the parent and finds source and target. In case of exchange (with
-RENAME_EXCHANGE in flags argument) lock both. In any case,
-if the target already exists, lock it. If the source is a non-directory,
-lock it. If we need to lock both, lock them in inode pointer order.
-Then call the method. All locks are exclusive.
+4) rename() that is _not_ cross-directory. Locking rules: caller locks the
+parent and finds source and target. We lock both (provided they exist). If we
+need to lock two inodes of different type (dir vs non-dir), we lock directory
+first. If we need to lock two inodes of the same type, lock them in inode
+pointer order. Then call the method. All locks are exclusive.
NB: we might get away with locking the source (and target in exchange
case) shared.
@@ -44,15 +43,17 @@
rules:
* lock the filesystem
- * lock parents in "ancestors first" order.
+ * lock parents in "ancestors first" order. If one is not ancestor of
+ the other, lock them in inode pointer order.
* find source and target.
* if old parent is equal to or is a descendent of target
fail with -ENOTEMPTY
* if new parent is equal to or is a descendent of source
fail with -ELOOP
- * If it's an exchange, lock both the source and the target.
- * If the target exists, lock it. If the source is a non-directory,
- lock it. If we need to lock both, do so in inode pointer order.
+ * Lock both the source and the target provided they exist. If we
+ need to lock two inodes of different type (dir vs non-dir), we lock
+ the directory first. If we need to lock two inodes of the same type,
+ lock them in inode pointer order.
* call the method.
All ->i_rwsem are taken exclusive. Again, we might get away with locking
@@ -66,8 +67,9 @@
Proof:
- First of all, at any moment we have a partial ordering of the
- objects - A < B iff A is an ancestor of B.
+ First of all, at any moment we have a linear ordering of the
+ objects - A < B iff (A is an ancestor of B) or (B is not an ancestor
+ of A and ptr(A) < ptr(B)).
That ordering can change. However, the following is true:
diff --git a/Documentation/filesystems/dlmfs.rst b/Documentation/filesystems/dlmfs.rst
index 28dd41a..7e2b1fd 100644
--- a/Documentation/filesystems/dlmfs.rst
+++ b/Documentation/filesystems/dlmfs.rst
@@ -12,7 +12,7 @@
:Project web page: http://ocfs2.wiki.kernel.org
:Tools web page: https://github.com/markfasheh/ocfs2-tools
-:OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+:OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst
index a6bef52..6e8fb2d 100644
--- a/Documentation/filesystems/ext4/journal.rst
+++ b/Documentation/filesystems/ext4/journal.rst
@@ -260,8 +260,13 @@
- s_num_fc_blocks
- Number of fast commit blocks in the journal.
* - 0x58
+ - __be32
+ - s_head
+ - Block number of the head (first unused block) of the journal, only
+ up-to-date when the journal is empty.
+ * - 0x5C
- __u32
- - s_padding[42]
+ - s_padding[40]
-
* - 0xFC
- __be32
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index c577453..9359978 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -351,6 +351,22 @@
data block update frequency of the extent per inode, in
order to provide better temperature hints for data block
allocation.
+errors=%s Specify f2fs behavior on critical errors. This supports modes:
+ "panic", "continue" and "remount-ro", respectively, trigger
+ panic immediately, continue without doing anything, and remount
+ the partition in read-only mode. By default it uses "continue"
+ mode.
+ ====================== =============== =============== ========
+ mode continue remount-ro panic
+ ====================== =============== =============== ========
+ access ops normal noraml N/A
+ syscall errors -EIO -EROFS N/A
+ mount option rw ro N/A
+ pending dir write keep keep N/A
+ pending non-dir write drop keep N/A
+ pending node write drop keep N/A
+ pending meta write keep keep N/A
+ ====================== =============== =============== ========
======================== ============================================================
Debugfs Entries
diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst
index ede672d..cb845e8 100644
--- a/Documentation/filesystems/fsverity.rst
+++ b/Documentation/filesystems/fsverity.rst
@@ -38,20 +38,14 @@
Use cases
=========
-By itself, the base fs-verity feature only provides integrity
-protection, i.e. detection of accidental (non-malicious) corruption.
+By itself, fs-verity only provides integrity protection, i.e.
+detection of accidental (non-malicious) corruption.
However, because fs-verity makes retrieving the file hash extremely
efficient, it's primarily meant to be used as a tool to support
authentication (detection of malicious modifications) or auditing
(logging file hashes before use).
-Trusted userspace code (e.g. operating system code running on a
-read-only partition that is itself authenticated by dm-verity) can
-authenticate the contents of an fs-verity file by using the
-`FS_IOC_MEASURE_VERITY`_ ioctl to retrieve its hash, then verifying a
-digital signature of it.
-
A standard file hash could be used instead of fs-verity. However,
this is inefficient if the file is large and only a small portion may
be accessed. This is often the case for Android application package
@@ -69,24 +63,31 @@
must live on a read-write filesystem because they are independently
updated and potentially user-installed, so dm-verity cannot be used.
-The base fs-verity feature is a hashing mechanism only; actually
-authenticating the files may be done by:
+fs-verity does not mandate a particular scheme for authenticating its
+file hashes. (Similarly, dm-verity does not mandate a particular
+scheme for authenticating its block device root hashes.) Options for
+authenticating fs-verity file hashes include:
-* Userspace-only
+- Trusted userspace code. Often, the userspace code that accesses
+ files can be trusted to authenticate them. Consider e.g. an
+ application that wants to authenticate data files before using them,
+ or an application loader that is part of the operating system (which
+ is already authenticated in a different way, such as by being loaded
+ from a read-only partition that uses dm-verity) and that wants to
+ authenticate applications before loading them. In these cases, this
+ trusted userspace code can authenticate a file's contents by
+ retrieving its fs-verity digest using `FS_IOC_MEASURE_VERITY`_, then
+ verifying a signature of it using any userspace cryptographic
+ library that supports digital signatures.
-* Builtin signature verification + userspace policy
+- Integrity Measurement Architecture (IMA). IMA supports fs-verity
+ file digests as an alternative to its traditional full file digests.
+ "IMA appraisal" enforces that files contain a valid, matching
+ signature in their "security.ima" extended attribute, as controlled
+ by the IMA policy. For more information, see the IMA documentation.
- fs-verity optionally supports a simple signature verification
- mechanism where users can configure the kernel to require that
- all fs-verity files be signed by a key loaded into a keyring;
- see `Built-in signature verification`_.
-
-* Integrity Measurement Architecture (IMA)
-
- IMA supports including fs-verity file digests and signatures in the
- IMA measurement list and verifying fs-verity based file signatures
- stored as security.ima xattrs, based on policy.
-
+- Trusted userspace code in combination with `Built-in signature
+ verification`_. This approach should be used only with great care.
User API
========
@@ -111,8 +112,7 @@
};
This structure contains the parameters of the Merkle tree to build for
-the file, and optionally contains a signature. It must be initialized
-as follows:
+the file. It must be initialized as follows:
- ``version`` must be 1.
- ``hash_algorithm`` must be the identifier for the hash algorithm to
@@ -129,12 +129,14 @@
file or device. Currently the maximum salt size is 32 bytes.
- ``salt_ptr`` is the pointer to the salt, or NULL if no salt is
provided.
-- ``sig_size`` is the size of the signature in bytes, or 0 if no
- signature is provided. Currently the signature is (somewhat
- arbitrarily) limited to 16128 bytes. See `Built-in signature
- verification`_ for more information.
-- ``sig_ptr`` is the pointer to the signature, or NULL if no
- signature is provided.
+- ``sig_size`` is the size of the builtin signature in bytes, or 0 if no
+ builtin signature is provided. Currently the builtin signature is
+ (somewhat arbitrarily) limited to 16128 bytes.
+- ``sig_ptr`` is the pointer to the builtin signature, or NULL if no
+ builtin signature is provided. A builtin signature is only needed
+ if the `Built-in signature verification`_ feature is being used. It
+ is not needed for IMA appraisal, and it is not needed if the file
+ signature is being handled entirely in userspace.
- All reserved fields must be zeroed.
FS_IOC_ENABLE_VERITY causes the filesystem to build a Merkle tree for
@@ -158,7 +160,7 @@
FS_IOC_ENABLE_VERITY can fail with the following errors:
- ``EACCES``: the process does not have write access to the file
-- ``EBADMSG``: the signature is malformed
+- ``EBADMSG``: the builtin signature is malformed
- ``EBUSY``: this ioctl is already running on the file
- ``EEXIST``: the file already has verity enabled
- ``EFAULT``: the caller provided inaccessible memory
@@ -168,10 +170,10 @@
reserved bits are set; or the file descriptor refers to neither a
regular file nor a directory.
- ``EISDIR``: the file descriptor refers to a directory
-- ``EKEYREJECTED``: the signature doesn't match the file
-- ``EMSGSIZE``: the salt or signature is too long
-- ``ENOKEY``: the fs-verity keyring doesn't contain the certificate
- needed to verify the signature
+- ``EKEYREJECTED``: the builtin signature doesn't match the file
+- ``EMSGSIZE``: the salt or builtin signature is too long
+- ``ENOKEY``: the ".fs-verity" keyring doesn't contain the certificate
+ needed to verify the builtin signature
- ``ENOPKG``: fs-verity recognizes the hash algorithm, but it's not
available in the kernel's crypto API as currently configured (e.g.
for SHA-512, missing CONFIG_CRYPTO_SHA512).
@@ -180,8 +182,8 @@
support; or the filesystem superblock has not had the 'verity'
feature enabled on it; or the filesystem does not support fs-verity
on this file. (See `Filesystem support`_.)
-- ``EPERM``: the file is append-only; or, a signature is required and
- one was not provided.
+- ``EPERM``: the file is append-only; or, a builtin signature is
+ required and one was not provided.
- ``EROFS``: the filesystem is read-only
- ``ETXTBSY``: someone has the file open for writing. This can be the
caller's file descriptor, another open file descriptor, or the file
@@ -270,9 +272,9 @@
- ``FS_VERITY_METADATA_TYPE_DESCRIPTOR`` reads the fs-verity
descriptor. See `fs-verity descriptor`_.
-- ``FS_VERITY_METADATA_TYPE_SIGNATURE`` reads the signature which was
- passed to FS_IOC_ENABLE_VERITY, if any. See `Built-in signature
- verification`_.
+- ``FS_VERITY_METADATA_TYPE_SIGNATURE`` reads the builtin signature
+ which was passed to FS_IOC_ENABLE_VERITY, if any. See `Built-in
+ signature verification`_.
The semantics are similar to those of ``pread()``. ``offset``
specifies the offset in bytes into the metadata item to read from, and
@@ -299,7 +301,7 @@
overflowed
- ``ENODATA``: the file is not a verity file, or
FS_VERITY_METADATA_TYPE_SIGNATURE was requested but the file doesn't
- have a built-in signature
+ have a builtin signature
- ``ENOTTY``: this type of filesystem does not implement fs-verity, or
this ioctl is not yet implemented on it
- ``EOPNOTSUPP``: the kernel was not configured with fs-verity
@@ -347,8 +349,8 @@
with EIO (for read()) or SIGBUS (for mmap() reads).
- If the sysctl "fs.verity.require_signatures" is set to 1 and the
- file is not signed by a key in the fs-verity keyring, then opening
- the file will fail. See `Built-in signature verification`_.
+ file is not signed by a key in the ".fs-verity" keyring, then
+ opening the file will fail. See `Built-in signature verification`_.
Direct access to the Merkle tree is not supported. Therefore, if a
verity file is copied, or is backed up and restored, then it will lose
@@ -433,20 +435,25 @@
Built-in signature verification
===============================
-With CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y, fs-verity supports putting
-a portion of an authentication policy (see `Use cases`_) in the
-kernel. Specifically, it adds support for:
+CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y adds supports for in-kernel
+verification of fs-verity builtin signatures.
-1. At fs-verity module initialization time, a keyring ".fs-verity" is
- created. The root user can add trusted X.509 certificates to this
- keyring using the add_key() system call, then (when done)
- optionally use keyctl_restrict_keyring() to prevent additional
- certificates from being added.
+**IMPORTANT**! Please take great care before using this feature.
+It is not the only way to do signatures with fs-verity, and the
+alternatives (such as userspace signature verification, and IMA
+appraisal) can be much better. It's also easy to fall into a trap
+of thinking this feature solves more problems than it actually does.
+
+Enabling this option adds the following:
+
+1. At boot time, the kernel creates a keyring named ".fs-verity". The
+ root user can add trusted X.509 certificates to this keyring using
+ the add_key() system call.
2. `FS_IOC_ENABLE_VERITY`_ accepts a pointer to a PKCS#7 formatted
detached signature in DER format of the file's fs-verity digest.
- On success, this signature is persisted alongside the Merkle tree.
- Then, any time the file is opened, the kernel will verify the
+ On success, the ioctl persists the signature alongside the Merkle
+ tree. Then, any time the file is opened, the kernel verifies the
file's actual digest against this signature, using the certificates
in the ".fs-verity" keyring.
@@ -454,8 +461,8 @@
When set to 1, the kernel requires that all verity files have a
correctly signed digest as described in (2).
-fs-verity file digests must be signed in the following format, which
-is similar to the structure used by `FS_IOC_MEASURE_VERITY`_::
+The data that the signature as described in (2) must be a signature of
+is the fs-verity file digest in the following format::
struct fsverity_formatted_digest {
char magic[8]; /* must be "FSVerity" */
@@ -464,13 +471,66 @@
__u8 digest[];
};
-fs-verity's built-in signature verification support is meant as a
-relatively simple mechanism that can be used to provide some level of
-authenticity protection for verity files, as an alternative to doing
-the signature verification in userspace or using IMA-appraisal.
-However, with this mechanism, userspace programs still need to check
-that the verity bit is set, and there is no protection against verity
-files being swapped around.
+That's it. It should be emphasized again that fs-verity builtin
+signatures are not the only way to do signatures with fs-verity. See
+`Use cases`_ for an overview of ways in which fs-verity can be used.
+fs-verity builtin signatures have some major limitations that should
+be carefully considered before using them:
+
+- Builtin signature verification does *not* make the kernel enforce
+ that any files actually have fs-verity enabled. Thus, it is not a
+ complete authentication policy. Currently, if it is used, the only
+ way to complete the authentication policy is for trusted userspace
+ code to explicitly check whether files have fs-verity enabled with a
+ signature before they are accessed. (With
+ fs.verity.require_signatures=1, just checking whether fs-verity is
+ enabled suffices.) But, in this case the trusted userspace code
+ could just store the signature alongside the file and verify it
+ itself using a cryptographic library, instead of using this feature.
+
+- A file's builtin signature can only be set at the same time that
+ fs-verity is being enabled on the file. Changing or deleting the
+ builtin signature later requires re-creating the file.
+
+- Builtin signature verification uses the same set of public keys for
+ all fs-verity enabled files on the system. Different keys cannot be
+ trusted for different files; each key is all or nothing.
+
+- The sysctl fs.verity.require_signatures applies system-wide.
+ Setting it to 1 only works when all users of fs-verity on the system
+ agree that it should be set to 1. This limitation can prevent
+ fs-verity from being used in cases where it would be helpful.
+
+- Builtin signature verification can only use signature algorithms
+ that are supported by the kernel. For example, the kernel does not
+ yet support Ed25519, even though this is often the signature
+ algorithm that is recommended for new cryptographic designs.
+
+- fs-verity builtin signatures are in PKCS#7 format, and the public
+ keys are in X.509 format. These formats are commonly used,
+ including by some other kernel features (which is why the fs-verity
+ builtin signatures use them), and are very feature rich.
+ Unfortunately, history has shown that code that parses and handles
+ these formats (which are from the 1990s and are based on ASN.1)
+ often has vulnerabilities as a result of their complexity. This
+ complexity is not inherent to the cryptography itself.
+
+ fs-verity users who do not need advanced features of X.509 and
+ PKCS#7 should strongly consider using simpler formats, such as plain
+ Ed25519 keys and signatures, and verifying signatures in userspace.
+
+ fs-verity users who choose to use X.509 and PKCS#7 anyway should
+ still consider that verifying those signatures in userspace is more
+ flexible (for other reasons mentioned earlier in this document) and
+ eliminates the need to enable CONFIG_FS_VERITY_BUILTIN_SIGNATURES
+ and its associated increase in kernel attack surface. In some cases
+ it can even be necessary, since advanced X.509 and PKCS#7 features
+ do not always work as intended with the kernel. For example, the
+ kernel does not check X.509 certificate validity times.
+
+ Note: IMA appraisal, which supports fs-verity, does not use PKCS#7
+ for its signatures, so it partially avoids the issues discussed
+ here. IMA appraisal does use X.509.
Filesystem support
==================
diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
index aa1a233..0ca479d 100644
--- a/Documentation/filesystems/locking.rst
+++ b/Documentation/filesystems/locking.rst
@@ -521,8 +521,6 @@
int (*fsync) (struct file *, loff_t start, loff_t end, int datasync);
int (*fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
- ssize_t (*sendpage) (struct file *, struct page *, int, size_t,
- loff_t *, int);
unsigned long (*get_unmapped_area)(struct file *, unsigned long,
unsigned long, unsigned long, unsigned long);
int (*check_flags)(int);
@@ -553,9 +551,8 @@
Note: this does not protect the file->f_pos against concurrent modifications
since this is something the userspace has to take care about.
-->iterate() is called with i_rwsem exclusive.
-
-->iterate_shared() is called with i_rwsem at least shared.
+->iterate_shared() is called with i_rwsem held for reading, and with the
+file f_pos_lock held exclusively
->fasync() is responsible for maintaining the FASYNC bit in filp->f_flags.
Most instances call fasync_helper(), which does that maintenance, so it's
diff --git a/Documentation/filesystems/nfs/exporting.rst b/Documentation/filesystems/nfs/exporting.rst
index 0e98edd..3d97b8d 100644
--- a/Documentation/filesystems/nfs/exporting.rst
+++ b/Documentation/filesystems/nfs/exporting.rst
@@ -122,8 +122,8 @@
super_block. This field must point to a "struct export_operations"
struct which has the following members:
- encode_fh (optional)
- Takes a dentry and creates a filehandle fragment which can later be used
+ encode_fh (optional)
+ Takes a dentry and creates a filehandle fragment which may later be used
to find or create a dentry for the same object. The default
implementation creates a filehandle fragment that encodes a 32bit inode
and generation number for the inode encoded, and if necessary the
diff --git a/Documentation/filesystems/ocfs2.rst b/Documentation/filesystems/ocfs2.rst
index 42ca9a3..5827062 100644
--- a/Documentation/filesystems/ocfs2.rst
+++ b/Documentation/filesystems/ocfs2.rst
@@ -14,7 +14,7 @@
Project web page: http://ocfs2.wiki.kernel.org
Tools git tree: https://github.com/markfasheh/ocfs2-tools
-OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index 4c76fda..eb7d2c8 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -231,12 +231,11 @@
Redirects are enabled.
- "redirect_dir=follow":
Redirects are not created, but followed.
-- "redirect_dir=off":
- Redirects are not created and only followed if "redirect_always_follow"
- feature is enabled in the kernel/module config.
- "redirect_dir=nofollow":
- Redirects are not created and not followed (equivalent to "redirect_dir=off"
- if "redirect_always_follow" feature is not enabled).
+ Redirects are not created and not followed.
+- "redirect_dir=off":
+ If "redirect_always_follow" is enabled in the kernel/module config,
+ this "off" traslates to "follow", otherwise it translates to "nofollow".
When the NFS export feature is enabled, every copied up directory is
indexed by the file handle of the lower inode and a file handle of the
@@ -371,6 +370,41 @@
[*] redirect_dir=follow only conflicts with metacopy=on if upperdir=... is
given.
+
+Data-only lower layers
+----------------------
+
+With "metacopy" feature enabled, an overlayfs regular file may be a composition
+of information from up to three different layers:
+
+ 1) metadata from a file in the upper layer
+
+ 2) st_ino and st_dev object identifier from a file in a lower layer
+
+ 3) data from a file in another lower layer (further below)
+
+The "lower data" file can be on any lower layer, except from the top most
+lower layer.
+
+Below the top most lower layer, any number of lower most layers may be defined
+as "data-only" lower layers, using double colon ("::") separators.
+A normal lower layer is not allowed to be below a data-only layer, so single
+colon separators are not allowed to the right of double colon ("::") separators.
+
+
+For example:
+
+ mount -t overlay overlay -olowerdir=/l1:/l2:/l3::/do1::/do2 /merged
+
+The paths of files in the "data-only" lower layers are not visible in the
+merged overlayfs directories and the metadata and st_ino/st_dev of files
+in the "data-only" lower layers are not visible in overlayfs inodes.
+
+Only the data of the files in the "data-only" lower layers may be visible
+when a "metacopy" file in one of the lower layers above it, has a "redirect"
+to the absolute path of the "lower data" file in the "data-only" lower layer.
+
+
Sharing and copying layers
--------------------------
diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst
index d2d684a..0f5da78 100644
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@ -537,7 +537,7 @@
**mandatory**
-->readdir() is gone now; switch to ->iterate()
+->readdir() is gone now; switch to ->iterate_shared()
**mandatory**
@@ -693,24 +693,19 @@
---
-**recommended**
+**mandatory**
-->iterate_shared() is added; it's a parallel variant of ->iterate().
+->iterate_shared() is added.
Exclusion on struct file level is still provided (as well as that
between it and lseek on the same struct file), but if your directory
has been opened several times, you can get these called in parallel.
Exclusion between that method and all directory-modifying ones is
still provided, of course.
-Often enough ->iterate() can serve as ->iterate_shared() without any
-changes - it is a read-only operation, after all. If you have any
-per-inode or per-dentry in-core data structures modified by ->iterate(),
-you might need something to serialize the access to them. If you
-do dcache pre-seeding, you'll need to switch to d_alloc_parallel() for
-that; look for in-tree examples.
-
-Old method is only used if the new one is absent; eventually it will
-be removed. Switch while you still can; the old one won't stay.
+If you have any per-inode or per-dentry in-core data structures modified
+by ->iterate_shared(), you might need something to serialize the access
+to them. If you do dcache pre-seeding, you'll need to switch to
+d_alloc_parallel() for that; look for in-tree examples.
---
@@ -930,9 +925,9 @@
filldir_t (readdir callbacks) calling conventions have changed. Instead of
returning 0 or -E... it returns bool now. false means "no more" (as -E... used
to) and true - "keep going" (as 0 in old calling conventions). Rationale:
-callers never looked at specific -E... values anyway. ->iterate() and
-->iterate_shared() instance require no changes at all, all filldir_t ones in
-the tree converted.
+callers never looked at specific -E... values anyway. -> iterate_shared()
+instances require no changes at all, all filldir_t ones in the tree
+converted.
---
diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst
index f18f46b..2cd8fa3 100644
--- a/Documentation/filesystems/tmpfs.rst
+++ b/Documentation/filesystems/tmpfs.rst
@@ -84,8 +84,6 @@
is half of the number of your physical RAM pages, or (on a
machine with highmem) the number of lowmem RAM pages,
whichever is the lower.
-noswap Disables swap. Remounts must respect the original settings.
- By default swap is enabled.
========= ============================================================
These parameters accept a suffix k, m or g for kilo, mega and giga and
@@ -99,36 +97,31 @@
use up all the memory on the machine; but enhances the scalability of
that instance in a system with many CPUs making intensive use of it.
+tmpfs blocks may be swapped out, when there is a shortage of memory.
+tmpfs has a mount option to disable its use of swap:
+
+====== ===========================================================
+noswap Disables swap. Remounts must respect the original settings.
+ By default swap is enabled.
+====== ===========================================================
+
tmpfs also supports Transparent Huge Pages which requires a kernel
configured with CONFIG_TRANSPARENT_HUGEPAGE and with huge supported for
your system (has_transparent_hugepage(), which is architecture specific).
The mount options for this are:
-====== ============================================================
-huge=0 never: disables huge pages for the mount
-huge=1 always: enables huge pages for the mount
-huge=2 within_size: only allocate huge pages if the page will be
- fully within i_size, also respect fadvise()/madvise() hints.
-huge=3 advise: only allocate huge pages if requested with
- fadvise()/madvise()
-====== ============================================================
+================ ==============================================================
+huge=never Do not allocate huge pages. This is the default.
+huge=always Attempt to allocate huge page every time a new page is needed.
+huge=within_size Only allocate huge page if it will be fully within i_size.
+ Also respect madvise(2) hints.
+huge=advise Only allocate huge page if requested with madvise(2).
+================ ==============================================================
-There is a sysfs file which you can also use to control system wide THP
-configuration for all tmpfs mounts, the file is:
-
-/sys/kernel/mm/transparent_hugepage/shmem_enabled
-
-This sysfs file is placed on top of THP sysfs directory and so is registered
-by THP code. It is however only used to control all tmpfs mounts with one
-single knob. Since it controls all tmpfs mounts it should only be used either
-for emergency or testing purposes. The values you can set for shmem_enabled are:
-
-== ============================================================
--1 deny: disables huge on shm_mnt and all mounts, for
- emergency use
--2 force: enables huge on shm_mnt and all mounts, w/o needing
- option, for testing
-== ============================================================
+See also Documentation/admin-guide/mm/transhuge.rst, which describes the
+sysfs file /sys/kernel/mm/transparent_hugepage/shmem_enabled: which can
+be used to deny huge pages on all tmpfs mounts in an emergency, or to
+force huge pages on all tmpfs mounts for testing.
tmpfs has a mount option to set the NUMA memory allocation policy for
all files in that instance (if CONFIG_NUMA is enabled) - which can be
diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst
index 769be52..cb2a97e 100644
--- a/Documentation/filesystems/vfs.rst
+++ b/Documentation/filesystems/vfs.rst
@@ -1086,7 +1086,6 @@
int (*fsync) (struct file *, loff_t, loff_t, int datasync);
int (*fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
- ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
int (*check_flags)(int);
int (*flock) (struct file *, int, struct file_lock *);
diff --git a/Documentation/gpu/amdgpu/apu-asic-info-table.csv b/Documentation/gpu/amdgpu/apu-asic-info-table.csv
index 395a7b7..2e76b42 100644
--- a/Documentation/gpu/amdgpu/apu-asic-info-table.csv
+++ b/Documentation/gpu/amdgpu/apu-asic-info-table.csv
@@ -5,6 +5,8 @@
Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN2, DCN 1.0, 9.2.2, VCN 1.0.1, 4.1.1, 10.0.1
SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1, 11.5.0
Ryzen 5000 series / Ryzen 7x30 series, GREEN SARDINE / Cezanne / Barcelo / Barcelo-R, DCN 2.1, 9.3, VCN 2.2, 4.1.1, 12.0.1
-Ryzen 6000 series / Ryzen 7x35 series, YELLOW CARP / Rembrandt / Rembrandt+, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3, 13.0.3
+Ryzen 6000 series / Ryzen 7x35 series / Ryzen 7x36 series, YELLOW CARP / Rembrandt / Rembrandt-R, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3, 13.0.3
Ryzen 7000 series (AM5), Raphael, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5
+Ryzen 7x45 series (FL1), / Dragon Range, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5
Ryzen 7x20 series, Mendocino, 3.1.6, 10.3.7, 3.1.1, 5.2.7, 13.0.8
+Ryzen 7x40 series, Phoenix, 3.1.4, 11.0.1 / 11.0.4, 4.0.2, 6.0.1, 13.0.4 / 13.0.11
\ No newline at end of file
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
index b463273..fe35a29 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -24,7 +24,7 @@
- All keys shall be prefixed with `drm-`.
- Whitespace between the delimiter and first non-whitespace character shall be
ignored when parsing.
-- Neither keys or values are allowed to contain whitespace characters.
+- Keys are not allowed to contain whitespace characters.
- Numerical key value pairs can end with optional unit string.
- Data type of the value is fixed as defined in the specification.
@@ -39,12 +39,13 @@
----------
- <uint> - Unsigned integer without defining the maximum value.
-- <str> - String excluding any above defined reserved characters or whitespace.
+- <keystr> - String excluding any above defined reserved characters or whitespace.
+- <valstr> - String.
Mandatory fully standardised keys
---------------------------------
-- drm-driver: <str>
+- drm-driver: <valstr>
String shall contain the name this driver registered as via the respective
`struct drm_driver` data structure.
@@ -52,6 +53,9 @@
Optional fully standardised keys
--------------------------------
+Identification
+^^^^^^^^^^^^^^
+
- drm-pdev: <aaaa:bb.cc.d>
For PCI devices this should contain the PCI slot address of the device in
@@ -69,10 +73,13 @@
Userspace should make sure to not double account any usage statistics by using
the above described criteria in order to associate data to individual clients.
-- drm-engine-<str>: <uint> ns
+Utilization
+^^^^^^^^^^^
+
+- drm-engine-<keystr>: <uint> ns
GPUs usually contain multiple execution engines. Each shall be given a stable
-and unique name (str), with possible values documented in the driver specific
+and unique name (keystr), with possible values documented in the driver specific
documentation.
Value shall be in specified time units which the respective GPU engine spent
@@ -84,31 +91,19 @@
was previously read, userspace is expected to stay with that larger previous
value until a monotonic update is seen.
-- drm-engine-capacity-<str>: <uint>
+- drm-engine-capacity-<keystr>: <uint>
Engine identifier string must be the same as the one specified in the
-drm-engine-<str> tag and shall contain a greater than zero number in case the
+drm-engine-<keystr> tag and shall contain a greater than zero number in case the
exported engine corresponds to a group of identical hardware engines.
In the absence of this tag parser shall assume capacity of one. Zero capacity
is not allowed.
-- drm-memory-<str>: <uint> [KiB|MiB]
-
-Each possible memory type which can be used to store buffer objects by the
-GPU in question shall be given a stable and unique name to be returned as the
-string here.
-
-Value shall reflect the amount of storage currently consumed by the buffer
-object belong to this client, in the respective memory region.
-
-Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
-indicating kibi- or mebi-bytes.
-
-- drm-cycles-<str> <uint>
+- drm-cycles-<keystr>: <uint>
Engine identifier string must be the same as the one specified in the
-drm-engine-<str> tag and shall contain the number of busy cycles for the given
+drm-engine-<keystr> tag and shall contain the number of busy cycles for the given
engine.
Values are not required to be constantly monotonic if it makes the driver
@@ -117,16 +112,60 @@
was previously read, userspace is expected to stay with that larger previous
value until a monotonic update is seen.
-- drm-maxfreq-<str> <uint> [Hz|MHz|KHz]
+- drm-maxfreq-<keystr>: <uint> [Hz|MHz|KHz]
Engine identifier string must be the same as the one specified in the
-drm-engine-<str> tag and shall contain the maximum frequency for the given
-engine. Taken together with drm-cycles-<str>, this can be used to calculate
-percentage utilization of the engine, whereas drm-engine-<str> only reflects
+drm-engine-<keystr> tag and shall contain the maximum frequency for the given
+engine. Taken together with drm-cycles-<keystr>, this can be used to calculate
+percentage utilization of the engine, whereas drm-engine-<keystr> only reflects
time active without considering what frequency the engine is operating as a
percentage of it's maximum frequency.
+Memory
+^^^^^^
+
+- drm-memory-<region>: <uint> [KiB|MiB]
+
+Each possible memory type which can be used to store buffer objects by the
+GPU in question shall be given a stable and unique name to be returned as the
+string here. The name "memory" is reserved to refer to normal system memory.
+
+Value shall reflect the amount of storage currently consumed by the buffer
+objects belong to this client, in the respective memory region.
+
+Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
+indicating kibi- or mebi-bytes.
+
+- drm-shared-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that are shared with another file (ie. have more
+than a single handle).
+
+- drm-total-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that including shared and private memory.
+
+- drm-resident-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that are resident in the specified region.
+
+- drm-purgeable-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that are purgeable.
+
+- drm-active-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that are active on one or more engines.
+
+Implementation Details
+======================
+
+Drivers should use drm_show_fdinfo() in their `struct file_operations`, and
+implement &drm_driver.show_fdinfo if they wish to provide any stats which
+are not provided by drm_show_fdinfo(). But even driver specific stats should
+be documented above and where possible, aligned with other drivers.
+
Driver specific implementations
-===============================
+-------------------------------
:ref:`i915-usage-stats`
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 4767197..e4f7b00 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -31,3 +31,7 @@
.. toctree::
i915_vm_bind.rst
+
+.. toctree::
+
+ xe.rst
diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst
new file mode 100644
index 0000000..2516fe1
--- /dev/null
+++ b/Documentation/gpu/rfc/xe.rst
@@ -0,0 +1,235 @@
+==========================
+Xe – Merge Acceptance Plan
+==========================
+Xe is a new driver for Intel GPUs that supports both integrated and
+discrete platforms starting with Tiger Lake (first Intel Xe Architecture).
+
+This document aims to establish a merge plan for the Xe, by writing down clear
+pre-merge goals, in order to avoid unnecessary delays.
+
+Xe – Overview
+=============
+The main motivation of Xe is to have a fresh base to work from that is
+unencumbered by older platforms, whilst also taking the opportunity to
+rearchitect our driver to increase sharing across the drm subsystem, both
+leveraging and allowing us to contribute more towards other shared components
+like TTM and drm/scheduler.
+
+This is also an opportunity to start from the beginning with a clean uAPI that is
+extensible by design and already aligned with the modern userspace needs. For
+this reason, the memory model is solely based on GPU Virtual Address space
+bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting
+explicit synchronization. With persistent mapping across the execution, the
+userspace does not need to provide a list of all required mappings during each
+submission.
+
+The new driver leverages a lot from i915. As for display, the intent is to share
+the display code with the i915 driver so that there is maximum reuse there.
+
+As for the power management area, the goal is to have a much-simplified support
+for the system suspend states (S-states), PCI device suspend states (D-states),
+GPU/Render suspend states (R-states) and frequency management. It should leverage
+as much as possible all the existent PCI-subsystem infrastructure (pm and
+runtime_pm) and underlying firmware components such PCODE and GuC for the power
+states and frequency decisions.
+
+Repository:
+
+https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next)
+
+Xe – Platforms
+==============
+Currently, Xe is already functional and has experimental support for multiple
+platforms starting from Tiger Lake, with initial support in userspace implemented
+in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO
+(for OpenCL and Level0).
+
+During a transition period, platforms will be supported by both Xe and i915.
+However, the force_probe mechanism existent in both drivers will allow only one
+official and by-default probe at a given time.
+
+For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of
+i915, the following set of parameters need to be used:
+
+```
+i915.force_probe=!5690 xe.force_probe=5690
+```
+
+In both drivers, the ‘.require_force_probe’ protection forces the user to use the
+force_probe parameter while the driver is under development. This protection is
+only removed when the support for the platform and the uAPI are stable. Stability
+which needs to be demonstrated by CI results.
+
+In order to avoid user space regressions, i915 will continue to support all the
+current platforms that are already out of this protection. Xe support will be
+forever experimental and dependent on the usage of force_probe for these
+platforms.
+
+When the time comes for Xe, the protection will be lifted on Xe and kept in i915.
+
+Xe driver will be protected with both STAGING Kconfig and force_probe. Changes in
+the uAPI are expected while the driver is behind these protections. STAGING will
+be removed when the driver uAPI gets to a mature state where we can guarantee the
+‘no regression’ rule. Then force_probe will be lifted only for future platforms
+that will be productized with Xe driver, but not with i915.
+
+Xe – Pre-Merge Goals
+====================
+
+Drm_scheduler
+-------------
+Xe primarily uses Firmware based scheduling (GuC FW). However, it will use
+drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to
+resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is
+not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and
+drm_sched_entity.
+
+Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but
+some consensus needs to be reached between Xe and other community drivers that
+could also benefit from this work, for coupling FW based/assisted submission such
+as the ARM’s new Mali GPU driver, and others.
+
+As a key measurable result, the patch series introducing Xe itself shall not
+depend on any other patch touching drm_scheduler itself that was not yet merged
+through drm-misc. This, by itself, already includes the reach of an agreement for
+uniform 1 to 1 relationship implementation / usage across drivers.
+
+GPU VA
+------
+Two main goals of Xe are meeting together here:
+
+1) Have an uAPI that aligns with modern UMD needs.
+
+2) Early upstream engagement.
+
+RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping
+track of GPU virtual address mappings. This is still not merged upstream, but
+this aligns very well with our goals and with our VM_BIND. The engagement with
+upstream and the port of Xe towards GPUVA is already ongoing.
+
+As a key measurable result, Xe needs to be aligned with the GPU VA and working in
+our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA
+related patch should be independent and present on dri-devel or acked by
+maintainers to go along with the first Xe pull request towards drm-next.
+
+DRM_VM_BIND
+-----------
+Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to
+fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the
+development of a common new drm_infrastructure. However, the Xe team needs to
+engage with the community to explore the options of a common API.
+
+As a key measurable result, the DRM_VM_BIND needs to be documented in this file
+below, or this entire block deleted if the consensus is for independent drivers
+vm_bind ioctls.
+
+Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
+Xe merged, it is mandatory to enforce the overall locking scheme for all major
+structs and list (so vm and vma). So, a consensus is needed, and possibly some
+common helpers. If helpers are needed, they should be also documented in this
+document.
+
+ASYNC VM_BIND
+-------------
+Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
+Xe merged, it is mandatory to have a consensus with other drivers and Mesa.
+It needs to be clear how to handle async VM_BIND and interactions with userspace
+memory fences. Ideally with helper support so people don't get it wrong in all
+possible ways.
+
+As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of
+various flavors, error handling and a sample API should be documented here or in
+a separate document pointed to by this document.
+
+Userptr integration and vm_bind
+-------------------------------
+Different drivers implement different ways of dealing with execution of userptr.
+With multiple drivers currently introducing support to VM_BIND, the goal is to
+aim for a DRM consensus on what’s the best way to have that support. To some
+extent this is already getting addressed itself with the GPUVA where likely the
+userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr.
+However, there are more aspects around the rules for that and the usage of
+mmu_notifiers, locking and other aspects.
+
+This task here has the goal of introducing a documentation of the basic rules.
+
+The documentation *needs* to first live in this document (API session below) and
+then moved to another more specific document or at Xe level or at DRM level.
+
+Documentation should include:
+
+ * The userptr part of the VM_BIND api.
+
+ * Locking, including the page-faulting case.
+
+ * O(1) complexity under VM_BIND.
+
+Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when
+the second driver supporting VM_BIND+userptr appears. Details to be defined when
+the time comes.
+
+Long running compute: minimal data structure/scaffolding
+--------------------------------------------------------
+The generic scheduler code needs to include the handling of endless compute
+contexts, with the minimal scaffolding for preempt-ctx fences (probably on the
+drm_sched_entity) and making sure drm_scheduler can cope with the lack of job
+completion fence.
+
+The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with
+this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any
+drm driver, including Xe, could re-use and add their own individual needs on top
+in a next stage. However, this should not block the initial merge.
+
+This is a non-blocker item since the driver without the support for the long
+running compute enabled is not a showstopper.
+
+Display integration with i915
+-----------------------------
+In order to share the display code with the i915 driver so that there is maximum
+reuse, the i915/display/ code is built twice, once for i915.ko and then for
+xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs'
+depending on the build target. The goal is to refactor both Xe and i915/display
+code simultaneously in order to get a clean result before they land upstream, so
+that display can already be part of the initial pull request towards drm-next.
+
+However, display code should not gate the acceptance of Xe in upstream. Xe
+patches will be refactored in a way that display code can be removed, if needed,
+from the first pull request of Xe towards drm-next. The expectation is that when
+both drivers are part of the drm-tip, the introduction of cleaner patches will be
+easier and speed up.
+
+Drm_exec
+--------
+Helper to make dma_resv locking for a big number of buffers is getting removed in
+the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/
+If that happens, Xe needs to change and incorporate the changes in the driver.
+The goal is to engage with the Community to understand if the best approach is to
+move that to the drivers that are using it or if we should keep the helpers in
+place waiting for Xe to get merged.
+
+This item ties into the GPUVA, VM_BIND, and even long-running compute support.
+
+As a key measurable result, we need to have a community consensus documented in
+this document and the Xe driver prepared for the changes, if necessary.
+
+Dev_coredump
+------------
+
+Xe needs to align with other drivers on the way that the error states are
+dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump
+infrastructure to report error states, since it produces a standardized way
+by exposing a virtual and temporary /sys/class/devcoredump device.
+
+As the key measurable result, Xe driver needs to provide GPU snapshots captured
+at hang time through devcoredump, but without depending on any core modification
+of devcoredump infrastructure itself.
+
+Later, when we are in-tree, the goal is to collaborate with devcoredump
+infrastructure with overall possible improvements, like multiple file support
+for better organization of the dumps, snapshot support, dmesg extra print,
+and whatever may make sense and help the overall infrastructure.
+
+Xe – uAPI high level overview
+=============================
+
+...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached.
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 1f8a5eb..68bdafa 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -276,11 +276,8 @@
- Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
setup code can't be deleted.
-- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
- atomic drivers we could check for valid formats by calling
- drm_plane_check_pixel_format() against all planes, and pass if any plane
- supports the format. For non-atomic that's not possible since like the format
- list for the primary plane is fake and we'd therefor reject valid formats.
+- Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for
+ valid formats for atomic drivers.
- Many drivers subclass drm_framebuffer, we'd need a embedding compatible
version of the varios drm_gem_fb_create functions. Maybe called
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 49db221..ba04ac7 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -118,14 +118,9 @@
There's lots of plane features we could add support for:
-- ARGB format on primary plane: blend the primary plane into background with
- translucent alpha.
-
- Add background color KMS property[Good to get started].
-- Full alpha blending on all planes.
-
-- Rotation, scaling.
+- Scaling.
- Additional buffer formats, especially YUV formats for video like NV12.
Low/high bpp RGB formats would also be interesting.
diff --git a/Documentation/hwmon/aht10.rst b/Documentation/hwmon/aht10.rst
index 4e198c5..213644b 100644
--- a/Documentation/hwmon/aht10.rst
+++ b/Documentation/hwmon/aht10.rst
@@ -5,32 +5,42 @@
Supported chips:
- * Aosong AHT10
+ * Aosong AHT10/AHT20
Prefix: 'aht10'
Addresses scanned: None
- Datasheet:
+ Datasheet(AHT10):
Chinese: http://www.aosong.com/userfiles/files/media/AHT10%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C%20A3%2020201210.pdf
English: https://server4.eca.ir/eshop/AHT10/Aosong_AHT10_en_draft_0c.pdf
+ Datasheet(AHT20):
+
+ English: http://www.aosong.com/userfiles/files/media/Data%20Sheet%20AHT20.pdf
+
Author: Johannes Cornelis Draaijer <jcdra1@gmail.com>
Description
-----------
-The AHT10 is a Temperature and Humidity sensor
+The AHT10/AHT20 is a Temperature and Humidity sensor
The address of this i2c device may only be 0x38
+Special Features
+----------------
+
+AHT20 has additional CRC8 support which is sent as the last byte of the sensor
+values.
+
Usage Notes
-----------
-This driver does not probe for AHT10 devices, as there is no reliable
-way to determine if an i2c chip is or isn't an AHT10. The device has
+This driver does not probe for AHT10/ATH20 devices, as there is no reliable
+way to determine if an i2c chip is or isn't an AHT10/AHT20. The device has
to be instantiated explicitly with the address 0x38. See
Documentation/i2c/instantiating-devices.rst for details.
diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst
index 14b3785..94dc2d9 100644
--- a/Documentation/hwmon/aquacomputer_d5next.rst
+++ b/Documentation/hwmon/aquacomputer_d5next.rst
@@ -12,6 +12,7 @@
* Aquacomputer Octo fan controller
* Aquacomputer Quadro fan controller
* Aquacomputer High Flow Next sensor
+* Aquacomputer Leakshield leak prevention system
* Aquacomputer Aquastream XT watercooling pump
* Aquacomputer Aquastream Ultimate watercooling pump
* Aquacomputer Poweradjust 3 fan controller
@@ -57,6 +58,11 @@
A temperature sensor can be connected to it, in which case it provides its reading
and an estimation of the dissipated/absorbed power in the liquid cooling loop.
+The Leakshield exposes two temperature sensors and coolant pressure (current, min, max and
+target readings). It also exposes the estimated reservoir volume and how much of it is
+filled with coolant. Pump RPM and flow can be set to enhance on-device calculations,
+but this is not yet implemented here.
+
The Aquastream XT pump exposes temperature readings for the coolant, external sensor
and fan IC. It also exposes pump and fan speeds (in RPM), voltages, as well as pump
current.
@@ -83,6 +89,9 @@
temp[1-20]_input Physical/virtual temperature sensors (in millidegrees Celsius)
temp[1-8]_offset Temperature sensor correction offset (in millidegrees Celsius)
fan[1-8]_input Pump/fan speed (in RPM) / Flow speed (in dL/h)
+fan1_min Minimal fan speed (in RPM)
+fan1_max Maximal fan speed (in RPM)
+fan1_target Target fan speed (in RPM)
fan5_pulses Quadro flow sensor pulses
power[1-8]_input Pump/fan power (in micro Watts)
in[0-7]_input Pump/fan voltage (in milli Volts)
diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index c92c1d3..7e3cd5b 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -14,6 +14,7 @@
* ROG CROSSHAIR VIII FORMULA
* ROG CROSSHAIR VIII HERO
* ROG CROSSHAIR VIII IMPACT
+ * ROG CROSSHAIR X670E HERO
* ROG MAXIMUS XI HERO
* ROG MAXIMUS XI HERO (WI-FI)
* ROG STRIX B550-E GAMING
diff --git a/Documentation/hwmon/corsair-psu.rst b/Documentation/hwmon/corsair-psu.rst
index c389bd2..16db34d 100644
--- a/Documentation/hwmon/corsair-psu.rst
+++ b/Documentation/hwmon/corsair-psu.rst
@@ -15,11 +15,11 @@
Corsair HX850i
- Corsair HX1000i (revision 1 and 2)
+ Corsair HX1000i (Series 2022 and 2023)
Corsair HX1200i
- Corsair HX1500i
+ Corsair HX1500i (Series 2022 and 2023)
Corsair RM550i
@@ -69,6 +69,8 @@
power2_input Power usage of the 12v psu rail
power3_input Power usage of the 5v psu rail
power4_input Power usage of the 3.3v psu rail
+pwm1 PWM value, read only
+pwm1_enable PWM mode, read only
temp1_input Temperature of the psu vrm component
temp1_crit Temperature max cirtical value of the psu vrm component
temp2_input Temperature of the psu case
@@ -78,11 +80,14 @@
Usage Notes
-----------
-It is an USB HID device, so it is auto-detected and supports hot-swapping.
+It is an USB HID device, so it is auto-detected, supports hot-swapping and
+several devices at once.
Flickering values in the rail voltage levels can be an indicator for a failing
-PSU. The driver also provides some additional useful values via debugfs, which
-do not fit into the hwmon class.
+PSU. Accordingly to the default automatic fan speed plan the fan starts at about
+30% of the wattage rating. If this does not happen, a fan failure is likely. The
+driver also provides some additional useful values via debugfs, which do not fit
+into the hwmon class.
Debugfs entries
---------------
diff --git a/Documentation/hwmon/hp-wmi-sensors.rst b/Documentation/hwmon/hp-wmi-sensors.rst
new file mode 100644
index 0000000..a6bca9a
--- /dev/null
+++ b/Documentation/hwmon/hp-wmi-sensors.rst
@@ -0,0 +1,140 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+.. include:: <isonum.txt>
+
+===========================
+Linux HP WMI Sensors Driver
+===========================
+
+:Copyright: |copy| 2023 James Seo <james@equiv.tech>
+
+Description
+===========
+
+Hewlett-Packard (and some HP Compaq) business-class computers report hardware
+monitoring information via Windows Management Instrumentation (WMI).
+This driver exposes that information to the Linux hwmon subsystem, allowing
+userspace utilities like ``sensors`` to gather numeric sensor readings.
+
+sysfs interface
+===============
+
+When the driver is loaded, it discovers the sensors available on the
+system and creates the following sysfs attributes as necessary within
+``/sys/class/hwmon/hwmon[X]``:
+
+(``[X]`` is some number that depends on other system components.)
+
+======================= ======= ===================================
+Name Perm Description
+======================= ======= ===================================
+``curr[X]_input`` RO Current in milliamperes (mA).
+``curr[X]_label`` RO Current sensor label.
+``fan[X]_input`` RO Fan speed in RPM.
+``fan[X]_label`` RO Fan sensor label.
+``fan[X]_fault`` RO Fan sensor fault indicator.
+``fan[X]_alarm`` RO Fan sensor alarm indicator.
+``in[X]_input`` RO Voltage in millivolts (mV).
+``in[X]_label`` RO Voltage sensor label.
+``temp[X]_input`` RO Temperature in millidegrees Celsius
+ (m\ |deg|\ C).
+``temp[X]_label`` RO Temperature sensor label.
+``temp[X]_fault`` RO Temperature sensor fault indicator.
+``temp[X]_alarm`` RO Temperature sensor alarm indicator.
+``intrusion[X]_alarm`` RW Chassis intrusion alarm indicator.
+======================= ======= ===================================
+
+``fault`` attributes
+ Reading ``1`` instead of ``0`` as the ``fault`` attribute for a sensor
+ indicates that it has encountered some issue during operation such that
+ measurements from it should not be trusted. If a sensor with the fault
+ condition recovers later, reading this attribute will return ``0`` again.
+
+``alarm`` attributes
+ Reading ``1`` instead of ``0`` as the ``alarm`` attribute for a sensor
+ indicates that one of the following has occurred, depending on its type:
+
+ - ``fan``: The fan has stalled or has been disconnected while running.
+ - ``temp``: The sensor reading has reached a critical threshold.
+ The exact threshold is system-dependent.
+ - ``intrusion``: The system's chassis has been opened.
+
+ After ``1`` is read from an ``alarm`` attribute, the attribute resets itself
+ and returns ``0`` on subsequent reads. As an exception, an
+ ``intrusion[X]_alarm`` can only be manually reset by writing ``0`` to it.
+
+debugfs interface
+=================
+
+.. warning:: The debugfs interface is subject to change without notice
+ and is only available when the kernel is compiled with
+ ``CONFIG_DEBUG_FS`` defined.
+
+The standard hwmon interface in sysfs exposes sensors of several common types
+that are connected as of driver initialization. However, there are usually
+other sensors in WMI that do not meet these criteria. In addition, a number of
+system-dependent "platform events objects" used for ``alarm`` attributes may
+be present. A debugfs interface is therefore provided for read-only access to
+all available HP WMI sensors and platform events objects.
+
+``/sys/kernel/debug/hp-wmi-sensors-[X]/sensor``
+contains one numbered entry per sensor with the following attributes:
+
+=============================== =======================================
+Name Example
+=============================== =======================================
+``name`` ``CPU0 Fan``
+``description`` ``Reports CPU0 fan speed``
+``sensor_type`` ``12``
+``other_sensor_type`` (an empty string)
+``operational_status`` ``2``
+``possible_states`` ``Normal,Caution,Critical,Not Present``
+``current_state`` ``Normal``
+``base_units`` ``19``
+``unit_modifier`` ``0``
+``current_reading`` ``1008``
+``rate_units`` ``0`` (only exists on some systems)
+=============================== =======================================
+
+If platform events objects are available,
+``/sys/kernel/debug/hp-wmi-sensors-[X]/platform_events``
+contains one numbered entry per object with the following attributes:
+
+=============================== ====================
+Name Example
+=============================== ====================
+``name`` ``CPU0 Fan Stall``
+``description`` ``CPU0 Fan Speed``
+``source_namespace`` ``root\wmi``
+``source_class`` ``HPBIOS_BIOSEvent``
+``category`` ``3``
+``possible_severity`` ``25``
+``possible_status`` ``5``
+=============================== ====================
+
+These represent the properties of the underlying ``HPBIOS_BIOSNumericSensor``
+and ``HPBIOS_PlatformEvents`` WMI objects, which vary between systems.
+See [#]_ for more details and Managed Object Format (MOF) definitions.
+
+Known issues and limitations
+============================
+
+- If the existing hp-wmi driver for non-business-class HP systems is already
+ loaded, ``alarm`` attributes will be unavailable even on systems that
+ support them. This is because the same WMI event GUID used by this driver
+ for ``alarm`` attributes is used on those systems for e.g. laptop hotkeys.
+- Dubious sensor hardware and inconsistent BIOS WMI implementations have been
+ observed to cause inaccurate readings and peculiar behavior, such as alarms
+ failing to occur or occurring only once per boot.
+- Only temperature, fan speed, and intrusion sensor types have been seen in
+ the wild so far. Support for voltage and current sensors is therefore
+ provisional.
+- Although HP WMI sensors may claim to be of any type, any oddball sensor
+ types unknown to hwmon will not be supported.
+
+References
+==========
+
+.. [#] Hewlett-Packard Development Company, L.P.,
+ "HP Client Management Interface Technical White Paper", 2005. [Online].
+ Available: https://h20331.www2.hp.com/hpsub/downloads/cmi_whitepaper.pdf
diff --git a/Documentation/hwmon/hwmon-kernel-api.rst b/Documentation/hwmon/hwmon-kernel-api.rst
index c2d1e02..6cacf7da 100644
--- a/Documentation/hwmon/hwmon-kernel-api.rst
+++ b/Documentation/hwmon/hwmon-kernel-api.rst
@@ -66,7 +66,7 @@
devm_hwmon_device_unregister does not normally have to be called. It is only
needed for error handling, and only needed if the driver probe fails after
-the call to hwmon_device_register_with_info and if the automatic (device
+the call to devm_hwmon_device_register_with_info and if the automatic (device
managed) removal would be too late.
All supported hwmon device registration functions only accept valid device
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index fa1208c..042e1cf 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -9,7 +9,6 @@
hwmon-kernel-api
pmbus-core
- inspur-ipsps1
submitting-patches
sysfs-interface
userspace-tools
@@ -78,6 +77,7 @@
gl518sm
gxp-fan-ctrl
hih6130
+ hp-wmi-sensors
ibmaem
ibm-cffps
ibmpowernv
@@ -85,6 +85,7 @@
ina2xx
ina238
ina3221
+ inspur-ipsps1
intel-m10-bmc-hwmon
ir35221
ir38064
@@ -140,6 +141,7 @@
max31760
max31785
max31790
+ max31827
max34440
max6620
max6639
diff --git a/Documentation/hwmon/max31827.rst b/Documentation/hwmon/max31827.rst
new file mode 100644
index 0000000..b0971d0
--- /dev/null
+++ b/Documentation/hwmon/max31827.rst
@@ -0,0 +1,90 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver max31827
+======================
+
+Supported chips:
+
+ * Maxim MAX31827
+
+ Prefix: 'max31827'
+
+ Addresses scanned: I2C 0x40 - 0x5f
+
+ Datasheet: Publicly available at the Analog Devices website
+
+ * Maxim MAX31828
+
+ Prefix: 'max31828'
+
+ Addresses scanned: I2C 0x40 - 0x5f
+
+ Datasheet: Publicly available at the Analog Devices website
+
+ * Maxim MAX31829
+
+ Prefix: 'max31829'
+
+ Addresses scanned: I2C 0x40 - 0x5f
+
+ Datasheet: Publicly available at the Analog Devices website
+
+
+Authors:
+ - Daniel Matyas <daniel.matyas@analog.com>
+
+Description
+-----------
+
+The chips supported by this driver are quite similar. The only difference
+between them is found in the default power-on behaviour of the chips. While the
+MAX31827's fault queue is set to 1, the other two chip's fault queue is set to
+4. Besides this, the MAX31829's alarm active state is high, while the other two
+chip's alarms are active on low. It is important to note that the chips can be
+configured to operate in the same manner with 1 write operation to the
+configuration register. From here on, we will refer to all these chips as
+MAX31827.
+
+MAX31827 implements a temperature sensor with a 6 WLP packaging scheme. This
+sensor measures the temperature of the chip itself.
+
+MAX31827 has low and over temperature alarms with an effective value and a
+hysteresis value: -40 and -30 degrees for under temperature alarm and +100 and
++90 degrees for over temperature alarm.
+
+The alarm can be configured in comparator and interrupt mode. Currently only
+comparator mode is implemented. In Comparator mode, the OT/UT status bits have a
+value of 1 when the temperature rises above the TH value or falls below TL,
+which is also subject to the Fault Queue selection. OT status returns to 0 when
+the temperature drops below the TH_HYST value or when shutdown mode is entered.
+Similarly, UT status returns to 0 when the temperature rises above TL_HYST value
+or when shutdown mode is entered.
+
+Putting the MAX31827 into shutdown mode also resets the OT/UT status bits. Note
+that if the mode is changed while OT/UT status bits are set, an OT/UT status
+reset may be required before it begins to behave normally. To prevent this,
+it is recommended to perform a read of the configuration/status register to
+clear the status bits before changing the operating mode.
+
+The conversions can be manual with the one-shot functionality and automatic with
+a set frequency. When powered on, the chip measures temperatures with 1 conv/s.
+Enabling the device when it is already enabled has the side effect of setting
+the conversion frequency to 1 conv/s. The conversion time varies depending on
+the resolution. The conversion time doubles with every bit of increased
+resolution. For 10 bit resolution 35ms are needed, while for 12 bit resolution
+(default) 140ms. When chip is in shutdown mode and a read operation is
+requested, one-shot is triggered, the device waits for 140 (conversion time) + 1
+(error) ms, and only after that is the temperature value register read.
+
+The LSB of the temperature values is 0.0625 degrees Celsius, but the values of
+the temperatures are displayed in milli-degrees. This means, that some data is
+lost. The step between 2 consecutive values is 62 or 63. This effect can be seen
+in the writing of alarm values too. For positive numbers the user-input value
+will always be rounded down to the nearest possible value, for negative numbers
+the user-input will always be rounded up to the nearest possible value.
+
+Notes
+-----
+
+Currently fault queue, alarm polarity and resolution cannot be modified.
+PEC is not implemented either.
diff --git a/Documentation/hwmon/oxp-sensors.rst b/Documentation/hwmon/oxp-sensors.rst
index 566a8d5..3adeb74 100644
--- a/Documentation/hwmon/oxp-sensors.rst
+++ b/Documentation/hwmon/oxp-sensors.rst
@@ -19,18 +19,32 @@
different. Aya Neo devices preceding the AIR may not be supportable as the EC
model is different and do not appear to have manual control capabilities.
+Some models have a toggle for changing the behaviour of the "Turbo/Silent"
+button of the device. It will change the key event that it triggers with
+a flip of the `tt_toggle` attribute. See below for boards that support this
+function.
+
Supported devices
-----------------
Currently the driver supports the following handhelds:
- AOK ZOE A1
+ - AOK ZOE A1 PRO
+ - Aya Neo 2
- Aya Neo AIR
- Aya Neo AIR Pro
+ - Aya Neo Geek
- OneXPlayer AMD
- OneXPlayer mini AMD
- OneXPlayer mini AMD PRO
+"Turbo/Silent" button behaviour toggle is only supported on:
+ - AOK ZOE A1
+ - AOK ZOE A1 PRO
+ - OneXPlayer mini AMD (only with updated alpha BIOS)
+ - OneXPlayer mini AMD PRO
+
Sysfs entries
-------------
@@ -47,3 +61,10 @@
Read Write. Read this attribute to see current duty cycle in the range [0-255].
When pwm1_enable is set to "1" (manual) write any value in the range [0-255]
to set fan speed.
+
+tt_toggle
+ Read Write. Read this attribute to check the status of the turbo/silent
+ button behaviour function. Write "1" to activate the switch and "0" to
+ deactivate it. The specific keycodes and behaviour is specific to the device
+ both with this function on and off. This attribute is attached to the platform
+ driver and not to the hwmon driver (/sys/devices/platform/oxp-platform/tt_toggle)
diff --git a/Documentation/hwmon/sht3x.rst b/Documentation/hwmon/sht3x.rst
index 95a850d..87864ff 100644
--- a/Documentation/hwmon/sht3x.rst
+++ b/Documentation/hwmon/sht3x.rst
@@ -28,15 +28,8 @@
addresses 0x44 or 0x45, depending on the wiring. See
Documentation/i2c/instantiating-devices.rst for methods to instantiate the device.
-There are two options configurable by means of sht3x_platform_data:
-
-1. blocking (pull the I2C clock line down while performing the measurement) or
- non-blocking mode. Blocking mode will guarantee the fastest result but
- the I2C bus will be busy during that time. By default, non-blocking mode
- is used. Make sure clock-stretching works properly on your device if you
- want to use blocking mode.
-2. high or low accuracy. High accuracy is used by default and using it is
- strongly recommended.
+Even if sht3x sensor supports clock-strech(blocking mode) and non-strench
+(non-blocking mode) in single-shot mode, this driver only supports the latter.
The sht3x sensor supports a single shot mode as well as 5 periodic measure
modes, which can be controlled with the update_interval sysfs interface.
@@ -85,4 +78,11 @@
update_interval: update interval, 0 for single shot, interval in msec
for periodic measurement. If the interval is not supported
by the sensor, the next faster interval is chosen
+repeatability: write or read repeatability, higher repeatability means
+ longer measurement duration, lower noise level and
+ larger energy consumption:
+
+ - 0: low repeatability
+ - 1: medium repeatability
+ - 2: high repeatability
=================== ============================================================
diff --git a/Documentation/i2c/busses/i2c-i801.rst b/Documentation/i2c/busses/i2c-i801.rst
index ab9e850e..e76e68c 100644
--- a/Documentation/i2c/busses/i2c-i801.rst
+++ b/Documentation/i2c/busses/i2c-i801.rst
@@ -46,7 +46,7 @@
* Intel Emmitsburg (PCH)
* Intel Alder Lake (PCH)
* Intel Raptor Lake (PCH)
- * Intel Meteor Lake (SOC)
+ * Intel Meteor Lake (SOC and PCH)
Datasheets: Publicly available at the Intel website
diff --git a/Documentation/input/devices/xpad.rst b/Documentation/input/devices/xpad.rst
index 173c2ac..a480bc7 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -4,16 +4,16 @@
This driver exposes all first-party and third-party Xbox compatible
controllers. It has a long history and has enjoyed considerable usage
-as Window's xinput library caused most PC games to focus on Xbox
+as Windows' xinput library caused most PC games to focus on Xbox
controller compatibility.
Due to backwards compatibility all buttons are reported as digital.
-This only effects Original Xbox controllers. All later controller models
+This only affects Original Xbox controllers. All later controller models
have only digital face buttons.
Rumble is supported on some models of Xbox 360 controllers but not of
Original Xbox controllers nor on Xbox One controllers. As of writing
-the Xbox One's rumble protocol has not been reverse engineered but in
+the Xbox One's rumble protocol has not been reverse-engineered but in
the future could be supported.
@@ -82,7 +82,7 @@
Unknown Controllers
-------------------
-If you have an unknown xbox controller, it should work just fine with
+If you have an unknown Xbox controller, it should work just fine with
the default settings.
HOWEVER if you have an unknown dance pad not listed below, it will not
@@ -123,7 +123,7 @@
Thanks to the trip splitter found on the cable you don't even need to cut the
original one. You can buy an extension cable and cut that instead. That way,
-you can still use the controller with your X-Box, if you have one ;)
+you can still use the controller with your Xbox, if you have one ;)
diff --git a/Documentation/input/gamepad.rst b/Documentation/input/gamepad.rst
index 71019de..eca17a7 100644
--- a/Documentation/input/gamepad.rst
+++ b/Documentation/input/gamepad.rst
@@ -184,7 +184,7 @@
Many pads also have a third button which is branded or has a special symbol
and meaning. Such buttons are mapped as BTN_MODE. Examples are the Nintendo
- "HOME" button, the XBox "X"-button or Sony "PS" button.
+ "HOME" button, the Xbox "X" button or the Sony PlayStation "PS" button.
- Rumble:
diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst
index 2a22ddb..bd90640 100644
--- a/Documentation/kbuild/kbuild.rst
+++ b/Documentation/kbuild/kbuild.rst
@@ -150,6 +150,12 @@
The value of KBUILD_DEBARCH is assumed (not checked) to be a valid Debian
architecture.
+KDOCFLAGS
+---------
+Specify extra (warning/error) flags for kernel-doc checks during the build,
+see scripts/kernel-doc for which flags are supported. Note that this doesn't
+(currently) apply to documentation builds.
+
ARCH
----
Set ARCH to the architecture to be built.
diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst
index ce57254..3ade16c 100644
--- a/Documentation/leds/index.rst
+++ b/Documentation/leds/index.rst
@@ -17,6 +17,7 @@
uleds
leds-blinkm
+ leds-cht-wcove
leds-el15203000
leds-lm3556
leds-lp3944
diff --git a/Documentation/leds/leds-cht-wcove.rst b/Documentation/leds/leds-cht-wcove.rst
new file mode 100644
index 0000000..5ec7cb6
--- /dev/null
+++ b/Documentation/leds/leds-cht-wcove.rst
@@ -0,0 +1,38 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================================================
+Kernel driver for Intel Cherry Trail Whiskey Cove PMIC LEDs
+===========================================================
+
+/sys/class/leds/<led>/hw_pattern
+--------------------------------
+
+Specify a hardware pattern for the Whiskey Cove PMIC LEDs.
+
+The only supported pattern is hardware breathing mode::
+
+ "0 2000 1 2000"
+
+ ^
+ |
+ Max-| ---
+ | / \
+ | / \
+ | / \ /
+ | / \ /
+ Min-|- ---
+ |
+ 0------2------4--> time (sec)
+
+The rise and fall times must be the same value.
+Supported values are 2000, 1000, 500 and 250 for
+breathing frequencies of 1/4, 1/2, 1 and 2 Hz.
+
+The set pattern only controls the timing. For max brightness the last
+set brightness is used and the max brightness can be changed
+while breathing by writing the brightness attribute.
+
+This is just like how blinking works in the LED subsystem,
+for both sw and hw blinking the brightness can also be changed
+while blinking. Breathing on this hw really is just a variant
+mode of blinking.
diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
index cd155ea..5db620e 100644
--- a/Documentation/leds/leds-class.rst
+++ b/Documentation/leds/leds-class.rst
@@ -169,6 +169,87 @@
should completely turn off the LED and cancel the previously programmed
hardware blinking function, if any.
+Hardware driven LEDs
+====================
+
+Some LEDs can be programmed to be driven by hardware. This is not
+limited to blink but also to turn off or on autonomously.
+To support this feature, a LED needs to implement various additional
+ops and needs to declare specific support for the supported triggers.
+
+With hw control we refer to the LED driven by hardware.
+
+LED driver must define the following value to support hw control:
+
+ - hw_control_trigger:
+ unique trigger name supported by the LED in hw control
+ mode.
+
+LED driver must implement the following API to support hw control:
+ - hw_control_is_supported:
+ check if the flags passed by the supported trigger can
+ be parsed and activate hw control on the LED.
+
+ Return 0 if the passed flags mask is supported and
+ can be set with hw_control_set().
+
+ If the passed flags mask is not supported -EOPNOTSUPP
+ must be returned, the LED trigger will use software
+ fallback in this case.
+
+ Return a negative error in case of any other error like
+ device not ready or timeouts.
+
+ - hw_control_set:
+ activate hw control. LED driver will use the provided
+ flags passed from the supported trigger, parse them to
+ a set of mode and setup the LED to be driven by hardware
+ following the requested modes.
+
+ Set LED_OFF via the brightness_set to deactivate hw control.
+
+ Return 0 on success, a negative error number on failing to
+ apply flags.
+
+ - hw_control_get:
+ get active modes from a LED already in hw control, parse
+ them and set in flags the current active flags for the
+ supported trigger.
+
+ Return 0 on success, a negative error number on failing
+ parsing the initial mode.
+ Error from this function is NOT FATAL as the device may
+ be in a not supported initial state by the attached LED
+ trigger.
+
+ - hw_control_get_device:
+ return the device associated with the LED driver in
+ hw control. A trigger might use this to match the
+ returned device from this function with a configured
+ device for the trigger as the source for blinking
+ events and correctly enable hw control.
+ (example a netdev trigger configured to blink for a
+ particular dev match the returned dev from get_device
+ to set hw control)
+
+ Returns a pointer to a struct device or NULL if nothing
+ is currently attached.
+
+LED driver can activate additional modes by default to workaround the
+impossibility of supporting each different mode on the supported trigger.
+Examples are hardcoding the blink speed to a set interval, enable special
+feature like bypassing blink if some requirements are not met.
+
+A trigger should first check if the hw control API are supported by the LED
+driver and check if the trigger is supported to verify if hw control is possible,
+use hw_control_is_supported to check if the flags are supported and only at
+the end use hw_control_set to activate hw control.
+
+A trigger can use hw_control_get to check if a LED is already in hw control
+and init their flags.
+
+When the LED is in hw control, no software blink is possible and doing so
+will effectively disable hw control.
Known Issues
============
diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt
index e9c30dc..67b4470 100644
--- a/Documentation/leds/well-known-leds.txt
+++ b/Documentation/leds/well-known-leds.txt
@@ -58,6 +58,7 @@
* System notification
+Good: "rgb:status"
Legacy: "status-led:{red,green,blue}" (Motorola Droid 4)
Legacy: "lp5523:{r,g,b}" (Nokia N900)
@@ -65,7 +66,7 @@
* Power management
-Good: "platform:*:charging" (allwinner sun50i)
+Good: "platform:*:charging" (allwinner sun50i, leds-cht-wcove)
* Screen
diff --git a/Documentation/maintainer/configure-git.rst b/Documentation/maintainer/configure-git.rst
index 80ae5030..ec0ddfb 100644
--- a/Documentation/maintainer/configure-git.rst
+++ b/Documentation/maintainer/configure-git.rst
@@ -56,7 +56,7 @@
$ cat >.git/hooks/applypatch-msg <<'EOF'
#!/bin/sh
. git-sh-setup
- perl -pi -e 's|^Message-Id:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1"
+ perl -pi -e 's|^Message-I[dD]:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1"
test -x "$GIT_DIR/hooks/commit-msg" &&
exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"}
:
diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst
index 756be15..ecc40fb 100644
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -28,5 +28,6 @@
oxsemi-tornado
pci-endpoint-test
spear-pcie-gadget
+ tps6594-pfsm
uacce
xilinx_sdfec
diff --git a/Documentation/misc-devices/tps6594-pfsm.rst b/Documentation/misc-devices/tps6594-pfsm.rst
new file mode 100644
index 0000000..4ada37c
--- /dev/null
+++ b/Documentation/misc-devices/tps6594-pfsm.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Texas Instruments TPS6594 PFSM driver
+=====================================
+
+Author: Julien Panis (jpanis@baylibre.com)
+
+Overview
+========
+
+Strictly speaking, PFSM (Pre-configurable Finite State Machine) is not
+hardware. It is a piece of code.
+
+The TPS6594 PMIC (Power Management IC) integrates a state machine which
+manages operational modes. Depending on the current operational mode,
+some voltage domains remain energized while others can be off.
+
+The PFSM driver can be used to trigger transitions between configured
+states. It also provides R/W access to the device registers.
+
+Supported chips
+---------------
+
+- tps6594-q1
+- tps6593-q1
+- lp8764-q1
+
+Driver location
+===============
+
+drivers/misc/tps6594-pfsm.c
+
+Driver type definitions
+=======================
+
+include/uapi/linux/tps6594_pfsm.h
+
+Driver IOCTLs
+=============
+
+:c:macro::`PMIC_GOTO_STANDBY`
+All device resources are powered down. The processor is off, and
+no voltage domains are energized.
+
+:c:macro::`PMIC_GOTO_LP_STANDBY`
+The digital and analog functions of the PMIC, which are not
+required to be always-on, are turned off (low-power).
+
+:c:macro::`PMIC_UPDATE_PGM`
+Triggers a firmware update.
+
+:c:macro::`PMIC_SET_ACTIVE_STATE`
+One of the operational modes.
+The PMICs are fully functional and supply power to all PDN loads.
+All voltage domains are energized in both MCU and Main processor
+sections.
+
+:c:macro::`PMIC_SET_MCU_ONLY_STATE`
+One of the operational modes.
+Only the power resources assigned to the MCU Safety Island are on.
+
+:c:macro::`PMIC_SET_RETENTION_STATE`
+One of the operational modes.
+Depending on the triggers set, some DDR/GPIO voltage domains can
+remain energized, while all other domains are off to minimize
+total system power.
+
+Driver usage
+============
+
+See available PFSMs::
+
+ # ls /dev/pfsm*
+
+Dump the registers of pages 0 and 1::
+
+ # hexdump -C /dev/pfsm-0-0x48
+
+See PFSM events::
+
+ # cat /proc/interrupts
+
+Userspace code example
+----------------------
+
+samples/pfsm/pfsm-wakeup.c
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 0cff6fa..4bfdf1d 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -4,31 +4,55 @@
Design
======
-Configurable Layers
-===================
-DAMON provides data access monitoring functionality while making the accuracy
-and the overhead controllable. The fundamental access monitorings require
-primitives that dependent on and optimized for the target address space. On
-the other hand, the accuracy and overhead tradeoff mechanism, which is the core
-of DAMON, is in the pure logic space. DAMON separates the two parts in
-different layers and defines its interface to allow various low level
-primitives implementations configurable with the core logic. We call the low
-level primitives implementations monitoring operations.
+Overall Architecture
+====================
-Due to this separated design and the configurable interface, users can extend
-DAMON for any address space by configuring the core logics with appropriate
-monitoring operations. If appropriate one is not provided, users can implement
-the operations on their own.
+DAMON subsystem is configured with three layers including
+
+- Operations Set: Implements fundamental operations for DAMON that depends on
+ the given monitoring target address-space and available set of
+ software/hardware primitives,
+- Core: Implements core logics including monitoring overhead/accurach control
+ and access-aware system operations on top of the operations set layer, and
+- Modules: Implements kernel modules for various purposes that provides
+ interfaces for the user space, on top of the core layer.
+
+
+Configurable Operations Set
+---------------------------
+
+For data access monitoring and additional low level work, DAMON needs a set of
+implementations for specific operations that are dependent on and optimized for
+the given target address space. On the other hand, the accuracy and overhead
+tradeoff mechanism, which is the core logic of DAMON, is in the pure logic
+space. DAMON separates the two parts in different layers, namely DAMON
+Operations Set and DAMON Core Logics Layers, respectively. It further defines
+the interface between the layers to allow various operations sets to be
+configured with the core logic.
+
+Due to this design, users can extend DAMON for any address space by configuring
+the core logic to use the appropriate operations set. If any appropriate set
+is unavailable, users can implement one on their own.
For example, physical memory, virtual memory, swap space, those for specific
processes, NUMA nodes, files, and backing memory devices would be supportable.
-Also, if some architectures or devices support special optimized access check
-primitives, those will be easily configurable.
+Also, if some architectures or devices supporting special optimized access
+check primitives, those will be easily configurable.
-Reference Implementations of Address Space Specific Monitoring Operations
-=========================================================================
+Programmable Modules
+--------------------
+
+Core layer of DAMON is implemented as a framework, and exposes its application
+programming interface to all kernel space components such as subsystems and
+modules. For common use cases of DAMON, DAMON subsystem provides kernel
+modules that built on top of the core layer using the API, which can be easily
+used by the user space end users.
+
+
+Operations Set Layer
+====================
The monitoring operations are defined in two parts:
@@ -90,8 +114,12 @@
as Idle page tracking does.
-Address Space Independent Core Mechanisms
-=========================================
+Core Logics
+===========
+
+
+Monitoring
+----------
Below four sections describe each of the DAMON core mechanisms and the five
monitoring attributes, ``sampling interval``, ``aggregation interval``,
@@ -100,7 +128,7 @@
Access Frequency Monitoring
----------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
The output of DAMON says what pages are how frequently accessed for a given
duration. The resolution of the access frequency is controlled by setting
@@ -127,7 +155,7 @@
Region Based Sampling
----------------------
+~~~~~~~~~~~~~~~~~~~~~
To avoid the unbounded increase of the overhead, DAMON groups adjacent pages
that assumed to have the same access frequencies into a region. As long as the
@@ -144,7 +172,7 @@
Adaptive Regions Adjustment
----------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
Even somehow the initial monitoring target regions are well constructed to
fulfill the assumption (pages in same region have similar access frequencies),
@@ -162,8 +190,22 @@
keeping the bounds users set for their trade-off.
+Age Tracking
+~~~~~~~~~~~~
+
+By analyzing the monitoring results, users can also find how long the current
+access pattern of a region has maintained. That could be used for good
+understanding of the access pattern. For example, page placement algorithm
+utilizing both the frequency and the recency could be implemented using that.
+To make such access pattern maintained period analysis easier, DAMON maintains
+yet another counter called ``age`` in each region. For each ``aggregation
+interval``, DAMON checks if the region's size and access frequency
+(``nr_accesses``) has significantly changed. If so, the counter is reset to
+zero. Otherwise, the counter is increased.
+
+
Dynamic Target Space Updates Handling
--------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The monitoring target address range could dynamically changed. For example,
virtual memory could be dynamically mapped and unmapped. Physical memory could
@@ -174,3 +216,246 @@
and applies it to monitoring operations-related data structures such as the
abstracted monitoring target memory area only for each of a user-specified time
interval (``update interval``).
+
+
+.. _damon_design_damos:
+
+Operation Schemes
+-----------------
+
+One common purpose of data access monitoring is access-aware system efficiency
+optimizations. For example,
+
+ paging out memory regions that are not accessed for more than two minutes
+
+or
+
+ using THP for memory regions that are larger than 2 MiB and showing a high
+ access frequency for more than one minute.
+
+One straightforward approach for such schemes would be profile-guided
+optimizations. That is, getting data access monitoring results of the
+workloads or the system using DAMON, finding memory regions of special
+characteristics by profiling the monitoring results, and making system
+operation changes for the regions. The changes could be made by modifying or
+providing advice to the software (the application and/or the kernel), or
+reconfiguring the hardware. Both offline and online approaches could be
+available.
+
+Among those, providing advice to the kernel at runtime would be flexible and
+effective, and therefore widely be used. However, implementing such schemes
+could impose unnecessary redundancy and inefficiency. The profiling could be
+redundant if the type of interest is common. Exchanging the information
+including monitoring results and operation advice between kernel and user
+spaces could be inefficient.
+
+To allow users to reduce such redundancy and inefficiencies by offloading the
+works, DAMON provides a feature called Data Access Monitoring-based Operation
+Schemes (DAMOS). It lets users specify their desired schemes at a high
+level. For such specifications, DAMON starts monitoring, finds regions having
+the access pattern of interest, and applies the user-desired operation actions
+to the regions as soon as found.
+
+
+.. _damon_design_damos_action:
+
+Operation Action
+~~~~~~~~~~~~~~~~
+
+The management action that the users desire to apply to the regions of their
+interest. For example, paging out, prioritizing for next reclamation victim
+selection, advising ``khugepaged`` to collapse or split, or doing nothing but
+collecting statistics of the regions.
+
+The list of supported actions is defined in DAMOS, but the implementation of
+each action is in the DAMON operations set layer because the implementation
+normally depends on the monitoring target address space. For example, the code
+for paging specific virtual address ranges out would be different from that for
+physical address ranges. And the monitoring operations implementation sets are
+not mandated to support all actions of the list. Hence, the availability of
+specific DAMOS action depends on what operations set is selected to be used
+together.
+
+Applying an action to a region is considered as changing the region's
+characteristics. Hence, DAMOS resets the age of regions when an action is
+applied to those.
+
+
+.. _damon_design_damos_access_pattern:
+
+Target Access Pattern
+~~~~~~~~~~~~~~~~~~~~~
+
+The access pattern of the schemes' interest. The patterns are constructed with
+the properties that DAMON's monitoring results provide, specifically the size,
+the access frequency, and the age. Users can describe their access pattern of
+interest by setting minimum and maximum values of the three properties. If a
+region's three properties are in the ranges, DAMOS classifies it as one of the
+regions that the scheme is having an interest in.
+
+
+.. _damon_design_damos_quotas:
+
+Quotas
+~~~~~~
+
+DAMOS upper-bound overhead control feature. DAMOS could incur high overhead if
+the target access pattern is not properly tuned. For example, if a huge memory
+region having the access pattern of interest is found, applying the scheme's
+action to all pages of the huge region could consume unacceptably large system
+resources. Preventing such issues by tuning the access pattern could be
+challenging, especially if the access patterns of the workloads are highly
+dynamic.
+
+To mitigate that situation, DAMOS provides an upper-bound overhead control
+feature called quotas. It lets users specify an upper limit of time that DAMOS
+can use for applying the action, and/or a maximum bytes of memory regions that
+the action can be applied within a user-specified time duration.
+
+
+.. _damon_design_damos_quotas_prioritization:
+
+Prioritization
+^^^^^^^^^^^^^^
+
+A mechanism for making a good decision under the quotas. When the action
+cannot be applied to all regions of interest due to the quotas, DAMOS
+prioritizes regions and applies the action to only regions having high enough
+priorities so that it will not exceed the quotas.
+
+The prioritization mechanism should be different for each action. For example,
+rarely accessed (colder) memory regions would be prioritized for page-out
+scheme action. In contrast, the colder regions would be deprioritized for huge
+page collapse scheme action. Hence, the prioritization mechanisms for each
+action are implemented in each DAMON operations set, together with the actions.
+
+Though the implementation is up to the DAMON operations set, it would be common
+to calculate the priority using the access pattern properties of the regions.
+Some users would want the mechanisms to be personalized for their specific
+case. For example, some users would want the mechanism to weigh the recency
+(``age``) more than the access frequency (``nr_accesses``). DAMOS allows users
+to specify the weight of each access pattern property and passes the
+information to the underlying mechanism. Nevertheless, how and even whether
+the weight will be respected are up to the underlying prioritization mechanism
+implementation.
+
+
+.. _damon_design_damos_watermarks:
+
+Watermarks
+~~~~~~~~~~
+
+Conditional DAMOS (de)activation automation. Users might want DAMOS to run
+only under certain situations. For example, when a sufficient amount of free
+memory is guaranteed, running a scheme for proactive reclamation would only
+consume unnecessary system resources. To avoid such consumption, the user would
+need to manually monitor some metrics such as free memory ratio, and turn
+DAMON/DAMOS on or off.
+
+DAMOS allows users to offload such works using three watermarks. It allows the
+users to configure the metric of their interest, and three watermark values,
+namely high, middle, and low. If the value of the metric becomes above the
+high watermark or below the low watermark, the scheme is deactivated. If the
+metric becomes below the mid watermark but above the low watermark, the scheme
+is activated. If all schemes are deactivated by the watermarks, the monitoring
+is also deactivated. In this case, the DAMON worker thread only periodically
+checks the watermarks and therefore incurs nearly zero overhead.
+
+
+.. _damon_design_damos_filters:
+
+Filters
+~~~~~~~
+
+Non-access pattern-based target memory regions filtering. If users run
+self-written programs or have good profiling tools, they could know something
+more than the kernel, such as future access patterns or some special
+requirements for specific types of memory. For example, some users may know
+only anonymous pages can impact their program's performance. They can also
+have a list of latency-critical processes.
+
+To let users optimize DAMOS schemes with such special knowledge, DAMOS provides
+a feature called DAMOS filters. The feature allows users to set an arbitrary
+number of filters for each scheme. Each filter specifies the type of target
+memory, and whether it should exclude the memory of the type (filter-out), or
+all except the memory of the type (filter-in).
+
+As of this writing, anonymous page type and memory cgroup type are supported by
+the feature. Some filter target types can require additional arguments. For
+example, the memory cgroup filter type asks users to specify the file path of
+the memory cgroup for the filter. Hence, users can apply specific schemes to
+only anonymous pages, non-anonymous pages, pages of specific cgroups, all pages
+excluding those of specific cgroups, and any combination of those.
+
+
+Application Programming Interface
+---------------------------------
+
+The programming interface for kernel space data access-aware applications.
+DAMON is a framework, so it does nothing by itself. Instead, it only helps
+other kernel components such as subsystems and modules building their data
+access-aware applications using DAMON's core features. For this, DAMON exposes
+its all features to other kernel components via its application programming
+interface, namely ``include/linux/damon.h``. Please refer to the API
+:doc:`document </mm/damon/api>` for details of the interface.
+
+
+Modules
+=======
+
+Because the core of DAMON is a framework for kernel components, it doesn't
+provide any direct interface for the user space. Such interfaces should be
+implemented by each DAMON API user kernel components, instead. DAMON subsystem
+itself implements such DAMON API user modules, which are supposed to be used
+for general purpose DAMON control and special purpose data access-aware system
+operations, and provides stable application binary interfaces (ABI) for the
+user space. The user space can build their efficient data access-aware
+applications using the interfaces.
+
+
+General Purpose User Interface Modules
+--------------------------------------
+
+DAMON modules that provide user space ABIs for general purpose DAMON usage in
+runtime.
+
+DAMON user interface modules, namely 'DAMON sysfs interface' and 'DAMON debugfs
+interface' are DAMON API user kernel modules that provide ABIs to the
+user-space. Please note that DAMON debugfs interface is currently deprecated.
+
+Like many other ABIs, the modules create files on sysfs and debugfs, allow
+users to specify their requests to and get the answers from DAMON by writing to
+and reading from the files. As a response to such I/O, DAMON user interface
+modules control DAMON and retrieve the results as user requested via the DAMON
+API, and return the results to the user-space.
+
+The ABIs are designed to be used for user space applications development,
+rather than human beings' fingers. Human users are recommended to use such
+user space tools. One such Python-written user space tool is available at
+Github (https://github.com/awslabs/damo), Pypi
+(https://pypistats.org/packages/damo), and Fedora
+(https://packages.fedoraproject.org/pkgs/python-damo/damo/).
+
+Please refer to the ABI :doc:`document </admin-guide/mm/damon/usage>` for
+details of the interfaces.
+
+
+Special-Purpose Access-aware Kernel Modules
+-------------------------------------------
+
+DAMON modules that provide user space ABI for specific purpose DAMON usage.
+
+DAMON sysfs/debugfs user interfaces are for full control of all DAMON features
+in runtime. For each special-purpose system-wide data access-aware system
+operations such as proactive reclamation or LRU lists balancing, the interfaces
+could be simplified by removing unnecessary knobs for the specific purpose, and
+extended for boot-time and even compile time control. Default values of DAMON
+control parameters for the usage would also need to be optimized for the
+purpose.
+
+To support such cases, yet more DAMON API user kernel modules that provide more
+simple and optimized user space interfaces are available. Currently, two
+modules for proactive reclamation and LRU lists manipulation are provided. For
+more detail, please read the usage documents for those
+(:doc:`/admin-guide/mm/damon/reclaim` and
+:doc:`/admin-guide/mm/damon/lru_sort`).
diff --git a/Documentation/mm/damon/faq.rst b/Documentation/mm/damon/faq.rst
index dde7e24..3279dc7 100644
--- a/Documentation/mm/damon/faq.rst
+++ b/Documentation/mm/damon/faq.rst
@@ -4,29 +4,6 @@
Frequently Asked Questions
==========================
-Why a new subsystem, instead of extending perf or other user space tools?
-=========================================================================
-
-First, because it needs to be lightweight as much as possible so that it can be
-used online, any unnecessary overhead such as kernel - user space context
-switching cost should be avoided. Second, DAMON aims to be used by other
-programs including the kernel. Therefore, having a dependency on specific
-tools like perf is not desirable. These are the two biggest reasons why DAMON
-is implemented in the kernel space.
-
-
-Can 'idle pages tracking' or 'perf mem' substitute DAMON?
-=========================================================
-
-Idle page tracking is a low level primitive for access check of the physical
-address space. 'perf mem' is similar, though it can use sampling to minimize
-the overhead. On the other hand, DAMON is a higher-level framework for the
-monitoring of various address spaces. It is focused on memory management
-optimization and provides sophisticated accuracy/overhead handling mechanisms.
-Therefore, 'idle pages tracking' and 'perf mem' could provide a subset of
-DAMON's output, but cannot substitute DAMON.
-
-
Does DAMON support virtual memory only?
=======================================
diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst
index 24a202f..a84c14e 100644
--- a/Documentation/mm/damon/maintainer-profile.rst
+++ b/Documentation/mm/damon/maintainer-profile.rst
@@ -3,7 +3,7 @@
DAMON Maintainer Entry Profile
==============================
-The DAMON subsystem covers the files that listed in 'DATA ACCESS MONITOR'
+The DAMON subsystem covers the files that are listed in 'DATA ACCESS MONITOR'
section of 'MAINTAINERS' file.
The mailing lists for the subsystem are damon@lists.linux.dev and
@@ -15,7 +15,7 @@
There are multiple Linux trees for DAMON development. Patches under
development or testing are queued in damon/next [2]_ by the DAMON maintainer.
-Suffieicntly reviewed patches will be queued in mm-unstable [1]_ by the memory
+Sufficiently reviewed patches will be queued in mm-unstable [1]_ by the memory
management subsystem maintainer. After more sufficient tests, the patches will
be queued in mm-stable [3]_ , and finally pull-requested to the mainline by the
memory management subsystem maintainer.
diff --git a/Documentation/mm/page_migration.rst b/Documentation/mm/page_migration.rst
index 313dce1..e35af78 100644
--- a/Documentation/mm/page_migration.rst
+++ b/Documentation/mm/page_migration.rst
@@ -73,14 +73,13 @@
It also prevents the swapper or other scans from encountering
the page.
-2. We need to have a function of type new_page_t that can be
+2. We need to have a function of type new_folio_t that can be
passed to migrate_pages(). This function should figure out
- how to allocate the correct new page given the old page.
+ how to allocate the correct new folio given the old folio.
3. The migrate_pages() function is called which attempts
to do the migration. It will call the function to allocate
- the new page for each page that is considered for
- moving.
+ the new folio for each folio that is considered for moving.
How migrate_pages() works
=========================
diff --git a/Documentation/mm/page_tables.rst b/Documentation/mm/page_tables.rst
index 9693957..7840c18 100644
--- a/Documentation/mm/page_tables.rst
+++ b/Documentation/mm/page_tables.rst
@@ -3,3 +3,152 @@
===========
Page Tables
===========
+
+Paged virtual memory was invented along with virtual memory as a concept in
+1962 on the Ferranti Atlas Computer which was the first computer with paged
+virtual memory. The feature migrated to newer computers and became a de facto
+feature of all Unix-like systems as time went by. In 1985 the feature was
+included in the Intel 80386, which was the CPU Linux 1.0 was developed on.
+
+Page tables map virtual addresses as seen by the CPU into physical addresses
+as seen on the external memory bus.
+
+Linux defines page tables as a hierarchy which is currently five levels in
+height. The architecture code for each supported architecture will then
+map this to the restrictions of the hardware.
+
+The physical address corresponding to the virtual address is often referenced
+by the underlying physical page frame. The **page frame number** or **pfn**
+is the physical address of the page (as seen on the external memory bus)
+divided by `PAGE_SIZE`.
+
+Physical memory address 0 will be *pfn 0* and the highest pfn will be
+the last page of physical memory the external address bus of the CPU can
+address.
+
+With a page granularity of 4KB and a address range of 32 bits, pfn 0 is at
+address 0x00000000, pfn 1 is at address 0x00001000, pfn 2 is at 0x00002000
+and so on until we reach pfn 0xfffff at 0xfffff000. With 16KB pages pfs are
+at 0x00004000, 0x00008000 ... 0xffffc000 and pfn goes from 0 to 0x3fffff.
+
+As you can see, with 4KB pages the page base address uses bits 12-31 of the
+address, and this is why `PAGE_SHIFT` in this case is defined as 12 and
+`PAGE_SIZE` is usually defined in terms of the page shift as `(1 << PAGE_SHIFT)`
+
+Over time a deeper hierarchy has been developed in response to increasing memory
+sizes. When Linux was created, 4KB pages and a single page table called
+`swapper_pg_dir` with 1024 entries was used, covering 4MB which coincided with
+the fact that Torvald's first computer had 4MB of physical memory. Entries in
+this single table were referred to as *PTE*:s - page table entries.
+
+The software page table hierarchy reflects the fact that page table hardware has
+become hierarchical and that in turn is done to save page table memory and
+speed up mapping.
+
+One could of course imagine a single, linear page table with enormous amounts
+of entries, breaking down the whole memory into single pages. Such a page table
+would be very sparse, because large portions of the virtual memory usually
+remains unused. By using hierarchical page tables large holes in the virtual
+address space does not waste valuable page table memory, because it will suffice
+to mark large areas as unmapped at a higher level in the page table hierarchy.
+
+Additionally, on modern CPUs, a higher level page table entry can point directly
+to a physical memory range, which allows mapping a contiguous range of several
+megabytes or even gigabytes in a single high-level page table entry, taking
+shortcuts in mapping virtual memory to physical memory: there is no need to
+traverse deeper in the hierarchy when you find a large mapped range like this.
+
+The page table hierarchy has now developed into this::
+
+ +-----+
+ | PGD |
+ +-----+
+ |
+ | +-----+
+ +-->| P4D |
+ +-----+
+ |
+ | +-----+
+ +-->| PUD |
+ +-----+
+ |
+ | +-----+
+ +-->| PMD |
+ +-----+
+ |
+ | +-----+
+ +-->| PTE |
+ +-----+
+
+
+Symbols on the different levels of the page table hierarchy have the following
+meaning beginning from the bottom:
+
+- **pte**, `pte_t`, `pteval_t` = **Page Table Entry** - mentioned earlier.
+ The *pte* is an array of `PTRS_PER_PTE` elements of the `pteval_t` type, each
+ mapping a single page of virtual memory to a single page of physical memory.
+ The architecture defines the size and contents of `pteval_t`.
+
+ A typical example is that the `pteval_t` is a 32- or 64-bit value with the
+ upper bits being a **pfn** (page frame number), and the lower bits being some
+ architecture-specific bits such as memory protection.
+
+ The **entry** part of the name is a bit confusing because while in Linux 1.0
+ this did refer to a single page table entry in the single top level page
+ table, it was retrofitted to be an array of mapping elements when two-level
+ page tables were first introduced, so the *pte* is the lowermost page
+ *table*, not a page table *entry*.
+
+- **pmd**, `pmd_t`, `pmdval_t` = **Page Middle Directory**, the hierarchy right
+ above the *pte*, with `PTRS_PER_PMD` references to the *pte*:s.
+
+- **pud**, `pud_t`, `pudval_t` = **Page Upper Directory** was introduced after
+ the other levels to handle 4-level page tables. It is potentially unused,
+ or *folded* as we will discuss later.
+
+- **p4d**, `p4d_t`, `p4dval_t` = **Page Level 4 Directory** was introduced to
+ handle 5-level page tables after the *pud* was introduced. Now it was clear
+ that we needed to replace *pgd*, *pmd*, *pud* etc with a figure indicating the
+ directory level and that we cannot go on with ad hoc names any more. This
+ is only used on systems which actually have 5 levels of page tables, otherwise
+ it is folded.
+
+- **pgd**, `pgd_t`, `pgdval_t` = **Page Global Directory** - the Linux kernel
+ main page table handling the PGD for the kernel memory is still found in
+ `swapper_pg_dir`, but each userspace process in the system also has its own
+ memory context and thus its own *pgd*, found in `struct mm_struct` which
+ in turn is referenced to in each `struct task_struct`. So tasks have memory
+ context in the form of a `struct mm_struct` and this in turn has a
+ `struct pgt_t *pgd` pointer to the corresponding page global directory.
+
+To repeat: each level in the page table hierarchy is a *array of pointers*, so
+the **pgd** contains `PTRS_PER_PGD` pointers to the next level below, **p4d**
+contains `PTRS_PER_P4D` pointers to **pud** items and so on. The number of
+pointers on each level is architecture-defined.::
+
+ PMD
+ --> +-----+ PTE
+ | ptr |-------> +-----+
+ | ptr |- | ptr |-------> PAGE
+ | ptr | \ | ptr |
+ | ptr | \ ...
+ | ... | \
+ | ptr | \ PTE
+ +-----+ +----> +-----+
+ | ptr |-------> PAGE
+ | ptr |
+ ...
+
+
+Page Table Folding
+==================
+
+If the architecture does not use all the page table levels, they can be *folded*
+which means skipped, and all operations performed on page tables will be
+compile-time augmented to just skip a level when accessing the next lower
+level.
+
+Page table handling code that wishes to be architecture-neutral, such as the
+virtual memory manager, will need to be written so that it traverses all of the
+currently five levels. This style should also be preferred for
+architecture-specific code, so as to be robust to future changes.
diff --git a/Documentation/mm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst
index 50ee0df..a834fad9 100644
--- a/Documentation/mm/split_page_table_lock.rst
+++ b/Documentation/mm/split_page_table_lock.rst
@@ -14,15 +14,20 @@
There are helpers to lock/unlock a table and other accessor functions:
- pte_offset_map_lock()
- maps pte and takes PTE table lock, returns pointer to the taken
- lock;
+ maps PTE and takes PTE table lock, returns pointer to PTE with
+ pointer to its PTE table lock, or returns NULL if no PTE table;
+ - pte_offset_map_nolock()
+ maps PTE, returns pointer to PTE with pointer to its PTE table
+ lock (not taken), or returns NULL if no PTE table;
+ - pte_offset_map()
+ maps PTE, returns pointer to PTE, or returns NULL if no PTE table;
+ - pte_unmap()
+ unmaps PTE table;
- pte_unmap_unlock()
unlocks and unmaps PTE table;
- pte_alloc_map_lock()
- allocates PTE table if needed and take the lock, returns pointer
- to taken lock or NULL if allocation failed;
- - pte_lockptr()
- returns pointer to PTE table lock;
+ allocates PTE table if needed and takes its lock, returns pointer to
+ PTE with pointer to its lock, or returns NULL if allocation failed;
- pmd_lock()
takes PMD table lock, returns pointer to taken lock;
- pmd_lockptr()
diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml
index 8e8c17b..57d1c1c 100644
--- a/Documentation/netlink/genetlink-c.yaml
+++ b/Documentation/netlink/genetlink-c.yaml
@@ -195,6 +195,16 @@
description: Max length for a string or a binary attribute.
$ref: '#/$defs/len-or-define'
sub-type: *attr-type
+ display-hint: &display-hint
+ description: |
+ Optional format indicator that is intended only for choosing
+ the right formatting mechanism when displaying values of this
+ type.
+ enum: [ hex, mac, fddi, ipv4, ipv6, uuid ]
+ # Start genetlink-c
+ name-prefix:
+ type: string
+ # End genetlink-c
# Make sure name-prefix does not appear in subsets (subsets inherit naming)
dependencies:
diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml
index b33541a..43b769c 100644
--- a/Documentation/netlink/genetlink-legacy.yaml
+++ b/Documentation/netlink/genetlink-legacy.yaml
@@ -119,9 +119,24 @@
name:
type: string
type:
- enum: [ u8, u16, u32, u64, s8, s16, s32, s64, string ]
+ description: The netlink attribute type
+ enum: [ u8, u16, u32, u64, s8, s16, s32, s64, string, binary ]
len:
$ref: '#/$defs/len-or-define'
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ doc:
+ description: Documentation for the struct member attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ display-hint: &display-hint
+ description: |
+ Optional format indicator that is intended only for choosing
+ the right formatting mechanism when displaying values of this
+ type.
+ enum: [ hex, mac, fddi, ipv4, ipv6, uuid ]
# End genetlink-legacy
attribute-sets:
@@ -171,6 +186,7 @@
name:
type: string
type: &attr-type
+ description: The netlink attribute type
enum: [ unused, pad, flag, binary, u8, u16, u32, u64, s32, s64,
string, nest, array-nest, nest-type-value ]
doc:
@@ -218,6 +234,11 @@
description: Max length for a string or a binary attribute.
$ref: '#/$defs/len-or-define'
sub-type: *attr-type
+ display-hint: *display-hint
+ # Start genetlink-c
+ name-prefix:
+ type: string
+ # End genetlink-c
# Start genetlink-legacy
struct:
description: Name of the struct type used for the attribute.
diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml
index d8b2cde..1cbb448 100644
--- a/Documentation/netlink/genetlink.yaml
+++ b/Documentation/netlink/genetlink.yaml
@@ -168,6 +168,12 @@
description: Max length for a string or a binary attribute.
$ref: '#/$defs/len-or-define'
sub-type: *attr-type
+ display-hint: &display-hint
+ description: |
+ Optional format indicator that is intended only for choosing
+ the right formatting mechanism when displaying values of this
+ type.
+ enum: [ hex, mac, fddi, ipv4, ipv6, uuid ]
# Make sure name-prefix does not appear in subsets (subsets inherit naming)
dependencies:
diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml
index 9064166..5d46ca9 100644
--- a/Documentation/netlink/specs/devlink.yaml
+++ b/Documentation/netlink/specs/devlink.yaml
@@ -9,6 +9,7 @@
attribute-sets:
-
name: devlink
+ name-prefix: devlink-attr-
attributes:
-
name: bus-name
@@ -95,10 +96,12 @@
-
name: reload-action-info
type: nest
+ multi-attr: true
nested-attributes: dl-reload-act-info
-
name: reload-action-stats
type: nest
+ multi-attr: true
nested-attributes: dl-reload-act-stats
-
name: dl-dev-stats
@@ -196,3 +199,8 @@
attributes:
- bus-name
- dev-name
+ - info-driver-name
+ - info-serial-number
+ - info-version-fixed
+ - info-version-running
+ - info-version-stored
diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 4846345..837b565 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -9,8 +9,13 @@
definitions:
-
name: udp-tunnel-type
+ enum-name:
type: enum
entries: [ vxlan, geneve, vxlan-gpe ]
+ -
+ name: stringset
+ type: enum
+ entries: []
attribute-sets:
-
@@ -497,7 +502,7 @@
attributes:
-
name: pad
- type: u32
+ type: pad
-
name: tx-frames
type: u64
@@ -577,7 +582,7 @@
name: phc-index
type: u32
-
- name: cable-test-ntf-nest-result
+ name: cable-result
attributes:
-
name: pair
@@ -586,7 +591,7 @@
name: code
type: u8
-
- name: cable-test-ntf-nest-fault-length
+ name: cable-fault-length
attributes:
-
name: pair
@@ -595,16 +600,16 @@
name: cm
type: u32
-
- name: cable-test-ntf-nest
+ name: cable-nest
attributes:
-
name: result
type: nest
- nested-attributes: cable-test-ntf-nest-result
+ nested-attributes: cable-result
-
name: fault-length
type: nest
- nested-attributes: cable-test-ntf-nest-fault-length
+ nested-attributes: cable-fault-length
-
name: cable-test
attributes:
@@ -612,13 +617,20 @@
name: header
type: nest
nested-attributes: header
+ -
+ name: cable-test-ntf
+ attributes:
+ -
+ name: header
+ type: nest
+ nested-attributes: header
-
name: status
type: u8
-
name: nest
type: nest
- nested-attributes: cable-test-ntf-nest
+ nested-attributes: cable-nest
-
name: cable-test-tdr-cfg
attributes:
@@ -632,9 +644,23 @@
name: step
type: u32
-
- name: pari
+ name: pair
type: u8
-
+ name: cable-test-tdr-ntf
+ attributes:
+ -
+ name: header
+ type: nest
+ nested-attributes: header
+ -
+ name: status
+ type: u8
+ -
+ name: nest
+ type: nest
+ nested-attributes: cable-nest
+ -
name: cable-test-tdr
attributes:
-
@@ -646,7 +672,7 @@
type: nest
nested-attributes: cable-test-tdr-cfg
-
- name: tunnel-info-udp-entry
+ name: tunnel-udp-entry
attributes:
-
name: port
@@ -657,7 +683,7 @@
type: u32
enum: udp-tunnel-type
-
- name: tunnel-info-udp-table
+ name: tunnel-udp-table
attributes:
-
name: size
@@ -667,9 +693,17 @@
type: nest
nested-attributes: bitset
-
- name: udp-ports
+ name: entry
type: nest
- nested-attributes: tunnel-info-udp-entry
+ multi-attr: true
+ nested-attributes: tunnel-udp-entry
+ -
+ name: tunnel-udp
+ attributes:
+ -
+ name: table
+ type: nest
+ nested-attributes: tunnel-udp-table
-
name: tunnel-info
attributes:
@@ -680,13 +714,13 @@
-
name: udp-ports
type: nest
- nested-attributes: tunnel-info-udp-table
+ nested-attributes: tunnel-udp
-
name: fec-stat
attributes:
-
name: pad
- type: u8
+ type: pad
-
name: corrected
type: binary
@@ -750,7 +784,7 @@
attributes:
-
name: pad
- type: u32
+ type: pad
-
name: id
type: u32
@@ -759,16 +793,29 @@
type: u32
-
name: stat
- type: nest
- nested-attributes: u64
+ type: u64
+ type-value: [ id ]
-
name: hist-rx
type: nest
- nested-attributes: u64
+ nested-attributes: stats-grp-hist
-
name: hist-tx
type: nest
- nested-attributes: u64
+ nested-attributes: stats-grp-hist
+ -
+ name: hist-bkt-low
+ type: u32
+ -
+ name: hist-bkt-hi
+ type: u32
+ -
+ name: hist-val
+ type: u64
+ -
+ name: stats-grp-hist
+ subset-of: stats-grp
+ attributes:
-
name: hist-bkt-low
type: u32
@@ -783,7 +830,7 @@
attributes:
-
name: pad
- type: u32
+ type: pad
-
name: header
type: nest
@@ -836,12 +883,15 @@
-
name: admin-state
type: u32
+ name-prefix: ethtool-a-podl-pse-
-
name: admin-control
type: u32
+ name-prefix: ethtool-a-podl-pse-
-
name: pw-d-status
type: u32
+ name-prefix: ethtool-a-podl-pse-
-
name: rss
attributes:
@@ -895,6 +945,7 @@
operations:
enum-model: directional
+ name-prefix: ethtool-msg-
list:
-
name: strset-get
@@ -1348,10 +1399,16 @@
request:
attributes:
- header
- reply:
- attributes:
- - header
- - cable-test-ntf-nest
+ -
+ name: cable-test-ntf
+ doc: Cable test notification.
+
+ attribute-set: cable-test-ntf
+
+ event:
+ attributes:
+ - header
+ - status
-
name: cable-test-tdr-act
doc: Cable test TDR.
@@ -1362,10 +1419,17 @@
request:
attributes:
- header
- reply:
- attributes:
- - header
- - cable-test-tdr-cfg
+ -
+ name: cable-test-tdr-ntf
+ doc: Cable test TDR notification.
+
+ attribute-set: cable-test-tdr-ntf
+
+ event:
+ attributes:
+ - header
+ - status
+ - nest
-
name: tunnel-info-get
doc: Get tsinfo params.
diff --git a/Documentation/netlink/specs/ovs_datapath.yaml b/Documentation/netlink/specs/ovs_datapath.yaml
index 6d71db8c..f709c26 100644
--- a/Documentation/netlink/specs/ovs_datapath.yaml
+++ b/Documentation/netlink/specs/ovs_datapath.yaml
@@ -3,6 +3,7 @@
name: ovs_datapath
version: 2
protocol: genetlink-legacy
+uapi-header: linux/openvswitch.h
doc:
OVS datapath configuration over generic netlink.
@@ -18,6 +19,7 @@
-
name: user-features
type: flags
+ name-prefix: ovs-dp-f-
entries:
-
name: unaligned
@@ -33,35 +35,37 @@
doc: Allow per-cpu dispatch of upcalls
-
name: datapath-stats
+ enum-name: ovs-dp-stats
type: struct
members:
-
- name: hit
+ name: n-hit
type: u64
-
- name: missed
+ name: n-missed
type: u64
-
- name: lost
+ name: n-lost
type: u64
-
- name: flows
+ name: n-flows
type: u64
-
name: megaflow-stats
+ enum-name: ovs-dp-megaflow-stats
type: struct
members:
-
- name: mask-hit
+ name: n-mask-hit
type: u64
-
- name: masks
+ name: n-masks
type: u32
-
name: padding
type: u32
-
- name: cache-hits
+ name: n-cache-hit
type: u64
-
name: pad1
@@ -70,6 +74,8 @@
attribute-sets:
-
name: datapath
+ name-prefix: ovs-dp-attr-
+ enum-name: ovs-datapath-attrs
attributes:
-
name: name
@@ -101,12 +107,16 @@
name: per-cpu-pids
type: binary
sub-type: u32
+ -
+ name: ifindex
+ type: u32
operations:
fixed-header: ovs-header
+ name-prefix: ovs-dp-cmd-
list:
-
- name: dp-get
+ name: get
doc: Get / dump OVS data path configuration and state
value: 3
attribute-set: datapath
@@ -125,7 +135,7 @@
- per-cpu-pids
dump: *dp-get-op
-
- name: dp-new
+ name: new
doc: Create new OVS data path
value: 1
attribute-set: datapath
@@ -137,7 +147,7 @@
- upcall-pid
- user-features
-
- name: dp-del
+ name: del
doc: Delete existing OVS data path
value: 2
attribute-set: datapath
diff --git a/Documentation/netlink/specs/ovs_flow.yaml b/Documentation/netlink/specs/ovs_flow.yaml
new file mode 100644
index 0000000..109ca1f
--- /dev/null
+++ b/Documentation/netlink/specs/ovs_flow.yaml
@@ -0,0 +1,980 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+
+name: ovs_flow
+version: 1
+protocol: genetlink-legacy
+uapi-header: linux/openvswitch.h
+
+doc:
+ OVS flow configuration over generic netlink.
+
+definitions:
+ -
+ name: ovs-header
+ type: struct
+ doc: |
+ Header for OVS Generic Netlink messages.
+ members:
+ -
+ name: dp-ifindex
+ type: u32
+ doc: |
+ ifindex of local port for datapath (0 to make a request not specific
+ to a datapath).
+ -
+ name: ovs-flow-stats
+ type: struct
+ members:
+ -
+ name: n-packets
+ type: u64
+ doc: Number of matched packets.
+ -
+ name: n-bytes
+ type: u64
+ doc: Number of matched bytes.
+ -
+ name: ovs-key-ethernet
+ type: struct
+ members:
+ -
+ name: eth-src
+ type: binary
+ len: 6
+ display-hint: mac
+ -
+ name: eth-dst
+ type: binary
+ len: 6
+ display-hint: mac
+ -
+ name: ovs-key-mpls
+ type: struct
+ members:
+ -
+ name: mpls-lse
+ type: u32
+ byte-order: big-endian
+ -
+ name: ovs-key-ipv4
+ type: struct
+ members:
+ -
+ name: ipv4-src
+ type: u32
+ byte-order: big-endian
+ display-hint: ipv4
+ -
+ name: ipv4-dst
+ type: u32
+ byte-order: big-endian
+ display-hint: ipv4
+ -
+ name: ipv4-proto
+ type: u8
+ -
+ name: ipv4-tos
+ type: u8
+ -
+ name: ipv4-ttl
+ type: u8
+ -
+ name: ipv4-frag
+ type: u8
+ enum: ovs-frag-type
+ -
+ name: ovs-key-ipv6
+ type: struct
+ members:
+ -
+ name: ipv6-src
+ type: binary
+ len: 16
+ byte-order: big-endian
+ display-hint: ipv6
+ -
+ name: ipv6-dst
+ type: binary
+ len: 16
+ byte-order: big-endian
+ display-hint: ipv6
+ -
+ name: ipv6-label
+ type: u32
+ byte-order: big-endian
+ -
+ name: ipv6-proto
+ type: u8
+ -
+ name: ipv6-tclass
+ type: u8
+ -
+ name: ipv6-hlimit
+ type: u8
+ -
+ name: ipv6-frag
+ type: u8
+ -
+ name: ovs-key-ipv6-exthdrs
+ type: struct
+ members:
+ -
+ name: hdrs
+ type: u16
+ -
+ name: ovs-frag-type
+ name-prefix: ovs-frag-type-
+ type: enum
+ entries:
+ -
+ name: none
+ doc: Packet is not a fragment.
+ -
+ name: first
+ doc: Packet is a fragment with offset 0.
+ -
+ name: later
+ doc: Packet is a fragment with nonzero offset.
+ -
+ name: any
+ value: 255
+ -
+ name: ovs-key-tcp
+ type: struct
+ members:
+ -
+ name: tcp-src
+ type: u16
+ byte-order: big-endian
+ -
+ name: tcp-dst
+ type: u16
+ byte-order: big-endian
+ -
+ name: ovs-key-udp
+ type: struct
+ members:
+ -
+ name: udp-src
+ type: u16
+ byte-order: big-endian
+ -
+ name: udp-dst
+ type: u16
+ byte-order: big-endian
+ -
+ name: ovs-key-sctp
+ type: struct
+ members:
+ -
+ name: sctp-src
+ type: u16
+ byte-order: big-endian
+ -
+ name: sctp-dst
+ type: u16
+ byte-order: big-endian
+ -
+ name: ovs-key-icmp
+ type: struct
+ members:
+ -
+ name: icmp-type
+ type: u8
+ -
+ name: icmp-code
+ type: u8
+ -
+ name: ovs-key-arp
+ type: struct
+ members:
+ -
+ name: arp-sip
+ type: u32
+ byte-order: big-endian
+ -
+ name: arp-tip
+ type: u32
+ byte-order: big-endian
+ -
+ name: arp-op
+ type: u16
+ byte-order: big-endian
+ -
+ name: arp-sha
+ type: binary
+ len: 6
+ display-hint: mac
+ -
+ name: arp-tha
+ type: binary
+ len: 6
+ display-hint: mac
+ -
+ name: ovs-key-nd
+ type: struct
+ members:
+ -
+ name: nd_target
+ type: binary
+ len: 16
+ byte-order: big-endian
+ -
+ name: nd-sll
+ type: binary
+ len: 6
+ display-hint: mac
+ -
+ name: nd-tll
+ type: binary
+ len: 6
+ display-hint: mac
+ -
+ name: ovs-key-ct-tuple-ipv4
+ type: struct
+ members:
+ -
+ name: ipv4-src
+ type: u32
+ byte-order: big-endian
+ -
+ name: ipv4-dst
+ type: u32
+ byte-order: big-endian
+ -
+ name: src-port
+ type: u16
+ byte-order: big-endian
+ -
+ name: dst-port
+ type: u16
+ byte-order: big-endian
+ -
+ name: ipv4-proto
+ type: u8
+ -
+ name: ovs-action-push-vlan
+ type: struct
+ members:
+ -
+ name: vlan_tpid
+ type: u16
+ byte-order: big-endian
+ doc: Tag protocol identifier (TPID) to push.
+ -
+ name: vlan_tci
+ type: u16
+ byte-order: big-endian
+ doc: Tag control identifier (TCI) to push.
+ -
+ name: ovs-ufid-flags
+ name-prefix: ovs-ufid-f-
+ type: flags
+ entries:
+ - omit-key
+ - omit-mask
+ - omit-actions
+ -
+ name: ovs-action-hash
+ type: struct
+ members:
+ -
+ name: hash-alg
+ type: u32
+ doc: Algorithm used to compute hash prior to recirculation.
+ -
+ name: hash-basis
+ type: u32
+ doc: Basis used for computing hash.
+ -
+ name: ovs-hash-alg
+ type: enum
+ doc: |
+ Data path hash algorithm for computing Datapath hash. The algorithm type only specifies
+ the fields in a flow will be used as part of the hash. Each datapath is free to use its
+ own hash algorithm. The hash value will be opaque to the user space daemon.
+ entries:
+ - ovs-hash-alg-l4
+
+ -
+ name: ovs-action-push-mpls
+ type: struct
+ members:
+ -
+ name: mpls-lse
+ type: u32
+ byte-order: big-endian
+ doc: |
+ MPLS label stack entry to push
+ -
+ name: mpls-ethertype
+ type: u32
+ byte-order: big-endian
+ doc: |
+ Ethertype to set in the encapsulating ethernet frame. The only values
+ ethertype should ever be given are ETH_P_MPLS_UC and ETH_P_MPLS_MC,
+ indicating MPLS unicast or multicast. Other are rejected.
+ -
+ name: ovs-action-add-mpls
+ type: struct
+ members:
+ -
+ name: mpls-lse
+ type: u32
+ byte-order: big-endian
+ doc: |
+ MPLS label stack entry to push
+ -
+ name: mpls-ethertype
+ type: u32
+ byte-order: big-endian
+ doc: |
+ Ethertype to set in the encapsulating ethernet frame. The only values
+ ethertype should ever be given are ETH_P_MPLS_UC and ETH_P_MPLS_MC,
+ indicating MPLS unicast or multicast. Other are rejected.
+ -
+ name: tun-flags
+ type: u16
+ doc: |
+ MPLS tunnel attributes.
+ -
+ name: ct-state-flags
+ type: flags
+ name-prefix: ovs-cs-f-
+ entries:
+ -
+ name: new
+ doc: Beginning of a new connection.
+ -
+ name: established
+ doc: Part of an existing connenction
+ -
+ name: related
+ doc: Related to an existing connection.
+ -
+ name: reply-dir
+ doc: Flow is in the reply direction.
+ -
+ name: invalid
+ doc: Could not track the connection.
+ -
+ name: tracked
+ doc: Conntrack has occurred.
+ -
+ name: src-nat
+ doc: Packet's source address/port was mangled by NAT.
+ -
+ name: dst-nat
+ doc: Packet's destination address/port was mangled by NAT.
+
+attribute-sets:
+ -
+ name: flow-attrs
+ enum-name: ovs-flow-attr
+ name-prefix: ovs-flow-attr-
+ attributes:
+ -
+ name: key
+ type: nest
+ nested-attributes: key-attrs
+ doc: |
+ Nested attributes specifying the flow key. Always present in
+ notifications. Required for all requests (except dumps).
+ -
+ name: actions
+ type: nest
+ nested-attributes: action-attrs
+ doc: |
+ Nested attributes specifying the actions to take for packets that
+ match the key. Always present in notifications. Required for
+ OVS_FLOW_CMD_NEW requests, optional for OVS_FLOW_CMD_SET requests. An
+ OVS_FLOW_CMD_SET without OVS_FLOW_ATTR_ACTIONS will not modify the
+ actions. To clear the actions, an OVS_FLOW_ATTR_ACTIONS without any
+ nested attributes must be given.
+ -
+ name: stats
+ type: binary
+ struct: ovs-flow-stats
+ doc: |
+ Statistics for this flow. Present in notifications if the stats would
+ be nonzero. Ignored in requests.
+ -
+ name: tcp-flags
+ type: u8
+ doc: |
+ An 8-bit value giving the ORed value of all of the TCP flags seen on
+ packets in this flow. Only present in notifications for TCP flows, and
+ only if it would be nonzero. Ignored in requests.
+ -
+ name: used
+ type: u64
+ doc: |
+ A 64-bit integer giving the time, in milliseconds on the system
+ monotonic clock, at which a packet was last processed for this
+ flow. Only present in notifications if a packet has been processed for
+ this flow. Ignored in requests.
+ -
+ name: clear
+ type: flag
+ doc: |
+ If present in a OVS_FLOW_CMD_SET request, clears the last-used time,
+ accumulated TCP flags, and statistics for this flow. Otherwise
+ ignored in requests. Never present in notifications.
+ -
+ name: mask
+ type: nest
+ nested-attributes: key-attrs
+ doc: |
+ Nested attributes specifying the mask bits for wildcarded flow
+ match. Mask bit value '1' specifies exact match with corresponding
+ flow key bit, while mask bit value '0' specifies a wildcarded
+ match. Omitting attribute is treated as wildcarding all corresponding
+ fields. Optional for all requests. If not present, all flow key bits
+ are exact match bits.
+ -
+ name: probe
+ type: binary
+ doc: |
+ Flow operation is a feature probe, error logging should be suppressed.
+ -
+ name: ufid
+ type: binary
+ doc: |
+ A value between 1-16 octets specifying a unique identifier for the
+ flow. Causes the flow to be indexed by this value rather than the
+ value of the OVS_FLOW_ATTR_KEY attribute. Optional for all
+ requests. Present in notifications if the flow was created with this
+ attribute.
+ display-hint: uuid
+ -
+ name: ufid-flags
+ type: u32
+ enum: ovs-ufid-flags
+ doc: |
+ A 32-bit value of ORed flags that provide alternative semantics for
+ flow installation and retrieval. Optional for all requests.
+ -
+ name: pad
+ type: binary
+
+ -
+ name: key-attrs
+ enum-name: ovs-key-attr
+ name-prefix: ovs-key-attr-
+ attributes:
+ -
+ name: encap
+ type: nest
+ nested-attributes: key-attrs
+ -
+ name: priority
+ type: u32
+ -
+ name: in-port
+ type: u32
+ -
+ name: ethernet
+ type: binary
+ struct: ovs-key-ethernet
+ doc: struct ovs_key_ethernet
+ -
+ name: vlan
+ type: u16
+ byte-order: big-endian
+ -
+ name: ethertype
+ type: u16
+ byte-order: big-endian
+ -
+ name: ipv4
+ type: binary
+ struct: ovs-key-ipv4
+ -
+ name: ipv6
+ type: binary
+ struct: ovs-key-ipv6
+ doc: struct ovs_key_ipv6
+ -
+ name: tcp
+ type: binary
+ struct: ovs-key-tcp
+ -
+ name: udp
+ type: binary
+ struct: ovs-key-udp
+ -
+ name: icmp
+ type: binary
+ struct: ovs-key-icmp
+ -
+ name: icmpv6
+ type: binary
+ struct: ovs-key-icmp
+ -
+ name: arp
+ type: binary
+ struct: ovs-key-arp
+ doc: struct ovs_key_arp
+ -
+ name: nd
+ type: binary
+ struct: ovs-key-nd
+ doc: struct ovs_key_nd
+ -
+ name: skb-mark
+ type: u32
+ -
+ name: tunnel
+ type: nest
+ nested-attributes: tunnel-key-attrs
+ -
+ name: sctp
+ type: binary
+ struct: ovs-key-sctp
+ -
+ name: tcp-flags
+ type: u16
+ byte-order: big-endian
+ -
+ name: dp-hash
+ type: u32
+ doc: Value 0 indicates the hash is not computed by the datapath.
+ -
+ name: recirc-id
+ type: u32
+ -
+ name: mpls
+ type: binary
+ struct: ovs-key-mpls
+ -
+ name: ct-state
+ type: u32
+ enum: ct-state-flags
+ enum-as-flags: true
+ -
+ name: ct-zone
+ type: u16
+ doc: connection tracking zone
+ -
+ name: ct-mark
+ type: u32
+ doc: connection tracking mark
+ -
+ name: ct-labels
+ type: binary
+ display-hint: hex
+ doc: 16-octet connection tracking label
+ -
+ name: ct-orig-tuple-ipv4
+ type: binary
+ struct: ovs-key-ct-tuple-ipv4
+ -
+ name: ct-orig-tuple-ipv6
+ type: binary
+ doc: struct ovs_key_ct_tuple_ipv6
+ -
+ name: nsh
+ type: nest
+ nested-attributes: ovs-nsh-key-attrs
+ -
+ name: packet-type
+ type: u32
+ byte-order: big-endian
+ doc: Should not be sent to the kernel
+ -
+ name: nd-extensions
+ type: binary
+ doc: Should not be sent to the kernel
+ -
+ name: tunnel-info
+ type: binary
+ doc: struct ip_tunnel_info
+ -
+ name: ipv6-exthdrs
+ type: binary
+ struct: ovs-key-ipv6-exthdrs
+ doc: struct ovs_key_ipv6_exthdr
+ -
+ name: action-attrs
+ enum-name: ovs-action-attr
+ name-prefix: ovs-action-attr-
+ attributes:
+ -
+ name: output
+ type: u32
+ doc: ovs port number in datapath
+ -
+ name: userspace
+ type: nest
+ nested-attributes: userspace-attrs
+ -
+ name: set
+ type: nest
+ nested-attributes: key-attrs
+ doc: Replaces the contents of an existing header. The single nested attribute specifies a header to modify and its value.
+ -
+ name: push-vlan
+ type: binary
+ struct: ovs-action-push-vlan
+ doc: Push a new outermost 802.1Q or 802.1ad header onto the packet.
+ -
+ name: pop-vlan
+ type: flag
+ doc: Pop the outermost 802.1Q or 802.1ad header from the packet.
+ -
+ name: sample
+ type: nest
+ nested-attributes: sample-attrs
+ doc: |
+ Probabilistically executes actions, as specified in the nested attributes.
+ -
+ name: recirc
+ type: u32
+ doc: recirc id
+ -
+ name: hash
+ type: binary
+ struct: ovs-action-hash
+ -
+ name: push-mpls
+ type: binary
+ struct: ovs-action-push-mpls
+ doc: |
+ Push a new MPLS label stack entry onto the top of the packets MPLS
+ label stack. Set the ethertype of the encapsulating frame to either
+ ETH_P_MPLS_UC or ETH_P_MPLS_MC to indicate the new packet contents.
+ -
+ name: pop-mpls
+ type: u16
+ byte-order: big-endian
+ doc: ethertype
+ -
+ name: set-masked
+ type: nest
+ nested-attributes: key-attrs
+ doc: |
+ Replaces the contents of an existing header. A nested attribute
+ specifies a header to modify, its value, and a mask. For every bit set
+ in the mask, the corresponding bit value is copied from the value to
+ the packet header field, rest of the bits are left unchanged. The
+ non-masked value bits must be passed in as zeroes. Masking is not
+ supported for the OVS_KEY_ATTR_TUNNEL attribute.
+ -
+ name: ct
+ type: nest
+ nested-attributes: ct-attrs
+ doc: |
+ Track the connection. Populate the conntrack-related entries
+ in the flow key.
+ -
+ name: trunc
+ type: u32
+ doc: struct ovs_action_trunc is a u32 max length
+ -
+ name: push-eth
+ type: binary
+ doc: struct ovs_action_push_eth
+ -
+ name: pop-eth
+ type: flag
+ -
+ name: ct-clear
+ type: flag
+ -
+ name: push-nsh
+ type: nest
+ nested-attributes: ovs-nsh-key-attrs
+ doc: |
+ Push NSH header to the packet.
+ -
+ name: pop-nsh
+ type: flag
+ doc: |
+ Pop the outermost NSH header off the packet.
+ -
+ name: meter
+ type: u32
+ doc: |
+ Run packet through a meter, which may drop the packet, or modify the
+ packet (e.g., change the DSCP field)
+ -
+ name: clone
+ type: nest
+ nested-attributes: action-attrs
+ doc: |
+ Make a copy of the packet and execute a list of actions without
+ affecting the original packet and key.
+ -
+ name: check-pkt-len
+ type: nest
+ nested-attributes: check-pkt-len-attrs
+ doc: |
+ Check the packet length and execute a set of actions if greater than
+ the specified packet length, else execute another set of actions.
+ -
+ name: add-mpls
+ type: binary
+ struct: ovs-action-add-mpls
+ doc: |
+ Push a new MPLS label stack entry at the start of the packet or at the
+ start of the l3 header depending on the value of l3 tunnel flag in the
+ tun_flags field of this OVS_ACTION_ATTR_ADD_MPLS argument.
+ -
+ name: dec-ttl
+ type: nest
+ nested-attributes: dec-ttl-attrs
+ -
+ name: tunnel-key-attrs
+ enum-name: ovs-tunnel-key-attr
+ name-prefix: ovs-tunnel-key-attr-
+ attributes:
+ -
+ name: id
+ type: u64
+ byte-order: big-endian
+ value: 0
+ -
+ name: ipv4-src
+ type: u32
+ byte-order: big-endian
+ -
+ name: ipv4-dst
+ type: u32
+ byte-order: big-endian
+ -
+ name: tos
+ type: u8
+ -
+ name: ttl
+ type: u8
+ -
+ name: dont-fragment
+ type: flag
+ -
+ name: csum
+ type: flag
+ -
+ name: oam
+ type: flag
+ -
+ name: geneve-opts
+ type: binary
+ sub-type: u32
+ -
+ name: tp-src
+ type: u16
+ byte-order: big-endian
+ -
+ name: tp-dst
+ type: u16
+ byte-order: big-endian
+ -
+ name: vxlan-opts
+ type: nest
+ nested-attributes: vxlan-ext-attrs
+ -
+ name: ipv6-src
+ type: binary
+ doc: |
+ struct in6_addr source IPv6 address
+ -
+ name: ipv6-dst
+ type: binary
+ doc: |
+ struct in6_addr destination IPv6 address
+ -
+ name: pad
+ type: binary
+ -
+ name: erspan-opts
+ type: binary
+ doc: |
+ struct erspan_metadata
+ -
+ name: ipv4-info-bridge
+ type: flag
+ -
+ name: check-pkt-len-attrs
+ enum-name: ovs-check-pkt-len-attr
+ name-prefix: ovs-check-pkt-len-attr-
+ attributes:
+ -
+ name: pkt-len
+ type: u16
+ -
+ name: actions-if-greater
+ type: nest
+ nested-attributes: action-attrs
+ -
+ name: actions-if-less-equal
+ type: nest
+ nested-attributes: action-attrs
+ -
+ name: sample-attrs
+ enum-name: ovs-sample-attr
+ name-prefix: ovs-sample-attr-
+ attributes:
+ -
+ name: probability
+ type: u32
+ -
+ name: actions
+ type: nest
+ nested-attributes: action-attrs
+ -
+ name: userspace-attrs
+ enum-name: ovs-userspace-attr
+ name-prefix: ovs-userspace-attr-
+ attributes:
+ -
+ name: pid
+ type: u32
+ -
+ name: userdata
+ type: binary
+ -
+ name: egress-tun-port
+ type: u32
+ -
+ name: actions
+ type: flag
+ -
+ name: ovs-nsh-key-attrs
+ enum-name: ovs-nsh-key-attr
+ name-prefix: ovs-nsh-key-attr-
+ attributes:
+ -
+ name: base
+ type: binary
+ -
+ name: md1
+ type: binary
+ -
+ name: md2
+ type: binary
+ -
+ name: ct-attrs
+ enum-name: ovs-ct-attr
+ name-prefix: ovs-ct-attr-
+ attributes:
+ -
+ name: commit
+ type: flag
+ -
+ name: zone
+ type: u16
+ -
+ name: mark
+ type: binary
+ -
+ name: labels
+ type: binary
+ -
+ name: helper
+ type: string
+ -
+ name: nat
+ type: nest
+ nested-attributes: nat-attrs
+ -
+ name: force-commit
+ type: flag
+ -
+ name: eventmask
+ type: u32
+ -
+ name: timeout
+ type: string
+ -
+ name: nat-attrs
+ enum-name: ovs-nat-attr
+ name-prefix: ovs-nat-attr-
+ attributes:
+ -
+ name: src
+ type: flag
+ -
+ name: dst
+ type: flag
+ -
+ name: ip-min
+ type: binary
+ -
+ name: ip-max
+ type: binary
+ -
+ name: proto-min
+ type: u16
+ -
+ name: proto-max
+ type: u16
+ -
+ name: persistent
+ type: flag
+ -
+ name: proto-hash
+ type: flag
+ -
+ name: proto-random
+ type: flag
+ -
+ name: dec-ttl-attrs
+ enum-name: ovs-dec-ttl-attr
+ name-prefix: ovs-dec-ttl-attr-
+ attributes:
+ -
+ name: action
+ type: nest
+ nested-attributes: action-attrs
+ -
+ name: vxlan-ext-attrs
+ enum-name: ovs-vxlan-ext-
+ name-prefix: ovs-vxlan-ext-
+ attributes:
+ -
+ name: gbp
+ type: u32
+
+operations:
+ name-prefix: ovs-flow-cmd-
+ fixed-header: ovs-header
+ list:
+ -
+ name: get
+ doc: Get / dump OVS flow configuration and state
+ value: 3
+ attribute-set: flow-attrs
+ do: &flow-get-op
+ request:
+ attributes:
+ - dp-ifindex
+ - key
+ - ufid
+ - ufid-flags
+ reply:
+ attributes:
+ - dp-ifindex
+ - key
+ - ufid
+ - mask
+ - stats
+ - actions
+ dump: *flow-get-op
+ -
+ name: new
+ doc: Create OVS flow configuration in a data path
+ value: 1
+ attribute-set: flow-attrs
+ do:
+ request:
+ attributes:
+ - dp-ifindex
+ - key
+ - ufid
+ - mask
+ - actions
+
+mcast-groups:
+ list:
+ -
+ name: ovs_flow
diff --git a/Documentation/netlink/specs/ovs_vport.yaml b/Documentation/netlink/specs/ovs_vport.yaml
index 8e55622..1733645 100644
--- a/Documentation/netlink/specs/ovs_vport.yaml
+++ b/Documentation/netlink/specs/ovs_vport.yaml
@@ -3,6 +3,7 @@
name: ovs_vport
version: 2
protocol: genetlink-legacy
+uapi-header: linux/openvswitch.h
doc:
OVS vport configuration over generic netlink.
@@ -18,10 +19,13 @@
-
name: vport-type
type: enum
+ enum-name: ovs-vport-type
+ name-prefix: ovs-vport-type-
entries: [ unspec, netdev, internal, gre, vxlan, geneve ]
-
name: vport-stats
type: struct
+ enum-name: ovs-vport-stats
members:
-
name: rx-packets
@@ -51,6 +55,8 @@
attribute-sets:
-
name: vport-options
+ enum-name: ovs-vport-options
+ name-prefix: ovs-tunnel-attr-
attributes:
-
name: dst-port
@@ -60,6 +66,8 @@
type: u32
-
name: upcall-stats
+ enum-name: ovs-vport-upcall-attr
+ name-prefix: ovs-vport-upcall-attr-
attributes:
-
name: success
@@ -70,6 +78,8 @@
type: u64
-
name: vport
+ name-prefix: ovs-vport-attr-
+ enum-name: ovs-vport-attr
attributes:
-
name: port-no
@@ -108,9 +118,10 @@
nested-attributes: upcall-stats
operations:
+ name-prefix: ovs-vport-cmd-
list:
-
- name: vport-get
+ name: get
doc: Get / dump OVS vport configuration and state
value: 3
attribute-set: vport
diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst
index 247c6c4..1cc35de 100644
--- a/Documentation/networking/af_xdp.rst
+++ b/Documentation/networking/af_xdp.rst
@@ -433,6 +433,15 @@
application to use. The final option is the flags field, but it will
be dealt with in separate sections for each UMEM flag.
+SO_BINDTODEVICE setsockopt
+--------------------------
+
+This is a generic SOL_SOCKET option that can be used to tie AF_XDP
+socket to a particular network interface. It is useful when a socket
+is created by a privileged process and passed to a non-privileged one.
+Once the option is set, kernel will refuse attempts to bind that socket
+to a different interface. Updating the value requires CAP_NET_RAW.
+
XDP_STATISTICS getsockopt
-------------------------
diff --git a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst
index 4118384..289c146 100644
--- a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst
+++ b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst
@@ -190,8 +190,7 @@
3. Userspace configuration
==========================
-rmnet userspace configuration is done through netlink library librmnetctl
-and command line utility rmnetcli. Utility is hosted in codeaurora forum git.
-The driver uses rtnl_link_ops for communication.
+rmnet userspace configuration is done through netlink using iproute2
+https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/
-https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/dataservices/tree/rmnetctl
+The driver uses rtnl_link_ops for communication.
diff --git a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst
index 8bcb173..5eaa3ab 100644
--- a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst
+++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst
@@ -38,6 +38,7 @@
Some of the ENA devices support a working mode called Low-latency
Queue (LLQ), which saves several more microseconds.
+
ENA Source Code Directory Structure
===================================
@@ -205,6 +206,8 @@
More information about Adaptive Interrupt Moderation (DIM) can be found in
Documentation/networking/net_dim.rst
+.. _`RX copybreak`:
+
RX copybreak
============
The rx_copybreak is initialized by default to ENA_DEFAULT_RX_COPYBREAK
@@ -315,3 +318,34 @@
- The new SKB is updated with the necessary information (protocol,
checksum hw verify result, etc), and then passed to the network
stack, using the NAPI interface function :code:`napi_gro_receive()`.
+
+Dynamic RX Buffers (DRB)
+------------------------
+
+Each RX descriptor in the RX ring is a single memory page (which is either 4KB
+or 16KB long depending on system's configurations).
+To reduce the memory allocations required when dealing with a high rate of small
+packets, the driver tries to reuse the remaining RX descriptor's space if more
+than 2KB of this page remain unused.
+
+A simple example of this mechanism is the following sequence of events:
+
+::
+
+ 1. Driver allocates page-sized RX buffer and passes it to hardware
+ +----------------------+
+ |4KB RX Buffer |
+ +----------------------+
+
+ 2. A 300Bytes packet is received on this buffer
+
+ 3. The driver increases the ref count on this page and returns it back to
+ HW as an RX buffer of size 4KB - 300Bytes = 3796 Bytes
+ +----+--------------------+
+ |****|3796 Bytes RX Buffer|
+ +----+--------------------+
+
+This mechanism isn't used when an XDP program is loaded, or when the
+RX packet is less than rx_copybreak bytes (in which case the packet is
+copied out of the RX buffer into the linear part of a new skb allocated
+for it and the RX buffer remains the same size, see `RX copybreak`_).
diff --git a/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst b/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst
new file mode 100644
index 0000000..587927d
--- /dev/null
+++ b/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst
@@ -0,0 +1,85 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. note: can be edited and viewed with /usr/bin/formiko-vim
+
+==========================================================
+PCI vDPA driver for the AMD/Pensando(R) DSC adapter family
+==========================================================
+
+AMD/Pensando vDPA VF Device Driver
+
+Copyright(c) 2023 Advanced Micro Devices, Inc
+
+Overview
+========
+
+The ``pds_vdpa`` driver is an auxiliary bus driver that supplies
+a vDPA device for use by the virtio network stack. It is used with
+the Pensando Virtual Function devices that offer vDPA and virtio queue
+services. It depends on the ``pds_core`` driver and hardware for the PF
+and VF PCI handling as well as for device configuration services.
+
+Using the device
+================
+
+The ``pds_vdpa`` device is enabled via multiple configuration steps and
+depends on the ``pds_core`` driver to create and enable SR-IOV Virtual
+Function devices. After the VFs are enabled, we enable the vDPA service
+in the ``pds_core`` device to create the auxiliary devices used by pds_vdpa.
+
+Example steps:
+
+.. code-block:: bash
+
+ #!/bin/bash
+
+ modprobe pds_core
+ modprobe vdpa
+ modprobe pds_vdpa
+
+ PF_BDF=`ls /sys/module/pds_core/drivers/pci\:pds_core/*/sriov_numvfs | awk -F / '{print $7}'`
+
+ # Enable vDPA VF auxiliary device(s) in the PF
+ devlink dev param set pci/$PF_BDF name enable_vnet cmode runtime value true
+
+ # Create a VF for vDPA use
+ echo 1 > /sys/bus/pci/drivers/pds_core/$PF_BDF/sriov_numvfs
+
+ # Find the vDPA services/devices available
+ PDS_VDPA_MGMT=`vdpa mgmtdev show | grep vDPA | head -1 | cut -d: -f1`
+
+ # Create a vDPA device for use in virtio network configurations
+ vdpa dev add name vdpa1 mgmtdev $PDS_VDPA_MGMT mac 00:11:22:33:44:55
+
+ # Set up an ethernet interface on the vdpa device
+ modprobe virtio_vdpa
+
+
+
+Enabling the driver
+===================
+
+The driver is enabled via the standard kernel configuration system,
+using the make command::
+
+ make oldconfig/menuconfig/etc.
+
+The driver is located in the menu structure at:
+
+ -> Device Drivers
+ -> Network device support (NETDEVICES [=y])
+ -> Ethernet driver support
+ -> Pensando devices
+ -> Pensando Ethernet PDS_VDPA Support
+
+Support
+=======
+
+For general Linux networking support, please use the netdev mailing
+list, which is monitored by Pensando personnel::
+
+ netdev@vger.kernel.org
+
+For more specific support needs, please use the Pensando driver support
+email::
+
+ drivers@pensando.io
diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst
index 417ca51..94ecb67 100644
--- a/Documentation/networking/device_drivers/ethernet/index.rst
+++ b/Documentation/networking/device_drivers/ethernet/index.rst
@@ -15,6 +15,7 @@
amazon/ena
altera/altera_tse
amd/pds_core
+ amd/pds_vdpa
aquantia/atlantic
chelsio/cxgb
cirrus/cs89x0
diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst
index 69695e5..e4d065c 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst
@@ -84,24 +84,6 @@
complete.
-Important notes for SR-IOV and Link Aggregation
------------------------------------------------
-Link Aggregation is mutually exclusive with SR-IOV.
-
-- If Link Aggregation is active, SR-IOV VFs cannot be created on the PF.
-- If SR-IOV is active, you cannot set up Link Aggregation on the interface.
-
-Bridging and MACVLAN are also affected by this. If you wish to use bridging or
-MACVLAN with SR-IOV, you must set up bridging or MACVLAN before enabling
-SR-IOV. If you are using bridging or MACVLAN in conjunction with SR-IOV, and
-you want to remove the interface from the bridge or MACVLAN, you must follow
-these steps:
-
-1. Destroy SR-IOV VFs if they exist
-2. Remove the interface from the bridge or MACVLAN
-3. Recreate SRIOV VFs as needed
-
-
Additional Features and Configurations
======================================
diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
index 5ba9015..bfd233c 100644
--- a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
+++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
@@ -13,6 +13,7 @@
- `Drivers`_
- `Basic packet flow`_
- `Devlink health reporters`_
+- `Quality of service`_
Overview
========
@@ -287,3 +288,47 @@
NIX_AF_ERR:
NIX Error Interrupt Reg : 64
Rx on unmapped PF_FUNC
+
+
+Quality of service
+==================
+
+
+Hardware algorithms used in scheduling
+--------------------------------------
+
+octeontx2 silicon and CN10K transmit interface consists of five transmit levels
+starting from SMQ/MDQ, TL4 to TL1. Each packet will traverse MDQ, TL4 to TL1
+levels. Each level contains an array of queues to support scheduling and shaping.
+The hardware uses the below algorithms depending on the priority of scheduler queues.
+once the usercreates tc classes with different priorities, the driver configures
+schedulers allocated to the class with specified priority along with rate-limiting
+configuration.
+
+1. Strict Priority
+
+ - Once packets are submitted to MDQ, hardware picks all active MDQs having different priority
+ using strict priority.
+
+2. Round Robin
+
+ - Active MDQs having the same priority level are chosen using round robin.
+
+
+Setup HTB offload
+-----------------
+
+1. Enable HW TC offload on the interface::
+
+ # ethtool -K <interface> hw-tc-offload on
+
+2. Crate htb root::
+
+ # tc qdisc add dev <interface> clsact
+ # tc qdisc replace dev <interface> root handle 1: htb offload
+
+3. Create tc classes with different priorities::
+
+ # tc class add dev <interface> parent 1: classid 1:1 htb rate 10Gbit prio 1
+
+ # tc class add dev <interface> parent 1: classid 1:2 htb rate 10Gbit prio 7
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst
index 6b2d1fe..a395df9 100644
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst
+++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst
@@ -797,6 +797,16 @@
RoCE/UD/RC traffic) [#accel]_.
- Acceleration
+ * - `vport_loopback_packets`
+ - Unicast, multicast and broadcast packets that were loop-back (received
+ and transmitted), IB/Eth [#accel]_.
+ - Acceleration
+
+ * - `vport_loopback_bytes`
+ - Unicast, multicast and broadcast bytes that were loop-back (received
+ and transmitted), IB/Eth [#accel]_.
+ - Acceleration
+
* - `rx_steer_missed_packets`
- Number of packets that was received by the NIC, however was discarded
because it did not match any flow in the NIC flow table.
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst
index 3354ca3..a4edf90 100644
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst
+++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst
@@ -290,6 +290,13 @@
- nic_receive_steering_discard
number of packets that completed RX flow
steering but were discarded due to a mismatch in flow table.
+- generated_pkt_steering_fail
+ number of packets generated by the VNIC experiencing unexpected steering
+ failure (at any point in steering flow).
+- handled_pkt_steering_fail
+ number of packets handled by the VNIC experiencing unexpected steering
+ failure (at any point in steering flow owned by the VNIC, including the FDB
+ for the eswitch owner).
User commands examples:
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
index 01deedb..6e3f5ee 100644
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
+++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
@@ -45,6 +45,28 @@
Subfunction
===========
+Subfunction which are spawned over the E-switch are created only with devlink
+device, and by default all the SF auxiliary devices are disabled.
+This will allow user to configure the SF before the SF have been fully probed,
+which will save time.
+
+Usage example:
+
+- Create SF::
+
+ $ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11
+ $ devlink port function set pci/0000:08:00.0/32768 hw_addr 00:00:00:00:00:11 state active
+
+- Enable ETH auxiliary device::
+
+ $ devlink dev param set auxiliary/mlx5_core.sf.1 name enable_eth value true cmode driverinit
+
+- Now, in order to fully probe the SF, use devlink reload::
+
+ $ devlink dev reload auxiliary/mlx5_core.sf.1
+
+mlx5 supports ETH,rdma and vdpa (vnet) auxiliary devices devlink params (see :ref:`Documentation/networking/devlink/devlink-params.rst <devlink_params_generic>`).
+
mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>`) interface.
A subfunction has its own function capabilities and its own resources. This
diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
index 80b8f73..4a010a7 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -881,9 +881,10 @@
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 127. Default value
- is 6, which corresponds to 63seconds till the last retransmission
- with the current initial RTO of 1second. With this the final timeout
- for an active TCP connection attempt will happen after 127seconds.
+ is 6, which corresponds to 67seconds (with tcp_syn_linear_timeouts = 4)
+ till the last retransmission with the current initial RTO of 1second.
+ With this the final timeout for an active TCP connection attempt
+ will happen after 131seconds.
tcp_timestamps - INTEGER
Enable timestamps as defined in RFC1323.
@@ -946,6 +947,16 @@
Default: 120
+tcp_syn_linear_timeouts - INTEGER
+ The number of times for an active TCP connection to retransmit SYNs with
+ a linear backoff timeout before defaulting to an exponential backoff
+ timeout. This has no effect on SYNACK at the passive TCP side.
+
+ With an initial RTO of 1 and tcp_syn_linear_timeouts = 4 we would
+ expect SYN RTOs to be: 1, 1, 1, 1, 1, 2, 4, ... (4 linear timeouts,
+ and the first exponential backoff using 2^0 * initial_RTO).
+ Default: 4
+
tcp_tso_win_divisor - INTEGER
This allows control over what percentage of the congestion window
can be consumed by a single TSO frame.
@@ -970,6 +981,21 @@
tcp_window_scaling - BOOLEAN
Enable window scaling as defined in RFC1323.
+tcp_shrink_window - BOOLEAN
+ This changes how the TCP receive window is calculated.
+
+ RFC 7323, section 2.4, says there are instances when a retracted
+ window can be offered, and that TCP implementations MUST ensure
+ that they handle a shrinking window, as specified in RFC 1122.
+
+ - 0 - Disabled. The window is never shrunk.
+ - 1 - Enabled. The window is shrunk when necessary to remain within
+ the memory limit set by autotuning (sk_rcvbuf).
+ This only occurs if a non-zero receive window
+ scaling factor is also in effect.
+
+ Default: 0
+
tcp_wmem - vector of 3 INTEGERs: min, default, max
min: Amount of memory reserved for send buffers for TCP sockets.
Each TCP socket has rights to use it due to fact of its birth.
diff --git a/Documentation/networking/napi.rst b/Documentation/networking/napi.rst
index a7a0477..7bf7b95 100644
--- a/Documentation/networking/napi.rst
+++ b/Documentation/networking/napi.rst
@@ -65,15 +65,16 @@
packets but should only process up to ``budget`` number of
Rx packets. Rx processing is usually much more expensive.
-In other words, it is recommended to ignore the budget argument when
-performing TX buffer reclamation to ensure that the reclamation is not
-arbitrarily bounded; however, it is required to honor the budget argument
-for RX processing.
+In other words for Rx processing the ``budget`` argument limits how many
+packets driver can process in a single poll. Rx specific APIs like page
+pool or XDP cannot be used at all when ``budget`` is 0.
+skb Tx processing should happen regardless of the ``budget``, but if
+the argument is 0 driver cannot call any XDP (or page pool) APIs.
.. warning::
- The ``budget`` argument may be 0 if core tries to only process Tx completions
- and no Rx packets.
+ The ``budget`` argument may be 0 if core tries to only process
+ skb Tx completions and no Rx or XDP packets.
The poll method returns the amount of work done. If the driver still
has outstanding work to do (e.g. ``budget`` was exhausted)
diff --git a/Documentation/networking/scaling.rst b/Documentation/networking/scaling.rst
index 3d435ca..92c9fb46 100644
--- a/Documentation/networking/scaling.rst
+++ b/Documentation/networking/scaling.rst
@@ -269,8 +269,8 @@
rps_sock_flow_table is a global flow table that contains the *desired* CPU
for flows: the CPU that is currently processing the flow in userspace.
Each table value is a CPU index that is updated during calls to recvmsg
-and sendmsg (specifically, inet_recvmsg(), inet_sendmsg(), inet_sendpage()
-and tcp_splice_read()).
+and sendmsg (specifically, inet_recvmsg(), inet_sendmsg() and
+tcp_splice_read()).
When the scheduler moves a thread to a new CPU while it has outstanding
receive packets on the old CPU, packets may arrive out of order. To
diff --git a/Documentation/powerpc/dexcr.rst b/Documentation/powerpc/dexcr.rst
new file mode 100644
index 0000000..615a631f
--- /dev/null
+++ b/Documentation/powerpc/dexcr.rst
@@ -0,0 +1,58 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==========================================
+DEXCR (Dynamic Execution Control Register)
+==========================================
+
+Overview
+========
+
+The DEXCR is a privileged special purpose register (SPR) introduced in
+PowerPC ISA 3.1B (Power10) that allows per-cpu control over several dynamic
+execution behaviours. These behaviours include speculation (e.g., indirect
+branch target prediction) and enabling return-oriented programming (ROP)
+protection instructions.
+
+The execution control is exposed in hardware as up to 32 bits ('aspects') in
+the DEXCR. Each aspect controls a certain behaviour, and can be set or cleared
+to enable/disable the aspect. There are several variants of the DEXCR for
+different purposes:
+
+DEXCR
+ A privileged SPR that can control aspects for userspace and kernel space
+HDEXCR
+ A hypervisor-privileged SPR that can control aspects for the hypervisor and
+ enforce aspects for the kernel and userspace.
+UDEXCR
+ An optional ultravisor-privileged SPR that can control aspects for the ultravisor.
+
+Userspace can examine the current DEXCR state using a dedicated SPR that
+provides a non-privileged read-only view of the userspace DEXCR aspects.
+There is also an SPR that provides a read-only view of the hypervisor enforced
+aspects, which ORed with the userspace DEXCR view gives the effective DEXCR
+state for a process.
+
+
+Configuration
+=============
+
+The DEXCR is currently unconfigurable. All threads are run with the
+NPHIE aspect enabled.
+
+
+coredump and ptrace
+===================
+
+The userspace values of the DEXCR and HDEXCR (in this order) are exposed under
+``NT_PPC_DEXCR``. These are each 64 bits and readonly, and are intended to
+assist with core dumps. The DEXCR may be made writable in future. The top 32
+bits of both registers (corresponding to the non-userspace bits) are masked off.
+
+If the kernel config ``CONFIG_CHECKPOINT_RESTORE`` is enabled, then
+``NT_PPC_HASHKEYR`` is available and exposes the HASHKEYR value of the process
+for reading and writing. This is a tradeoff between increased security and
+checkpoint/restore support: a process should normally have no need to know its
+secret key, but restoring a process requires setting its original key. The key
+therefore appears in core dumps, and an attacker may be able to retrieve it from
+a coredump and effectively bypass ROP protection on any threads that share this
+key (potentially all threads from the same parent that have not run ``exec()``).
diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst
index 85e80e3..d33b554 100644
--- a/Documentation/powerpc/index.rst
+++ b/Documentation/powerpc/index.rst
@@ -15,6 +15,7 @@
cxl
cxlflash
dawr-power9
+ dexcr
dscr
eeh-pci-error-recovery
elf_hwcaps
diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index 6a919cf..613a01d 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -434,9 +434,10 @@
questions. Some developers can get impatient with people who clearly
have not done their homework.
-- Avoid top-posting (the practice of putting your answer above the quoted
- text you are responding to). It makes your response harder to read and
- makes a poor impression.
+- Use interleaved ("inline") replies, which makes your response easier to
+ read. (i.e. avoid top-posting -- the practice of putting your answer above
+ the quoted text you are responding to.) For more details, see
+ :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`.
- Ask on the correct mailing list. Linux-kernel may be the general meeting
point, but it is not the best place to find developers from all
diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst
index a173cd5..66fa400 100644
--- a/Documentation/process/6.Followthrough.rst
+++ b/Documentation/process/6.Followthrough.rst
@@ -51,6 +51,13 @@
working toward the creation of the best kernel they can; they are not
trying to create discomfort for their employers' competitors.
+ - Be prepared for seemingly silly requests for coding style changes
+ and requests to factor out some of your code to shared parts of
+ the kernel. One job the maintainers do is to keep things looking
+ the same. Sometimes this means that the clever hack in your driver
+ to get around a problem actually needs to become a generalized
+ kernel feature ready for next time.
+
What all of this comes down to is that, when reviewers send you comments,
you need to pay attention to the technical observations that they are
making. Do not let their form of expression or your own pride keep that
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index ef54086..5561dae 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -31,7 +31,7 @@
====================== =============== ========================================
GNU C 5.1 gcc --version
Clang/LLVM (optional) 11.0.0 clang --version
-Rust (optional) 1.62.0 rustc --version
+Rust (optional) 1.68.2 rustc --version
bindgen (optional) 0.56.0 bindgen --version
GNU make 3.82 make --version
bash 4.2 bash --version
@@ -60,6 +60,8 @@
bc 1.06.95 bc --version
Sphinx\ [#f1]_ 1.7 sphinx-build --version
cpio any cpio --version
+GNU tar 1.28 tar --version
+gtags (optional) 6.6.5 gtags --version
====================== =============== ========================================
.. [#f1] Sphinx is needed only to build the Kernel documentation
@@ -174,6 +176,18 @@
enabled. You will also need openssl development packages to build kernels 4.3
and higher.
+Tar
+---
+
+GNU tar is needed if you want to enable access to the kernel headers via sysfs
+(CONFIG_IKHEADERS).
+
+gtags / GNU GLOBAL (optional)
+-----------------------------
+
+The kernel build requires GNU GLOBAL version 6.6.5 or later to generate
+tag files through ``make gtags``. This is due to its use of the gtags
+``-C (--directory)`` flag.
System utilities
****************
diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst
index df97812..cb68623 100644
--- a/Documentation/process/embargoed-hardware-issues.rst
+++ b/Documentation/process/embargoed-hardware-issues.rst
@@ -254,7 +254,6 @@
Samsung Javier González <javier.gonz@samsung.com>
Microsoft James Morris <jamorris@linux.microsoft.com>
- VMware
Xen Andrew Cooper <andrew.cooper3@citrix.com>
Canonical John Johansen <john.johansen@canonical.com>
@@ -263,10 +262,8 @@
Red Hat Josh Poimboeuf <jpoimboe@redhat.com>
SUSE Jiri Kosina <jkosina@suse.cz>
- Amazon
Google Kees Cook <keescook@chromium.org>
- GCC
LLVM Nick Desaulniers <ndesaulniers@google.com>
============= ========================================================
diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst
index abb741b..5d3c3de 100644
--- a/Documentation/process/handling-regressions.rst
+++ b/Documentation/process/handling-regressions.rst
@@ -129,88 +129,132 @@
these tools is regzbot, which heavily relies on the "Link:" tags to associate
reports for regression with changes resolving them.
-Prioritize work on fixing regressions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Expectations and best practices for fixing regressions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-You should fix any reported regression as quickly as possible, to provide
-affected users with a solution in a timely manner and prevent more users from
-running into the issue; nevertheless developers need to take enough time and
-care to ensure regression fixes do not cause additional damage.
+As a Linux kernel developer, you are expected to give your best to prevent
+situations where a regression caused by a recent change of yours leaves users
+only these options:
-In the end though, developers should give their best to prevent users from
-running into situations where a regression leaves them only three options: "run
-a kernel with a regression that seriously impacts usage", "continue running an
-outdated and thus potentially insecure kernel version for more than two weeks
-after a regression's culprit was identified", and "downgrade to a still
-supported kernel series that lack required features".
+ * Run a kernel with a regression that impacts usage.
-How to realize this depends a lot on the situation. Here are a few rules of
-thumb for you, in order or importance:
+ * Switch to an older or newer kernel series.
- * Prioritize work on handling regression reports and fixing regression over all
- other Linux kernel work, unless the latter concerns acute security issues or
- bugs causing data loss or damage.
+ * Continue running an outdated and thus potentially insecure kernel for more
+ than three weeks after the regression's culprit was identified. Ideally it
+ should be less than two. And it ought to be just a few days, if the issue is
+ severe or affects many users -- either in general or in prevalent
+ environments.
- * Always consider reverting the culprit commits and reapplying them later
- together with necessary fixes, as this might be the least dangerous and
- quickest way to fix a regression.
+How to realize that in practice depends on various factors. Use the following
+rules of thumb as a guide.
- * Developers should handle regressions in all supported kernel series, but are
- free to delegate the work to the stable team, if the issue probably at no
- point in time occurred with mainline.
+In general:
- * Try to resolve any regressions introduced in the current development before
- its end. If you fear a fix might be too risky to apply only days before a new
- mainline release, let Linus decide: submit the fix separately to him as soon
- as possible with the explanation of the situation. He then can make a call
- and postpone the release if necessary, for example if multiple such changes
- show up in his inbox.
+ * Prioritize work on regressions over all other Linux kernel work, unless the
+ latter concerns a severe issue (e.g. acute security vulnerability, data loss,
+ bricked hardware, ...).
- * Address regressions in stable, longterm, or proper mainline releases with
- more urgency than regressions in mainline pre-releases. That changes after
- the release of the fifth pre-release, aka "-rc5": mainline then becomes as
- important, to ensure all the improvements and fixes are ideally tested
- together for at least one week before Linus releases a new mainline version.
+ * Expedite fixing mainline regressions that recently made it into a proper
+ mainline, stable, or longterm release (either directly or via backport).
- * Fix regressions within two or three days, if they are critical for some
- reason -- for example, if the issue is likely to affect many users of the
- kernel series in question on all or certain architectures. Note, this
- includes mainline, as issues like compile errors otherwise might prevent many
- testers or continuous integration systems from testing the series.
+ * Do not consider regressions from the current cycle as something that can wait
+ till the end of the cycle, as the issue might discourage or prevent users and
+ CI systems from testing mainline now or generally.
- * Aim to fix regressions within one week after the culprit was identified, if
- the issue was introduced in either:
+ * Work with the required care to avoid additional or bigger damage, even if
+ resolving an issue then might take longer than outlined below.
- * a recent stable/longterm release
+On timing once the culprit of a regression is known:
- * the development cycle of the latest proper mainline release
+ * Aim to mainline a fix within two or three days, if the issue is severe or
+ bothering many users -- either in general or in prevalent conditions like a
+ particular hardware environment, distribution, or stable/longterm series.
- In the latter case (say Linux v5.14), try to address regressions even
- quicker, if the stable series for the predecessor (v5.13) will be abandoned
- soon or already was stamped "End-of-Life" (EOL) -- this usually happens about
- three to four weeks after a new mainline release.
+ * Aim to mainline a fix by Sunday after the next, if the culprit made it
+ into a recent mainline, stable, or longterm release (either directly or via
+ backport); if the culprit became known early during a week and is simple to
+ resolve, try to mainline the fix within the same week.
- * Try to fix all other regressions within two weeks after the culprit was
- found. Two or three additional weeks are acceptable for performance
- regressions and other issues which are annoying, but don't prevent anyone
- from running Linux (unless it's an issue in the current development cycle,
- as those should ideally be addressed before the release). A few weeks in
- total are acceptable if a regression can only be fixed with a risky change
- and at the same time is affecting only a few users; as much time is
- also okay if the regression is already present in the second newest longterm
- kernel series.
+ * For other regressions, aim to mainline fixes before the hindmost Sunday
+ within the next three weeks. One or two Sundays later are acceptable, if the
+ regression is something people can live with easily for a while -- like a
+ mild performance regression.
-Note: The aforementioned time frames for resolving regressions are meant to
-include getting the fix tested, reviewed, and merged into mainline, ideally with
-the fix being in linux-next at least briefly. This leads to delays you need to
-account for.
+ * It's strongly discouraged to delay mainlining regression fixes till the next
+ merge window, except when the fix is extraordinarily risky or when the
+ culprit was mainlined more than a year ago.
-Subsystem maintainers are expected to assist in reaching those periods by doing
-timely reviews and quick handling of accepted patches. They thus might have to
-send git-pull requests earlier or more often than usual; depending on the fix,
-it might even be acceptable to skip testing in linux-next. Especially fixes for
-regressions in stable and longterm kernels need to be handled quickly, as fixes
-need to be merged in mainline before they can be backported to older series.
+On procedure:
+
+ * Always consider reverting the culprit, as it's often the quickest and least
+ dangerous way to fix a regression. Don't worry about mainlining a fixed
+ variant later: that should be straight-forward, as most of the code went
+ through review once already.
+
+ * Try to resolve any regressions introduced in mainline during the past
+ twelve months before the current development cycle ends: Linus wants such
+ regressions to be handled like those from the current cycle, unless fixing
+ bears unusual risks.
+
+ * Consider CCing Linus on discussions or patch review, if a regression seems
+ tangly. Do the same in precarious or urgent cases -- especially if the
+ subsystem maintainer might be unavailable. Also CC the stable team, when you
+ know such a regression made it into a mainline, stable, or longterm release.
+
+ * For urgent regressions, consider asking Linus to pick up the fix straight
+ from the mailing list: he is totally fine with that for uncontroversial
+ fixes. Ideally though such requests should happen in accordance with the
+ subsystem maintainers or come directly from them.
+
+ * In case you are unsure if a fix is worth the risk applying just days before
+ a new mainline release, send Linus a mail with the usual lists and people in
+ CC; in it, summarize the situation while asking him to consider picking up
+ the fix straight from the list. He then himself can make the call and when
+ needed even postpone the release. Such requests again should ideally happen
+ in accordance with the subsystem maintainers or come directly from them.
+
+Regarding stable and longterm kernels:
+
+ * You are free to leave regressions to the stable team, if they at no point in
+ time occurred with mainline or were fixed there already.
+
+ * If a regression made it into a proper mainline release during the past
+ twelve months, ensure to tag the fix with "Cc: stable@vger.kernel.org", as a
+ "Fixes:" tag alone does not guarantee a backport. Please add the same tag,
+ in case you know the culprit was backported to stable or longterm kernels.
+
+ * When receiving reports about regressions in recent stable or longterm kernel
+ series, please evaluate at least briefly if the issue might happen in current
+ mainline as well -- and if that seems likely, take hold of the report. If in
+ doubt, ask the reporter to check mainline.
+
+ * Whenever you want to swiftly resolve a regression that recently also made it
+ into a proper mainline, stable, or longterm release, fix it quickly in
+ mainline; when appropriate thus involve Linus to fast-track the fix (see
+ above). That's because the stable team normally does neither revert nor fix
+ any changes that cause the same problems in mainline.
+
+ * In case of urgent regression fixes you might want to ensure prompt
+ backporting by dropping the stable team a note once the fix was mainlined;
+ this is especially advisable during merge windows and shortly thereafter, as
+ the fix otherwise might land at the end of a huge patch queue.
+
+On patch flow:
+
+ * Developers, when trying to reach the time periods mentioned above, remember
+ to account for the time it takes to get fixes tested, reviewed, and merged by
+ Linus, ideally with them being in linux-next at least briefly. Hence, if a
+ fix is urgent, make it obvious to ensure others handle it appropriately.
+
+ * Reviewers, you are kindly asked to assist developers in reaching the time
+ periods mentioned above by reviewing regression fixes in a timely manner.
+
+ * Subsystem maintainers, you likewise are encouraged to expedite the handling
+ of regression fixes. Thus evaluate if skipping linux-next is an option for
+ the particular fix. Also consider sending git pull requests more often than
+ usual when needed. And try to avoid holding onto regression fixes over
+ weekends -- especially when the fix is marked for backporting.
More aspects regarding regressions developers should be aware of
diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst
index d783060..9992bfd 100644
--- a/Documentation/process/maintainer-handbooks.rst
+++ b/Documentation/process/maintainer-handbooks.rst
@@ -15,5 +15,7 @@
:numbered:
:maxdepth: 2
- maintainer-tip
maintainer-netdev
+ maintainer-soc
+ maintainer-tip
+ maintainer-kvm-x86
diff --git a/Documentation/process/maintainer-kvm-x86.rst b/Documentation/process/maintainer-kvm-x86.rst
new file mode 100644
index 0000000..9183bd4
--- /dev/null
+++ b/Documentation/process/maintainer-kvm-x86.rst
@@ -0,0 +1,390 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+KVM x86
+=======
+
+Foreword
+--------
+KVM strives to be a welcoming community; contributions from newcomers are
+valued and encouraged. Please do not be discouraged or intimidated by the
+length of this document and the many rules/guidelines it contains. Everyone
+makes mistakes, and everyone was a newbie at some point. So long as you make
+an honest effort to follow KVM x86's guidelines, are receptive to feedback,
+and learn from any mistakes you make, you will be welcomed with open arms, not
+torches and pitchforks.
+
+TL;DR
+-----
+Testing is mandatory. Be consistent with established styles and patterns.
+
+Trees
+-----
+KVM x86 is currently in a transition period from being part of the main KVM
+tree, to being "just another KVM arch". As such, KVM x86 is split across the
+main KVM tree, ``git.kernel.org/pub/scm/virt/kvm/kvm.git``, and a KVM x86
+specific tree, ``github.com/kvm-x86/linux.git``.
+
+Generally speaking, fixes for the current cycle are applied directly to the
+main KVM tree, while all development for the next cycle is routed through the
+KVM x86 tree. In the unlikely event that a fix for the current cycle is routed
+through the KVM x86 tree, it will be applied to the ``fixes`` branch before
+making its way to the main KVM tree.
+
+Note, this transition period is expected to last quite some time, i.e. will be
+the status quo for the foreseeable future.
+
+Branches
+~~~~~~~~
+The KVM x86 tree is organized into multiple topic branches. The purpose of
+using finer-grained topic branches is to make it easier to keep tabs on an area
+of development, and to limit the collateral damage of human errors and/or buggy
+commits, e.g. dropping the HEAD commit of a topic branch has no impact on other
+in-flight commits' SHA1 hashes, and having to reject a pull request due to bugs
+delays only that topic branch.
+
+All topic branches, except for ``next`` and ``fixes``, are rolled into ``next``
+via a Cthulhu merge on an as-needed basis, i.e. when a topic branch is updated.
+As a result, force pushes to ``next`` are common.
+
+Lifecycle
+~~~~~~~~~
+Fixes that target the current release, a.k.a. mainline, are typically applied
+directly to the main KVM tree, i.e. do not route through the KVM x86 tree.
+
+Changes that target the next release are routed through the KVM x86 tree. Pull
+requests (from KVM x86 to main KVM) are sent for each KVM x86 topic branch,
+typically the week before Linus' opening of the merge window, e.g. the week
+following rc7 for "normal" releases. If all goes well, the topic branches are
+rolled into the main KVM pull request sent during Linus' merge window.
+
+The KVM x86 tree doesn't have its own official merge window, but there's a soft
+close around rc5 for new features, and a soft close around rc6 for fixes (for
+the next release; see above for fixes that target the current release).
+
+Timeline
+~~~~~~~~
+Submissions are typically reviewed and applied in FIFO order, with some wiggle
+room for the size of a series, patches that are "cache hot", etc. Fixes,
+especially for the current release and or stable trees, get to jump the queue.
+Patches that will be taken through a non-KVM tree (most often through the tip
+tree) and/or have other acks/reviews also jump the queue to some extent.
+
+Note, the vast majority of review is done between rc1 and rc6, give or take.
+The period between rc6 and the next rc1 is used to catch up on other tasks,
+i.e. radio silence during this period isn't unusual.
+
+Pings to get a status update are welcome, but keep in mind the timing of the
+current release cycle and have realistic expectations. If you are pinging for
+acceptance, i.e. not just for feedback or an update, please do everything you
+can, within reason, to ensure that your patches are ready to be merged! Pings
+on series that break the build or fail tests lead to unhappy maintainers!
+
+Development
+-----------
+
+Base Tree/Branch
+~~~~~~~~~~~~~~~~
+Fixes that target the current release, a.k.a. mainline, should be based on
+``git://git.kernel.org/pub/scm/virt/kvm/kvm.git master``. Note, fixes do not
+automatically warrant inclusion in the current release. There is no singular
+rule, but typically only fixes for bugs that are urgent, critical, and/or were
+introduced in the current release should target the current release.
+
+Everything else should be based on ``kvm-x86/next``, i.e. there is no need to
+select a specific topic branch as the base. If there are conflicts and/or
+dependencies across topic branches, it is the maintainer's job to sort them
+out.
+
+The only exception to using ``kvm-x86/next`` as the base is if a patch/series
+is a multi-arch series, i.e. has non-trivial modifications to common KVM code
+and/or has more than superficial changes to other architectures' code. Multi-
+arch patch/series should instead be based on a common, stable point in KVM's
+history, e.g. the release candidate upon which ``kvm-x86 next`` is based. If
+you're unsure whether a patch/series is truly multi-arch, err on the side of
+caution and treat it as multi-arch, i.e. use a common base.
+
+Coding Style
+~~~~~~~~~~~~
+When it comes to style, naming, patterns, etc., consistency is the number one
+priority in KVM x86. If all else fails, match what already exists.
+
+With a few caveats listed below, follow the tip tree maintainers' preferred
+:ref:`maintainer-tip-coding-style`, as patches/series often touch both KVM and
+non-KVM x86 files, i.e. draw the attention of KVM *and* tip tree maintainers.
+
+Using reverse fir tree, a.k.a. reverse Christmas tree or reverse XMAS tree, for
+variable declarations isn't strictly required, though it is still preferred.
+
+Except for a handful of special snowflakes, do not use kernel-doc comments for
+functions. The vast majority of "public" KVM functions aren't truly public as
+they are intended only for KVM-internal consumption (there are plans to
+privatize KVM's headers and exports to enforce this).
+
+Comments
+~~~~~~~~
+Write comments using imperative mood and avoid pronouns. Use comments to
+provide a high level overview of the code, and/or to explain why the code does
+what it does. Do not reiterate what the code literally does; let the code
+speak for itself. If the code itself is inscrutable, comments will not help.
+
+SDM and APM References
+~~~~~~~~~~~~~~~~~~~~~~
+Much of KVM's code base is directly tied to architectural behavior defined in
+Intel's Software Development Manual (SDM) and AMD's Architecture Programmer’s
+Manual (APM). Use of "Intel's SDM" and "AMD's APM", or even just "SDM" or
+"APM", without additional context is a-ok.
+
+Do not reference specific sections, tables, figures, etc. by number, especially
+not in comments. Instead, if necessary (see below), copy-paste the relevant
+snippet and reference sections/tables/figures by name. The layouts of the SDM
+and APM are constantly changing, and so the numbers/labels aren't stable.
+
+Generally speaking, do not explicitly reference or copy-paste from the SDM or
+APM in comments. With few exceptions, KVM *must* honor architectural behavior,
+therefore it's implied that KVM behavior is emulating SDM and/or APM behavior.
+Note, referencing the SDM/APM in changelogs to justify the change and provide
+context is perfectly ok and encouraged.
+
+Shortlog
+~~~~~~~~
+The preferred prefix format is ``KVM: <topic>:``, where ``<topic>`` is one of::
+
+ - x86
+ - x86/mmu
+ - x86/pmu
+ - x86/xen
+ - selftests
+ - SVM
+ - nSVM
+ - VMX
+ - nVMX
+
+**DO NOT use x86/kvm!** ``x86/kvm`` is used exclusively for Linux-as-a-KVM-guest
+changes, i.e. for arch/x86/kernel/kvm.c. Do not use file names or complete file
+paths as the subject/shortlog prefix.
+
+Note, these don't align with the topics branches (the topic branches care much
+more about code conflicts).
+
+All names are case sensitive! ``KVM: x86:`` is good, ``kvm: vmx:`` is not.
+
+Capitalize the first word of the condensed patch description, but omit ending
+punctionation. E.g.::
+
+ KVM: x86: Fix a null pointer dereference in function_xyz()
+
+not::
+
+ kvm: x86: fix a null pointer dereference in function_xyz.
+
+If a patch touches multiple topics, traverse up the conceptual tree to find the
+first common parent (which is often simply ``x86``). When in doubt,
+``git log path/to/file`` should provide a reasonable hint.
+
+New topics do occasionally pop up, but please start an on-list discussion if
+you want to propose introducing a new topic, i.e. don't go rogue.
+
+See :ref:`the_canonical_patch_format` for more information, with one amendment:
+do not treat the 70-75 character limit as an absolute, hard limit. Instead,
+use 75 characters as a firm-but-not-hard limit, and use 80 characters as a hard
+limit. I.e. let the shortlog run a few characters over the standard limit if
+you have good reason to do so.
+
+Changelog
+~~~~~~~~~
+Most importantly, write changelogs using imperative mood and avoid pronouns.
+
+See :ref:`describe_changes` for more information, with one amendment: lead with
+a short blurb on the actual changes, and then follow up with the context and
+background. Note! This order directly conflicts with the tip tree's preferred
+approach! Please follow the tip tree's preferred style when sending patches
+that primarily target arch/x86 code that is _NOT_ KVM code.
+
+Stating what a patch does before diving into details is preferred by KVM x86
+for several reasons. First and foremost, what code is actually being changed
+is arguably the most important information, and so that info should be easy to
+find. Changelogs that bury the "what's actually changing" in a one-liner after
+3+ paragraphs of background make it very hard to find that information.
+
+For initial review, one could argue the "what's broken" is more important, but
+for skimming logs and git archaeology, the gory details matter less and less.
+E.g. when doing a series of "git blame", the details of each change along the
+way are useless, the details only matter for the culprit. Providing the "what
+changed" makes it easy to quickly determine whether or not a commit might be of
+interest.
+
+Another benefit of stating "what's changing" first is that it's almost always
+possible to state "what's changing" in a single sentence. Conversely, all but
+the most simple bugs require multiple sentences or paragraphs to fully describe
+the problem. If both the "what's changing" and "what's the bug" are super
+short then the order doesn't matter. But if one is shorter (almost always the
+"what's changing), then covering the shorter one first is advantageous because
+it's less of an inconvenience for readers/reviewers that have a strict ordering
+preference. E.g. having to skip one sentence to get to the context is less
+painful than having to skip three paragraphs to get to "what's changing".
+
+Fixes
+~~~~~
+If a change fixes a KVM/kernel bug, add a Fixes: tag even if the change doesn't
+need to be backported to stable kernels, and even if the change fixes a bug in
+an older release.
+
+Conversely, if a fix does need to be backported, explicitly tag the patch with
+"Cc: stable@vger.kernel" (though the email itself doesn't need to Cc: stable);
+KVM x86 opts out of backporting Fixes: by default. Some auto-selected patches
+do get backported, but require explicit maintainer approval (search MANUALSEL).
+
+Function References
+~~~~~~~~~~~~~~~~~~~
+When a function is mentioned in a comment, changelog, or shortlog (or anywhere
+for that matter), use the format ``function_name()``. The parentheses provide
+context and disambiguate the reference.
+
+Testing
+-------
+At a bare minimum, *all* patches in a series must build cleanly for KVM_INTEL=m
+KVM_AMD=m, and KVM_WERROR=y. Building every possible combination of Kconfigs
+isn't feasible, but the more the merrier. KVM_SMM, KVM_XEN, PROVE_LOCKING, and
+X86_64 are particularly interesting knobs to turn.
+
+Running KVM selftests and KVM-unit-tests is also mandatory (and stating the
+obvious, the tests need to pass). The only exception is for changes that have
+negligible probability of affecting runtime behavior, e.g. patches that only
+modify comments. When possible and relevant, testing on both Intel and AMD is
+strongly preferred. Booting an actual VM is encouraged, but not mandatory.
+
+For changes that touch KVM's shadow paging code, running with TDP (EPT/NPT)
+disabled is mandatory. For changes that affect common KVM MMU code, running
+with TDP disabled is strongly encouraged. For all other changes, if the code
+being modified depends on and/or interacts with a module param, testing with
+the relevant settings is mandatory.
+
+Note, KVM selftests and KVM-unit-tests do have known failures. If you suspect
+a failure is not due to your changes, verify that the *exact same* failure
+occurs with and without your changes.
+
+Changes that touch reStructured Text documentation, i.e. .rst files, must build
+htmldocs cleanly, i.e. with no new warnings or errors.
+
+If you can't fully test a change, e.g. due to lack of hardware, clearly state
+what level of testing you were able to do, e.g. in the cover letter.
+
+New Features
+~~~~~~~~~~~~
+With one exception, new features *must* come with test coverage. KVM specific
+tests aren't strictly required, e.g. if coverage is provided by running a
+sufficiently enabled guest VM, or by running a related kernel selftest in a VM,
+but dedicated KVM tests are preferred in all cases. Negative testcases in
+particular are mandatory for enabling of new hardware features as error and
+exception flows are rarely exercised simply by running a VM.
+
+The only exception to this rule is if KVM is simply advertising support for a
+feature via KVM_GET_SUPPORTED_CPUID, i.e. for instructions/features that KVM
+can't prevent a guest from using and for which there is no true enabling.
+
+Note, "new features" does not just mean "new hardware features"! New features
+that can't be well validated using existing KVM selftests and/or KVM-unit-tests
+must come with tests.
+
+Posting new feature development without tests to get early feedback is more
+than welcome, but such submissions should be tagged RFC, and the cover letter
+should clearly state what type of feedback is requested/expected. Do not abuse
+the RFC process; RFCs will typically not receive in-depth review.
+
+Bug Fixes
+~~~~~~~~~
+Except for "obvious" found-by-inspection bugs, fixes must be accompanied by a
+reproducer for the bug being fixed. In many cases the reproducer is implicit,
+e.g. for build errors and test failures, but it should still be clear to
+readers what is broken and how to verify the fix. Some leeway is given for
+bugs that are found via non-public workloads/tests, but providing regression
+tests for such bugs is strongly preferred.
+
+In general, regression tests are preferred for any bug that is not trivial to
+hit. E.g. even if the bug was originally found by a fuzzer such as syzkaller,
+a targeted regression test may be warranted if the bug requires hitting a
+one-in-a-million type race condition.
+
+Note, KVM bugs are rarely urgent *and* non-trivial to reproduce. Ask yourself
+if a bug is really truly the end of the world before posting a fix without a
+reproducer.
+
+Posting
+-------
+
+Links
+~~~~~
+Do not explicitly reference bug reports, prior versions of a patch/series, etc.
+via ``In-Reply-To:`` headers. Using ``In-Reply-To:`` becomes an unholy mess
+for large series and/or when the version count gets high, and ``In-Reply-To:``
+is useless for anyone that doesn't have the original message, e.g. if someone
+wasn't Cc'd on the bug report or if the list of recipients changes between
+versions.
+
+To link to a bug report, previous version, or anything of interest, use lore
+links. For referencing previous version(s), generally speaking do not include
+a Link: in the changelog as there is no need to record the history in git, i.e.
+put the link in the cover letter or in the section git ignores. Do provide a
+formal Link: for bug reports and/or discussions that led to the patch. The
+context of why a change was made is highly valuable for future readers.
+
+Git Base
+~~~~~~~~
+If you are using git version 2.9.0 or later (Googlers, this is all of you!),
+use ``git format-patch`` with the ``--base`` flag to automatically include the
+base tree information in the generated patches.
+
+Note, ``--base=auto`` works as expected if and only if a branch's upstream is
+set to the base topic branch, e.g. it will do the wrong thing if your upstream
+is set to your personal repository for backup purposes. An alternative "auto"
+solution is to derive the names of your development branches based on their
+KVM x86 topic, and feed that into ``--base``. E.g. ``x86/pmu/my_branch_name``,
+and then write a small wrapper to extract ``pmu`` from the current branch name
+to yield ``--base=x/pmu``, where ``x`` is whatever name your repository uses to
+track the KVM x86 remote.
+
+Co-Posting Tests
+~~~~~~~~~~~~~~~~
+KVM selftests that are associated with KVM changes, e.g. regression tests for
+bug fixes, should be posted along with the KVM changes as a single series. The
+standard kernel rules for bisection apply, i.e. KVM changes that result in test
+failures should be ordered after the selftests updates, and vice versa, new
+tests that fail due to KVM bugs should be ordered after the KVM fixes.
+
+KVM-unit-tests should *always* be posted separately. Tools, e.g. b4 am, don't
+know that KVM-unit-tests is a separate repository and get confused when patches
+in a series apply on different trees. To tie KVM-unit-tests patches back to
+KVM patches, first post the KVM changes and then provide a lore Link: to the
+KVM patch/series in the KVM-unit-tests patch(es).
+
+Notifications
+-------------
+When a patch/series is officially accepted, a notification email will be sent
+in reply to the original posting (cover letter for multi-patch series). The
+notification will include the tree and topic branch, along with the SHA1s of
+the commits of applied patches.
+
+If a subset of patches is applied, this will be clearly stated in the
+notification. Unless stated otherwise, it's implied that any patches in the
+series that were not accepted need more work and should be submitted in a new
+version.
+
+If for some reason a patch is dropped after officially being accepted, a reply
+will be sent to the notification email explaining why the patch was dropped, as
+well as the next steps.
+
+SHA1 Stability
+~~~~~~~~~~~~~~
+SHA1s are not 100% guaranteed to be stable until they land in Linus' tree! A
+SHA1 is *usually* stable once a notification has been sent, but things happen.
+In most cases, an update to the notification email be provided if an applied
+patch's SHA1 changes. However, in some scenarios, e.g. if all KVM x86 branches
+need to be rebased, individual notifications will not be given.
+
+Vulnerabilities
+---------------
+Bugs that can be exploited by the guest to attack the host (kernel or
+userspace), or that can be exploited by a nested VM to *its* host (L2 attacking
+L1), are of particular interest to KVM. Please follow the protocol for
+:ref:`securitybugs` if you suspect a bug can lead to an escape, data leak, etc.
+
diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index 83614ce..2ab843c 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -98,7 +98,7 @@
repository link above for any new networking-related commits. You may
also check the following website for the current status:
- http://vger.kernel.org/~davem/net-next.html
+ https://patchwork.hopto.org/net-next.html
The ``net`` tree continues to collect fixes for the vX.Y content, and is
fed back to Linus at regular (~weekly) intervals. Meaning that the
@@ -149,8 +149,11 @@
of communicating with the bot, the bot commands should be seen as metadata.
The use of the bot is restricted to authors of the patches (the ``From:``
-header on patch submission and command must match!), maintainers themselves
-and a handful of senior reviewers. Bot records its activity here:
+header on patch submission and command must match!), maintainers of
+the modified code according to the MAINTAINERS file (again, ``From:``
+must match the MAINTAINERS entry) and a handful of senior reviewers.
+
+Bot records its activity here:
https://patchwork.hopto.org/pw-bot.html
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
new file mode 100644
index 0000000..49f0828
--- /dev/null
+++ b/Documentation/process/maintainer-soc.rst
@@ -0,0 +1,177 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+SoC Subsystem
+=============
+
+Overview
+--------
+
+The SoC subsystem is a place of aggregation for SoC-specific code.
+The main components of the subsystem are:
+
+* devicetrees for 32- & 64-bit ARM and RISC-V
+* 32-bit ARM board files (arch/arm/mach*)
+* 32- & 64-bit ARM defconfigs
+* SoC-specific drivers across architectures, in particular for 32- & 64-bit
+ ARM, RISC-V and Loongarch
+
+These "SoC-specific drivers" do not include clock, GPIO etc drivers that have
+other top-level maintainers. The drivers/soc/ directory is generally meant
+for kernel-internal drivers that are used by other drivers to provide SoC-
+specific functionality like identifying an SoC revision or interfacing with
+power domains.
+
+The SoC subsystem also serves as an intermediate location for changes to
+drivers/bus, drivers/firmware, drivers/reset and drivers/memory. The addition
+of new platforms, or the removal of existing ones, often go through the SoC
+tree as a dedicated branch covering multiple subsystems.
+
+The main SoC tree is housed on git.kernel.org:
+ https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/
+
+Clearly this is quite a wide range of topics, which no one person, or even
+small group of people are capable of maintaining. Instead, the SoC subsystem
+is comprised of many submaintainers, each taking care of individual platforms
+and driver subdirectories.
+In this regard, "platform" usually refers to a series of SoCs from a given
+vendor, for example, Nvidia's series of Tegra SoCs. Many submaintainers operate
+on a vendor level, responsible for multiple product lines. For several reasons,
+including acquisitions/different business units in a company, things vary
+significantly here. The various submaintainers are documented in the
+MAINTAINERS file.
+
+Most of these submaintainers have their own trees where they stage patches,
+sending pull requests to the main SoC tree. These trees are usually, but not
+always, listed in MAINTAINERS. The main SoC maintainers can be reached via the
+alias soc@kernel.org if there is no platform-specific maintainer, or if they
+are unresponsive.
+
+What the SoC tree is not, however, is a location for architecture-specific code
+changes. Each architecture has its own maintainers that are responsible for
+architectural details, CPU errata and the like.
+
+Information for (new) Submaintainers
+------------------------------------
+
+As new platforms spring up, they often bring with them new submaintainers,
+many of whom work for the silicon vendor, and may not be familiar with the
+process.
+
+Devicetree ABI Stability
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Perhaps one of the most important things to highlight is that dt-bindings
+document the ABI between the devicetree and the kernel.
+Please read Documentation/devicetree/bindings/ABI.rst.
+
+If changes are being made to a devicetree that are incompatible with old
+kernels, the devicetree patch should not be applied until the driver is, or an
+appropriate time later. Most importantly, any incompatible changes should be
+clearly pointed out in the patch description and pull request, along with the
+expected impact on existing users, such as bootloaders or other operating
+systems.
+
+Driver Branch Dependencies
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A common problem is synchronizing changes between device drivers and devicetree
+files. Even if a change is compatible in both directions, this may require
+coordinating how the changes get merged through different maintainer trees.
+
+Usually the branch that includes a driver change will also include the
+corresponding change to the devicetree binding description, to ensure they are
+in fact compatible. This means that the devicetree branch can end up causing
+warnings in the "make dtbs_check" step. If a devicetree change depends on
+missing additions to a header file in include/dt-bindings/, it will fail the
+"make dtbs" step and not get merged.
+
+There are multiple ways to deal with this:
+
+* Avoid defining custom macros in include/dt-bindings/ for hardware constants
+ that can be derived from a datasheet -- binding macros in header files should
+ only be used as a last resort if there is no natural way to define a binding
+
+* Use literal values in the devicetree file in place of macros even when a
+ header is required, and change them to the named representation in a
+ following release
+
+* Defer the devicetree changes to a release after the binding and driver have
+ already been merged
+
+* Change the bindings in a shared immutable branch that is used as the base for
+ both the driver change and the devicetree changes
+
+* Add duplicate defines in the devicetree file guarded by an #ifndef section,
+ removing them in a later release
+
+Devicetree Naming Convention
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The general naming scheme for devicetree files is as follows. The aspects of a
+platform that are set at the SoC level, like CPU cores, are contained in a file
+named $soc.dtsi, for example, jh7100.dtsi. Integration details, that will vary
+from board to board, are described in $soc-$board.dts. An example of this is
+jh7100-beaglev-starlight.dts. Often many boards are variations on a theme, and
+frequently there are intermediate files, such as jh7100-common.dtsi, which sit
+between the $soc.dtsi and $soc-$board.dts files, containing the descriptions of
+common hardware.
+
+Some platforms also have System on Modules, containing an SoC, which are then
+integrated into several different boards. For these platforms, $soc-$som.dtsi
+and $soc-$som-$board.dts are typical.
+
+Directories are usually named after the vendor of the SoC at the time of its
+inclusion, leading to some historical directory names in the tree.
+
+Validating Devicetree Files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``make dtbs_check`` can be used to validate that devicetree files are compliant
+with the dt-bindings that describe the ABI. Please read the section
+"Running checks" of Documentation/devicetree/bindings/writing-schema.rst for
+more information on the validation of devicetrees.
+
+For new platforms, or additions to existing ones, ``make dtbs_check`` should not
+add any new warnings. For RISC-V, as it has the advantage of being a newer
+architecture, ``make dtbs_check W=1`` is required to not add any new warnings.
+If in any doubt about a devicetree change, reach out to the devicetree
+maintainers.
+
+Branches and Pull Requests
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Just as the main SoC tree has several branches, it is expected that
+submaintainers will do the same. Driver, defconfig and devicetree changes should
+all be split into separate branches and appear in separate pull requests to the
+SoC maintainers. Each branch should be usable by itself and avoid
+regressions that originate from dependencies on other branches.
+
+Small sets of patches can also be sent as separate emails to soc@kernel.org,
+grouped into the same categories.
+
+If changes do not fit into the normal patterns, there can be additional
+top-level branches, e.g. for a treewide rework, or the addition of new SoC
+platforms including dts files and drivers.
+
+Branches with a lot of changes can benefit from getting split up into separate
+topics branches, even if they end up getting merged into the same branch of the
+SoC tree. An example here would be one branch for devicetree warning fixes, one
+for a rework and one for newly added boards.
+
+Another common way to split up changes is to send an early pull request with the
+majority of the changes at some point between rc1 and rc4, following up with one
+or more smaller pull requests towards the end of the cycle that can add late
+changes or address problems identified while testing the first set.
+
+While there is no cut-off time for late pull requests, it helps to only send
+small branches as time gets closer to the merge window.
+
+Pull requests for bugfixes for the current release can be sent at any time, but
+again having multiple smaller branches is better than trying to combine too many
+patches into one pull request.
+
+The subject line of a pull request should begin with "[GIT PULL]" and made using
+a signed tag, rather than a branch. This tag should contain a short description
+summarising the changes in the pull request. For more detail on sending pull
+requests, please see Documentation/maintainer/pull-requests.rst.
diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst
index 178c95f..08dd0f8 100644
--- a/Documentation/process/maintainer-tip.rst
+++ b/Documentation/process/maintainer-tip.rst
@@ -421,6 +421,9 @@
The release candidate -rc1 is the starting point for new patches to be
applied which are targeted for the next merge window.
+So called _urgent_ branches will be merged into mainline during the
+stabilization phase of each release.
+
Git
^^^
@@ -452,6 +455,8 @@
Some of these options are x86-specific and can be left out when testing
on other architectures.
+.. _maintainer-tip-coding-style:
+
Coding style notes
------------------
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 82e2983..5a69937 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -63,31 +63,28 @@
of the report are treated confidentially even after the embargo has been
lifted, in perpetuity.
-Coordination
-------------
+Coordination with other groups
+------------------------------
-Fixes for sensitive bugs, such as those that might lead to privilege
-escalations, may need to be coordinated with the private
-<linux-distros@vs.openwall.org> mailing list so that distribution vendors
-are well prepared to issue a fixed kernel upon public disclosure of the
-upstream fix. Distros will need some time to test the proposed patch and
-will generally request at least a few days of embargo, and vendor update
-publication prefers to happen Tuesday through Thursday. When appropriate,
-the security team can assist with this coordination, or the reporter can
-include linux-distros from the start. In this case, remember to prefix
-the email Subject line with "[vs]" as described in the linux-distros wiki:
-<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
+The kernel security team strongly recommends that reporters of potential
+security issues NEVER contact the "linux-distros" mailing list until
+AFTER discussing it with the kernel security team. Do not Cc: both
+lists at once. You may contact the linux-distros mailing list after a
+fix has been agreed on and you fully understand the requirements that
+doing so will impose on you and the kernel community.
+
+The different lists have different goals and the linux-distros rules do
+not contribute to actually fixing any potential security problems.
CVE assignment
--------------
-The security team does not normally assign CVEs, nor do we require them
-for reports or fixes, as this can needlessly complicate the process and
-may delay the bug handling. If a reporter wishes to have a CVE identifier
-assigned ahead of public disclosure, they will need to contact the private
-linux-distros list, described above. When such a CVE identifier is known
-before a patch is provided, it is desirable to mention it in the commit
-message if the reporter agrees.
+The security team does not assign CVEs, nor do we require them for
+reports or fixes, as this can needlessly complicate the process and may
+delay the bug handling. If a reporter wishes to have a CVE identifier
+assigned, they should find one by themselves, for example by contacting
+MITRE directly. However under no circumstances will a patch inclusion
+be delayed to wait for a CVE identifier to arrive.
Non-disclosure agreements
-------------------------
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 486875f..efac910 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -331,6 +331,31 @@
See Documentation/process/email-clients.rst for recommendations on email
clients and mailing list etiquette.
+.. _interleaved_replies:
+
+Use trimmed interleaved replies in email discussions
+----------------------------------------------------
+Top-posting is strongly discouraged in Linux kernel development
+discussions. Interleaved (or "inline") replies make conversations much
+easier to follow. For more details see:
+https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
+
+As is frequently quoted on the mailing list::
+
+ A: http://en.wikipedia.org/wiki/Top_post
+ Q: Were do I find info about this thing called top-posting?
+ A: Because it messes up the order in which people normally read text.
+ Q: Why is top-posting such a bad thing?
+ A: Top-posting.
+ Q: What is the most annoying thing in e-mail?
+
+Similarly, please trim all unneeded quotations that aren't relevant
+to your reply. This makes responses easier to find, and saves time and
+space. For more details see: http://daringfireball.net/2007/07/on_top ::
+
+ A: No.
+ Q: Should I include quotations after my reply?
+
.. _resend_reminders:
Don't get discouraged - or impatient
diff --git a/Documentation/riscv/acpi.rst b/Documentation/riscv/acpi.rst
new file mode 100644
index 0000000..9870a28
--- /dev/null
+++ b/Documentation/riscv/acpi.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============
+ACPI on RISC-V
+==============
+
+The ISA string parsing rules for ACPI are defined by `Version ASCIIDOC
+Conversion, 12/2022 of the RISC-V specifications, as defined by tag
+"riscv-isa-release-1239329-2023-05-23" (commit 1239329
+) <https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-isa-release-1239329-2023-05-23>`_
diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index 9f0dd62..933c715 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -49,7 +49,7 @@
privileged ISA, with the following known exceptions (more exceptions may be
added, but only if it can be demonstrated that the user ABI is not broken):
- * The :fence.i: instruction cannot be directly executed by userspace
+ * The ``fence.i`` instruction cannot be directly executed by userspace
programs (it may still be executed in userspace via a
kernel-controlled mechanism such as the vDSO).
@@ -64,6 +64,19 @@
* :c:macro:`RISCV_HWPROBE_IMA_C`: The C extension is supported, as defined
by version 2.2 of the RISC-V ISA manual.
+ * :c:macro:`RISCV_HWPROBE_IMA_V`: The V extension is supported, as defined by
+ version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBA`: The Zba address generation extension is
+ supported, as defined in version 1.0 of the Bit-Manipulation ISA
+ extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, as defined
+ in version 1.0 of the Bit-Manipulation ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
+ in version 1.0 of the Bit-Manipulation ISA extensions.
+
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
information about the selected set of processors.
diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst
index 175a91d..81cf6e6 100644
--- a/Documentation/riscv/index.rst
+++ b/Documentation/riscv/index.rst
@@ -5,11 +5,13 @@
.. toctree::
:maxdepth: 1
+ acpi
boot-image-header
vm-layout
hwprobe
patch-acceptance
uabi
+ vector
features
diff --git a/Documentation/riscv/vector.rst b/Documentation/riscv/vector.rst
new file mode 100644
index 0000000..165b7ed
--- /dev/null
+++ b/Documentation/riscv/vector.rst
@@ -0,0 +1,140 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================
+Vector Extension Support for RISC-V Linux
+=========================================
+
+This document briefly outlines the interface provided to userspace by Linux in
+order to support the use of the RISC-V Vector Extension.
+
+1. prctl() Interface
+---------------------
+
+Two new prctl() calls are added to allow programs to manage the enablement
+status for the use of Vector in userspace. The intended usage guideline for
+these interfaces is to give init systems a way to modify the availability of V
+for processes running under its domain. Calling thess interfaces is not
+recommended in libraries routines because libraries should not override policies
+configured from the parant process. Also, users must noted that these interfaces
+are not portable to non-Linux, nor non-RISC-V environments, so it is discourage
+to use in a portable code. To get the availability of V in an ELF program,
+please read :c:macro:`COMPAT_HWCAP_ISA_V` bit of :c:macro:`ELF_HWCAP` in the
+auxiliary vector.
+
+* prctl(PR_RISCV_V_SET_CONTROL, unsigned long arg)
+
+ Sets the Vector enablement status of the calling thread, where the control
+ argument consists of two 2-bit enablement statuses and a bit for inheritance
+ mode. Other threads of the calling process are unaffected.
+
+ Enablement status is a tri-state value each occupying 2-bit of space in
+ the control argument:
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_DEFAULT`: Use the system-wide default
+ enablement status on execve(). The system-wide default setting can be
+ controlled via sysctl interface (see sysctl section below).
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_ON`: Allow Vector to be run for the
+ thread.
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_OFF`: Disallow Vector. Executing Vector
+ instructions under such condition will trap and casuse the termination of the thread.
+
+ arg: The control argument is a 5-bit value consisting of 3 parts, and
+ accessed by 3 masks respectively.
+
+ The 3 masks, PR_RISCV_V_VSTATE_CTRL_CUR_MASK,
+ PR_RISCV_V_VSTATE_CTRL_NEXT_MASK, and PR_RISCV_V_VSTATE_CTRL_INHERIT
+ represents bit[1:0], bit[3:2], and bit[4]. bit[1:0] accounts for the
+ enablement status of current thread, and the setting at bit[3:2] takes place
+ at next execve(). bit[4] defines the inheritance mode of the setting in
+ bit[3:2].
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_CUR_MASK`: bit[1:0]: Account for the
+ Vector enablement status for the calling thread. The calling thread is
+ not able to turn off Vector once it has been enabled. The prctl() call
+ fails with EPERM if the value in this mask is PR_RISCV_V_VSTATE_CTRL_OFF
+ but the current enablement status is not off. Setting
+ PR_RISCV_V_VSTATE_CTRL_DEFAULT here takes no effect but to set back
+ the original enablement status.
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_NEXT_MASK`: bit[3:2]: Account for the
+ Vector enablement setting for the calling thread at the next execve()
+ system call. If PR_RISCV_V_VSTATE_CTRL_DEFAULT is used in this mask,
+ then the enablement status will be decided by the system-wide
+ enablement status when execve() happen.
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_INHERIT`: bit[4]: the inheritance
+ mode for the setting at PR_RISCV_V_VSTATE_CTRL_NEXT_MASK. If the bit
+ is set then the following execve() will not clear the setting in both
+ PR_RISCV_V_VSTATE_CTRL_NEXT_MASK and PR_RISCV_V_VSTATE_CTRL_INHERIT.
+ This setting persists across changes in the system-wide default value.
+
+ Return value:
+ * 0 on success;
+ * EINVAL: Vector not supported, invalid enablement status for current or
+ next mask;
+ * EPERM: Turning off Vector in PR_RISCV_V_VSTATE_CTRL_CUR_MASK if Vector
+ was enabled for the calling thread.
+
+ On success:
+ * A valid setting for PR_RISCV_V_VSTATE_CTRL_CUR_MASK takes place
+ immediately. The enablement status specified in
+ PR_RISCV_V_VSTATE_CTRL_NEXT_MASK happens at the next execve() call, or
+ all following execve() calls if PR_RISCV_V_VSTATE_CTRL_INHERIT bit is
+ set.
+ * Every successful call overwrites a previous setting for the calling
+ thread.
+
+* prctl(PR_RISCV_V_GET_CONTROL)
+
+ Gets the same Vector enablement status for the calling thread. Setting for
+ next execve() call and the inheritance bit are all OR-ed together.
+
+ Note that ELF programs are able to get the availability of V for itself by
+ reading :c:macro:`COMPAT_HWCAP_ISA_V` bit of :c:macro:`ELF_HWCAP` in the
+ auxiliary vector.
+
+ Return value:
+ * a nonnegative value on success;
+ * EINVAL: Vector not supported.
+
+2. System runtime configuration (sysctl)
+-----------------------------------------
+
+To mitigate the ABI impact of expansion of the signal stack, a
+policy mechanism is provided to the administrators, distro maintainers, and
+developers to control the default Vector enablement status for userspace
+processes in form of sysctl knob:
+
+* /proc/sys/abi/riscv_v_default_allow
+
+ Writing the text representation of 0 or 1 to this file sets the default
+ system enablement status for new starting userspace programs. Valid values
+ are:
+
+ * 0: Do not allow Vector code to be executed as the default for new processes.
+ * 1: Allow Vector code to be executed as the default for new processes.
+
+ Reading this file returns the current system default enablement status.
+
+ At every execve() call, a new enablement status of the new process is set to
+ the system default, unless:
+
+ * PR_RISCV_V_VSTATE_CTRL_INHERIT is set for the calling process, and the
+ setting in PR_RISCV_V_VSTATE_CTRL_NEXT_MASK is not
+ PR_RISCV_V_VSTATE_CTRL_DEFAULT. Or,
+
+ * The setting in PR_RISCV_V_VSTATE_CTRL_NEXT_MASK is not
+ PR_RISCV_V_VSTATE_CTRL_DEFAULT.
+
+ Modifying the system default enablement status does not affect the enablement
+ status of any existing process of thread that do not make an execve() call.
+
+3. Vector Register State Across System Calls
+---------------------------------------------
+
+As indicated by version 1.0 of the V extension [1], vector registers are
+clobbered by system calls.
+
+1: https://github.com/riscv/riscv-v-spec/blob/master/calling-convention.adoc
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index 13b7744..a893151 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -38,9 +38,9 @@
rustup override set $(scripts/min-tool-version.sh rustc)
-Otherwise, fetch a standalone installer or install ``rustup`` from:
+Otherwise, fetch a standalone installer from:
- https://www.rust-lang.org
+ https://forge.rust-lang.org/infra/other-installation-methods.html#standalone
Rust standard library source
diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
index 9d9be52..9fe4846 100644
--- a/Documentation/scheduler/sched-deadline.rst
+++ b/Documentation/scheduler/sched-deadline.rst
@@ -203,12 +203,15 @@
- Total bandwidth (this_bw): this is the sum of all tasks "belonging" to the
runqueue, including the tasks in Inactive state.
+ - Maximum usable bandwidth (max_bw): This is the maximum bandwidth usable by
+ deadline tasks and is currently set to the RT capacity.
+
The algorithm reclaims the bandwidth of the tasks in Inactive state.
It does so by decrementing the runtime of the executing task Ti at a pace equal
to
- dq = -max{ Ui / Umax, (1 - Uinact - Uextra) } dt
+ dq = -(max{ Ui, (Umax - Uinact - Uextra) } / Umax) dt
where:
diff --git a/Documentation/scsi/arcmsr_spec.rst b/Documentation/scsi/arcmsr_spec.rst
index 83dd53b..792c731 100644
--- a/Documentation/scsi/arcmsr_spec.rst
+++ b/Documentation/scsi/arcmsr_spec.rst
@@ -1,3 +1,4 @@
+===================
ARECA FIRMWARE SPEC
===================
diff --git a/Documentation/scsi/dc395x.rst b/Documentation/scsi/dc395x.rst
index d779e78..d92947c 100644
--- a/Documentation/scsi/dc395x.rst
+++ b/Documentation/scsi/dc395x.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-======================================
-README file for the dc395x SCSI driver
-======================================
+==================
+dc395x SCSI driver
+==================
Status
------
@@ -11,13 +11,10 @@
great degree and caution should be exercised if you want to attempt
to use this driver with hard disks.
-This is a 2.5 only driver. For a 2.4 driver please see the original
-driver (which this driver started from) at
-http://www.garloff.de/kurt/linux/dc395/
-
-Problems, questions and patches should be submitted to the mailing
-list. Details on the list, including archives, are available at
-http://lists.twibble.org/mailman/listinfo/dc395x/
+This driver is evolved from `the original 2.4 driver
+<https://web.archive.org/web/20140129181343/http://www.garloff.de/kurt/linux/dc395/>`_.
+Problems, questions and patches should be submitted to the `Linux SCSI
+mailing list <linux-scsi@vger.kernel.org>`_.
Parameters
----------
diff --git a/Documentation/scsi/g_NCR5380.rst b/Documentation/scsi/g_NCR5380.rst
index a282059..b250c24 100644
--- a/Documentation/scsi/g_NCR5380.rst
+++ b/Documentation/scsi/g_NCR5380.rst
@@ -1,9 +1,9 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
-==========================================
-README file for the Linux g_NCR5380 driver
-==========================================
+================
+g_NCR5380 driver
+================
Copyright |copy| 1993 Drew Eckhard
diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst
index 919f3ed..f15a0f3 100644
--- a/Documentation/scsi/index.rst
+++ b/Documentation/scsi/index.rst
@@ -7,6 +7,38 @@
.. toctree::
:maxdepth: 1
+Introduction
+============
+
+.. toctree::
+ :maxdepth: 1
+
+ scsi
+
+SCSI driver APIs
+================
+
+.. toctree::
+ :maxdepth: 1
+
+ scsi_mid_low_api
+ scsi_eh
+
+SCSI driver parameters
+======================
+
+.. toctree::
+ :maxdepth: 1
+
+ scsi-parameters
+ link_power_management_policy
+
+SCSI host adapter drivers
+=========================
+
+.. toctree::
+ :maxdepth: 1
+
53c700
aacraid
advansys
@@ -25,7 +57,6 @@
hpsa
hptiop
libsas
- link_power_management_policy
lpfc
megaraid
ncr53c8xx
@@ -33,12 +64,8 @@
ppa
qlogicfas
scsi-changer
- scsi_eh
scsi_fc_transport
scsi-generic
- scsi_mid_low_api
- scsi-parameters
- scsi
sd-parameters
smartpqi
st
diff --git a/Documentation/scsi/megaraid.rst b/Documentation/scsi/megaraid.rst
index 22b75a8..10a6b05 100644
--- a/Documentation/scsi/megaraid.rst
+++ b/Documentation/scsi/megaraid.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-==========================
-Notes on Management Module
-==========================
+=================================
+Megaraid Common Management Module
+=================================
Overview
--------
diff --git a/Documentation/scsi/ncr53c8xx.rst b/Documentation/scsi/ncr53c8xx.rst
index 1c79e08..fd8d26d 100644
--- a/Documentation/scsi/ncr53c8xx.rst
+++ b/Documentation/scsi/ncr53c8xx.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-=================================================
-The Linux NCR53C8XX/SYM53C8XX drivers README file
-=================================================
+===========================
+NCR53C8XX/SYM53C8XX drivers
+===========================
Written by Gerard Roudier <groudier@free.fr>
diff --git a/Documentation/scsi/scsi-changer.rst b/Documentation/scsi/scsi-changer.rst
index ab60e7e..5d828c7 100644
--- a/Documentation/scsi/scsi-changer.rst
+++ b/Documentation/scsi/scsi-changer.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-========================================
-README for the SCSI media changer driver
-========================================
+=========================
+SCSI media changer driver
+=========================
This is a driver for SCSI Medium Changer devices, which are listed
with "Type: Medium Changer" in /proc/scsi/scsi.
diff --git a/Documentation/scsi/scsi-generic.rst b/Documentation/scsi/scsi-generic.rst
index 258505e..b82ffe4 100644
--- a/Documentation/scsi/scsi-generic.rst
+++ b/Documentation/scsi/scsi-generic.rst
@@ -1,15 +1,15 @@
.. SPDX-License-Identifier: GPL-2.0
-=======================================
-Notes on Linux SCSI Generic (sg) driver
-=======================================
+========================
+SCSI Generic (sg) driver
+========================
20020126
Introduction
============
The SCSI Generic driver (sg) is one of the four "high level" SCSI device
-drivers along with sd, st and sr (disk, tape and CDROM respectively). Sg
+drivers along with sd, st and sr (disk, tape and CD-ROM respectively). Sg
is more generalized (but lower level) than its siblings and tends to be
used on SCSI devices that don't fit into the already serviced categories.
Thus sg is used for scanners, CD writers and reading audio CDs digitally
@@ -22,7 +22,7 @@
Major versions of the sg driver
===============================
-There are three major versions of sg found in the linux kernel (lk):
+There are three major versions of sg found in the Linux kernel (lk):
- sg version 1 (original) from 1992 to early 1999 (lk 2.2.5) .
It is based in the sg_header interface structure.
- sg version 2 from lk 2.2.6 in the 2.2 series. It is based on
@@ -33,34 +33,24 @@
Sg driver documentation
=======================
-The most recent documentation of the sg driver is kept at the Linux
-Documentation Project's (LDP) site:
+The most recent documentation of the sg driver is kept at
-- http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO
+- https://sg.danny.cz/sg/
This describes the sg version 3 driver found in the lk 2.4 series.
-The LDP renders documents in single and multiple page HTML, postscript
-and pdf. This document can also be found at:
+Documentation (large version) for the version 2 sg driver found in the
+lk 2.2 series can be found at
-- http://sg.danny.cz/sg/p/sg_v3_ho.html
-
-Documentation for the version 2 sg driver found in the lk 2.2 series can
-be found at http://sg.danny.cz/sg/. A larger version
-is at: http://sg.danny.cz/sg/p/scsi-generic_long.txt.
+- https://sg.danny.cz/sg/p/scsi-generic_long.txt.
The original documentation for the sg driver (prior to lk 2.2.6) can be
-found at http://www.torque.net/sg/p/original/SCSI-Programming-HOWTO.txt
-and in the LDP archives.
+found in the LDP archives at
-A changelog with brief notes can be found in the
-/usr/src/linux/include/scsi/sg.h file. Note that the glibc maintainers copy
-and edit this file (removing its changelog for example) before placing it
-in /usr/include/scsi/sg.h . Driver debugging information and other notes
-can be found at the top of the /usr/src/linux/drivers/scsi/sg.c file.
+- https://tldp.org/HOWTO/archived/SCSI-Programming-HOWTO/index.html
A more general description of the Linux SCSI subsystem of which sg is a
-part can be found at http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO .
+part can be found at https://www.tldp.org/HOWTO/SCSI-2.4-HOWTO .
Example code and utilities
@@ -73,8 +63,8 @@
and earlier
========= ==========================================================
-Both packages will work in the lk 2.4 series however sg3_utils offers more
-capabilities. They can be found at: http://sg.danny.cz/sg/sg3_utils.html and
+Both packages will work in the lk 2.4 series. However, sg3_utils offers more
+capabilities. They can be found at: https://sg.danny.cz/sg/sg3_utils.html and
freecode.com
Another approach is to look at the applications that use the sg driver.
@@ -83,7 +73,7 @@
Mapping of Linux kernel versions to sg driver versions
======================================================
-Here is a list of linux kernels in the 2.4 series that had new version
+Here is a list of Linux kernels in the 2.4 series that had the new version
of the sg driver:
- lk 2.4.0 : sg version 3.1.17
@@ -92,10 +82,10 @@
- lk 2.4.17 : sg version 3.1.22
.. [#] There were 3 changes to sg version 3.1.20 by third parties in the
- next six linux kernel versions.
+ next six Linux kernel versions.
-For reference here is a list of linux kernels in the 2.2 series that had
-new version of the sg driver:
+For reference here is a list of Linux kernels in the 2.2 series that had
+the new version of the sg driver:
- lk 2.2.0 : original sg version [with no version number]
- lk 2.2.6 : sg version 2.1.31
@@ -106,9 +96,8 @@
- lk 2.2.17 : sg version 2.1.39
- lk 2.2.20 : sg version 2.1.40
-The lk 2.5 development series has recently commenced and it currently
-contains sg version 3.5.23 which is functionally equivalent to sg
-version 3.1.22 found in lk 2.4.17.
+The lk 2.5 development series currently contains sg version 3.5.23
+which is functionally equivalent to sg version 3.1.22 found in lk 2.4.17.
Douglas Gilbert
diff --git a/Documentation/scsi/scsi.rst b/Documentation/scsi/scsi.rst
index 276918e..8556846 100644
--- a/Documentation/scsi/scsi.rst
+++ b/Documentation/scsi/scsi.rst
@@ -6,30 +6,28 @@
The Linux Documentation Project (LDP) maintains a document describing
the SCSI subsystem in the Linux kernel (lk) 2.4 series. See:
-http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single
+https://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single
and multiple page HTML renderings as well as postscript and pdf.
-It can also be found at:
-http://web.archive.org/web/%2E/http://www.torque.net/scsi/SCSI-2.4-HOWTO
Notes on using modules in the SCSI subsystem
============================================
-The scsi support in the linux kernel can be modularized in a number of
+The SCSI support in the Linux kernel can be modularized in a number of
different ways depending upon the needs of the end user. To understand
your options, we should first define a few terms.
-The scsi-core (also known as the "mid level") contains the core of scsi
-support. Without it you can do nothing with any of the other scsi drivers.
-The scsi core support can be a module (scsi_mod.o), or it can be built into
-the kernel. If the core is a module, it must be the first scsi module
+The scsi-core (also known as the "mid level") contains the core of SCSI
+support. Without it you can do nothing with any of the other SCSI drivers.
+The SCSI core support can be a module (scsi_mod.o), or it can be built into
+the kernel. If the core is a module, it must be the first SCSI module
loaded, and if you unload the modules, it will have to be the last one
-unloaded. In practice the modprobe and rmmod commands (and "autoclean")
+unloaded. In practice the modprobe and rmmod commands
will enforce the correct ordering of loading and unloading modules in
the SCSI subsystem.
The individual upper and lower level drivers can be loaded in any order
-once the scsi core is present in the kernel (either compiled in or loaded
-as a module). The disk driver (sd_mod.o), cdrom driver (sr_mod.o),
-tape driver [1]_ (st.o) and scsi generics driver (sg.o) represent the upper
+once the SCSI core is present in the kernel (either compiled in or loaded
+as a module). The disk driver (sd_mod.o), CD-ROM driver (sr_mod.o),
+tape driver [1]_ (st.o) and SCSI generics driver (sg.o) represent the upper
level drivers to support the various assorted devices which can be
controlled. You can for example load the tape driver to use the tape drive,
and then unload it once you have no further need for the driver (and release
@@ -44,4 +42,3 @@
.. [1] There is a variant of the st driver for controlling OnStream tape
devices. Its module name is osst.o .
-
diff --git a/Documentation/scsi/scsi_fc_transport.rst b/Documentation/scsi/scsi_fc_transport.rst
index 176c186..e3ddcfb 100644
--- a/Documentation/scsi/scsi_fc_transport.rst
+++ b/Documentation/scsi/scsi_fc_transport.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-================
-SCSI FC Tansport
-================
+=================
+SCSI FC Transport
+=================
Date: 11/18/2008
@@ -556,5 +556,5 @@
James Smart
-james.smart@emulex.com
+james.smart@broadcom.com
diff --git a/Documentation/scsi/sym53c8xx_2.rst b/Documentation/scsi/sym53c8xx_2.rst
index 004f1a7..4eb0479 100644
--- a/Documentation/scsi/sym53c8xx_2.rst
+++ b/Documentation/scsi/sym53c8xx_2.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-=========================================
-The Linux SYM-2 driver documentation file
-=========================================
+============
+SYM-2 driver
+============
Written by Gerard Roudier <groudier@free.fr>
diff --git a/Documentation/sound/cards/audigy-mixer.rst b/Documentation/sound/cards/audigy-mixer.rst
index aa17645..ea66b50 100644
--- a/Documentation/sound/cards/audigy-mixer.rst
+++ b/Documentation/sound/cards/audigy-mixer.rst
@@ -227,7 +227,7 @@
name='EMU10K1 PCM Volume',index 0-31
------------------------------------
-Channel volume attenuation in range 0-0xffff. The maximum value (no
+Channel volume attenuation in range 0-0x1fffd. The middle value (no
attenuation) is default. The channel mapping for three values is
as follows:
@@ -240,30 +240,30 @@
This control specifies the destination - FX-bus accumulators. There are 24
values in this mapping:
-* 0 - mono, A destination (FX-bus 0-63), default 0
-* 1 - mono, B destination (FX-bus 0-63), default 1
-* 2 - mono, C destination (FX-bus 0-63), default 2
-* 3 - mono, D destination (FX-bus 0-63), default 3
-* 4 - mono, E destination (FX-bus 0-63), default 0
-* 5 - mono, F destination (FX-bus 0-63), default 0
-* 6 - mono, G destination (FX-bus 0-63), default 0
-* 7 - mono, H destination (FX-bus 0-63), default 0
-* 8 - left, A destination (FX-bus 0-63), default 0
-* 9 - left, B destination (FX-bus 0-63), default 1
+* 0 - mono, A destination (FX-bus 0-63), default 0
+* 1 - mono, B destination (FX-bus 0-63), default 1
+* 2 - mono, C destination (FX-bus 0-63), default 2
+* 3 - mono, D destination (FX-bus 0-63), default 3
+* 4 - mono, E destination (FX-bus 0-63), default 4
+* 5 - mono, F destination (FX-bus 0-63), default 5
+* 6 - mono, G destination (FX-bus 0-63), default 6
+* 7 - mono, H destination (FX-bus 0-63), default 7
+* 8 - left, A destination (FX-bus 0-63), default 0
+* 9 - left, B destination (FX-bus 0-63), default 1
* 10 - left, C destination (FX-bus 0-63), default 2
* 11 - left, D destination (FX-bus 0-63), default 3
-* 12 - left, E destination (FX-bus 0-63), default 0
-* 13 - left, F destination (FX-bus 0-63), default 0
-* 14 - left, G destination (FX-bus 0-63), default 0
-* 15 - left, H destination (FX-bus 0-63), default 0
+* 12 - left, E destination (FX-bus 0-63), default 4
+* 13 - left, F destination (FX-bus 0-63), default 5
+* 14 - left, G destination (FX-bus 0-63), default 6
+* 15 - left, H destination (FX-bus 0-63), default 7
* 16 - right, A destination (FX-bus 0-63), default 0
* 17 - right, B destination (FX-bus 0-63), default 1
* 18 - right, C destination (FX-bus 0-63), default 2
* 19 - right, D destination (FX-bus 0-63), default 3
-* 20 - right, E destination (FX-bus 0-63), default 0
-* 21 - right, F destination (FX-bus 0-63), default 0
-* 22 - right, G destination (FX-bus 0-63), default 0
-* 23 - right, H destination (FX-bus 0-63), default 0
+* 20 - right, E destination (FX-bus 0-63), default 4
+* 21 - right, F destination (FX-bus 0-63), default 5
+* 22 - right, G destination (FX-bus 0-63), default 6
+* 23 - right, H destination (FX-bus 0-63), default 7
Don't forget that it's illegal to assign a channel to the same FX-bus accumulator
more than once (it means 0=0 && 1=0 is an invalid combination).
diff --git a/Documentation/sound/cards/index.rst b/Documentation/sound/cards/index.rst
index c016f8c..49c1f2f 100644
--- a/Documentation/sound/cards/index.rst
+++ b/Documentation/sound/cards/index.rst
@@ -17,3 +17,4 @@
hdspm
serial-u16550
img-spdif-in
+ pcmtest
diff --git a/Documentation/sound/cards/pcmtest.rst b/Documentation/sound/cards/pcmtest.rst
new file mode 100644
index 0000000..e163522
--- /dev/null
+++ b/Documentation/sound/cards/pcmtest.rst
@@ -0,0 +1,120 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+The Virtual PCM Test Driver
+===========================
+
+The Virtual PCM Test Driver emulates a generic PCM device, and can be used for
+testing/fuzzing of the userspace ALSA applications, as well as for testing/fuzzing of
+the PCM middle layer. Additionally, it can be used for simulating hard to reproduce
+problems with PCM devices.
+
+What can this driver do?
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+At this moment the driver can do the following things:
+ * Simulate both capture and playback processes
+ * Generate random or pattern-based capturing data
+ * Inject delays into the playback and capturing processes
+ * Inject errors during the PCM callbacks
+
+It supports up to 8 substreams and 4 channels. Also it supports both interleaved and
+non-interleaved access modes.
+
+Also, this driver can check the playback stream for containing the predefined pattern,
+which is used in the corresponding selftest (alsa/pcmtest-test.sh) to check the PCM middle
+layer data transferring functionality. Additionally, this driver redefines the default
+RESET ioctl, and the selftest covers this PCM API functionality as well.
+
+Configuration
+-------------
+
+The driver has several parameters besides the common ALSA module parameters:
+
+ * fill_mode (bool) - Buffer fill mode (see below)
+ * inject_delay (int)
+ * inject_hwpars_err (bool)
+ * inject_prepare_err (bool)
+ * inject_trigger_err (bool)
+
+
+Capture Data Generation
+-----------------------
+
+The driver has two modes of data generation: the first (0 in the fill_mode parameter)
+means random data generation, the second (1 in the fill_mode) - pattern-based
+data generation. Let's look at the second mode.
+
+First of all, you may want to specify the pattern for data generation. You can do it
+by writing the pattern to the debugfs file. There are pattern buffer debugfs entries
+for each channel, as well as entries which contain the pattern buffer length.
+
+ * /sys/kernel/debug/pcmtest/fill_pattern[0-3]
+ * /sys/kernel/debug/pcmtest/fill_pattern[0-3]_len
+
+To set the pattern for the channel 0 you can execute the following command:
+
+.. code-block:: bash
+
+ echo -n mycoolpattern > /sys/kernel/debug/pcmtest/fill_pattern0
+
+Then, after every capture action performed on the 'pcmtest' device the buffer for the
+channel 0 will contain 'mycoolpatternmycoolpatternmycoolpatternmy...'.
+
+The pattern itself can be up to 4096 bytes long.
+
+Delay injection
+---------------
+
+The driver has 'inject_delay' parameter, which has very self-descriptive name and
+can be used for time delay/speedup simulations. The parameter has integer type, and
+it means the delay added between module's internal timer ticks.
+
+If the 'inject_delay' value is positive, the buffer will be filled slower, if it is
+negative - faster. You can try it yourself by starting a recording in any
+audiorecording application (like Audacity) and selecting the 'pcmtest' device as a
+source.
+
+This parameter can be also used for generating a huge amount of sound data in a very
+short period of time (with the negative 'inject_delay' value).
+
+Errors injection
+----------------
+
+This module can be used for injecting errors into the PCM communication process. This
+action can help you to figure out how the userspace ALSA program behaves under unusual
+circumstances.
+
+For example, you can make all 'hw_params' PCM callback calls return EBUSY error by
+writing '1' to the 'inject_hwpars_err' module parameter:
+
+.. code-block:: bash
+
+ echo 1 > /sys/module/snd_pcmtest/parameters/inject_hwpars_err
+
+Errors can be injected into the following PCM callbacks:
+
+ * hw_params (EBUSY)
+ * prepare (EINVAL)
+ * trigger (EINVAL)
+
+Playback test
+-------------
+
+This driver can be also used for the playback functionality testing - every time you
+write the playback data to the 'pcmtest' PCM device and close it, the driver checks the
+buffer for containing the looped pattern (which is specified in the fill_pattern
+debugfs file for each channel). If the playback buffer content represents the looped
+pattern, 'pc_test' debugfs entry is set into '1'. Otherwise, the driver sets it to '0'.
+
+ioctl redefinition test
+-----------------------
+
+The driver redefines the 'reset' ioctl, which is default for all PCM devices. To test
+this functionality, we can trigger the reset ioctl and check the 'ioctl_test' debugfs
+entry:
+
+.. code-block:: bash
+
+ cat /sys/kernel/debug/pcmtest/ioctl_test
+
+If the ioctl is triggered successfully, this file will contain '1', and '0' otherwise.
diff --git a/Documentation/sound/cards/sb-live-mixer.rst b/Documentation/sound/cards/sb-live-mixer.rst
index 8198866..4dd9bfe 100644
--- a/Documentation/sound/cards/sb-live-mixer.rst
+++ b/Documentation/sound/cards/sb-live-mixer.rst
@@ -258,7 +258,7 @@
``name='EMU10K1 PCM Volume',index 0-31``
----------------------------------------
-Channel volume attenuation in range 0-0xffff. The maximum value (no
+Channel volume attenuation in range 0-0x1fffd. The middle value (no
attenuation) is default. The channel mapping for three values is
as follows:
diff --git a/Documentation/sound/designs/compress-offload.rst b/Documentation/sound/designs/compress-offload.rst
index 935f325..655624f 100644
--- a/Documentation/sound/designs/compress-offload.rst
+++ b/Documentation/sound/designs/compress-offload.rst
@@ -268,11 +268,12 @@
| |
| V
| +----------+
- | | |
- | |NEXT_TRACK|
- | | |
- | +----------+
- | |
+ | compr_set_params() | |
+ | +-----------|NEXT_TRACK|
+ | | | |
+ | | +--+-------+
+ | | | |
+ | +--------------+ |
| |
| | compr_partial_drain()
| |
diff --git a/Documentation/sound/designs/index.rst b/Documentation/sound/designs/index.rst
index 1eb08e7..b79db9a 100644
--- a/Documentation/sound/designs/index.rst
+++ b/Documentation/sound/designs/index.rst
@@ -15,3 +15,4 @@
oss-emulation
seq-oss
jack-injection
+ midi-2.0
diff --git a/Documentation/sound/designs/midi-2.0.rst b/Documentation/sound/designs/midi-2.0.rst
new file mode 100644
index 0000000..27d0d3d
--- /dev/null
+++ b/Documentation/sound/designs/midi-2.0.rst
@@ -0,0 +1,378 @@
+=================
+MIDI 2.0 on Linux
+=================
+
+General
+=======
+
+MIDI 2.0 is an extended protocol for providing higher resolutions and
+more fine controls over the legacy MIDI 1.0. The fundamental changes
+introduced for supporting MIDI 2.0 are:
+
+- Support of Universal MIDI Packet (UMP)
+- Support of MIDI 2.0 protocol messages
+- Transparent conversions between UMP and legacy MIDI 1.0 byte stream
+- MIDI-CI for property and profile configurations
+
+UMP is a new container format to hold all MIDI protocol 1.0 and MIDI
+2.0 protocol messages. Unlike the former byte stream, it's 32bit
+aligned, and each message can be put in a single packet. UMP can send
+the events up to 16 "UMP Groups", where each UMP Group contain up to
+16 MIDI channels.
+
+MIDI 2.0 protocol is an extended protocol to achieve the higher
+resolution and more controls over the old MIDI 1.0 protocol.
+
+MIDI-CI is a high-level protocol that can talk with the MIDI device
+for the flexible profiles and configurations. It's represented in the
+form of special SysEx.
+
+For Linux implementations, the kernel supports the UMP transport and
+the encoding/decoding of MIDI protocols on UMP, while MIDI-CI is
+supported in user-space over the standard SysEx.
+
+As of this writing, only USB MIDI device supports the UMP and Linux
+2.0 natively. The UMP support itself is pretty generic, hence it
+could be used by other transport layers, although it could be
+implemented differently (e.g. as a ALSA sequencer client), too.
+
+The access to UMP devices are provided in two ways: the access via
+rawmidi device and the access via ALSA sequencer API.
+
+ALSA sequencer API was extended to allow the payload of UMP packets.
+It's allowed to connect freely between MIDI 1.0 and MIDI 2.0 sequencer
+clients, and the events are converted transparently.
+
+
+Kernel Configuration
+====================
+
+The following new configs are added for supporting MIDI 2.0:
+`CONFIG_SND_UMP`, `CONFIG_SND_UMP_LEGACY_RAWMIDI`,
+`CONFIG_SND_SEQ_UMP`, `CONFIG_SND_SEQ_UMP_CLIENT`, and
+`CONFIG_SND_USB_AUDIO_MIDI_V2`. The first visible one is
+`CONFIG_SND_USB_AUDIO_MIDI_V2`, and when you choose it (to set `=y`),
+the core support for UMP (`CONFIG_SND_UMP`) and the sequencer binding
+(`CONFIG_SND_SEQ_UMP_CLIENT`) will be automatically selected.
+
+Additionally, `CONFIG_SND_UMP_LEGACY_RAWMIDI=y` will enable the
+support for the legacy raw MIDI device for UMP Endpoints.
+
+
+Rawmidi Device with USB MIDI 2.0
+================================
+
+When a device supports MIDI 2.0, the USB-audio driver probes and uses
+the MIDI 2.0 interface (that is found always at the altset 1) as
+default instead of the MIDI 1.0 interface (at altset 0). You can
+switch back to the binding with the old MIDI 1.0 interface by passing
+`midi2_enable=0` option to snd-usb-audio driver module, too.
+
+The USB audio driver tries to query the UMP Endpoint and UMP Function
+Block information that are provided since UMP v1.1, and builds up the
+topology based on those information. When the device is older and
+doesn't respond to the new UMP inquiries, the driver falls back and
+builds the topology based on Group Terminal Block (GTB) information
+from the USB descriptor. Some device might be screwed up by the
+unexpected UMP command; in such a case, pass `midi2_probe=0` option to
+snd-usb-audio driver for skipping the UMP v1.1 inquiries.
+
+When the MIDI 2.0 device is probed, the kernel creates a rawmidi
+device for each UMP Endpoint of the device. Its device name is
+`/dev/snd/umpC*D*` and different from the standard rawmidi device name
+`/dev/snd/midiC*D*` for MIDI 1.0, in order to avoid confusing the
+legacy applications accessing mistakenly to UMP devices.
+
+You can read and write UMP packet data directly from/to this UMP
+rawmidi device. For example, reading via `hexdump` like below will
+show the incoming UMP packets of the card 0 device 0 in the hex
+format::
+
+ % hexdump -C /dev/snd/umpC0D0
+ 00000000 01 07 b0 20 00 07 b0 20 64 3c 90 20 64 3c 80 20 |... ... d<. d<. |
+
+Unlike the MIDI 1.0 byte stream, UMP is a 32bit packet, and the size
+for reading or writing the device is also aligned to 32bit (which is 4
+bytes).
+
+The 32-bit words in the UMP packet payload are always in CPU native
+endianness. Transport drivers are responsible to convert UMP words
+from / to system endianness to required transport endianness / byte
+order.
+
+When `CONFIG_SND_UMP_LEGACY_RAWMIDI` is set, the driver creates
+another standard raw MIDI device additionally as `/dev/snd/midiC*D*`.
+This contains 16 substreams, and each substream corresponds to a
+(0-based) UMP Group. Legacy applications can access to the specified
+group via each substream in MIDI 1.0 byte stream format. With the
+ALSA rawmidi API, you can open the arbitrary substream, while just
+opening `/dev/snd/midiC*D*` will end up with opening the first
+substream.
+
+Each UMP Endpoint can provide the additional information, constructed
+from the information inquired via UMP 1.1 Stream messages or USB MIDI
+2.0 descriptors. And a UMP Endpoint may contain one or more UMP
+Blocks, where UMP Block is an abstraction introduced in the ALSA UMP
+implementations to represent the associations among UMP Groups. UMP
+Block corresponds to Function Block in UMP 1.1 specification. When
+UMP 1.1 Function Block information isn't available, it's filled
+partially from Group Terminal Block (GTB) as defined in USB MIDI 2.0
+specifications.
+
+The information of UMP Endpoints and UMP Blocks are found in the proc
+file `/proc/asound/card*/midi*`. For example::
+
+ % cat /proc/asound/card1/midi0
+ ProtoZOA MIDI
+
+ Type: UMP
+ EP Name: ProtoZOA
+ EP Product ID: ABCD12345678
+ UMP Version: 0x0000
+ Protocol Caps: 0x00000100
+ Protocol: 0x00000100
+ Num Blocks: 3
+
+ Block 0 (ProtoZOA Main)
+ Direction: bidirection
+ Active: Yes
+ Groups: 1-1
+ Is MIDI1: No
+
+ Block 1 (ProtoZOA Ext IN)
+ Direction: output
+ Active: Yes
+ Groups: 2-2
+ Is MIDI1: Yes (Low Speed)
+ ....
+
+Note that `Groups` field shown in the proc file above indicates the
+1-based UMP Group numbers (from-to).
+
+Those additional UMP Endpoint and UMP Block information can be
+obtained via the new ioctls `SNDRV_UMP_IOCTL_ENDPOINT_INFO` and
+`SNDRV_UMP_IOCTL_BLOCK_INFO`, respectively.
+
+The rawmidi name and the UMP Endpoint name are usually identical, and
+in the case of USB MIDI, it's taken from `iInterface` of the
+corresponding USB MIDI interface descriptor. If it's not provided,
+it's copied from `iProduct` of the USB device descriptor as a
+fallback.
+
+The Endpoint Product ID is a string field and supposed to be unique.
+It's copied from `iSerialNumber` of the device for USB MIDI.
+
+The protocol capabilities and the actual protocol bits are defined in
+`asound.h`.
+
+
+ALSA Sequencer with USB MIDI 2.0
+================================
+
+In addition to the rawmidi interfaces, ALSA sequencer interface
+supports the new UMP MIDI 2.0 device, too. Now, each ALSA sequencer
+client may set its MIDI version (0, 1 or 2) to declare itself being
+either the legacy, UMP MIDI 1.0 or UMP MIDI 2.0 device, respectively.
+The first, legacy client is the one that sends/receives the old
+sequencer event as was. Meanwhile, UMP MIDI 1.0 and 2.0 clients send
+and receive in the extended event record for UMP. The MIDI version is
+seen in the new `midi_version` field of `snd_seq_client_info`.
+
+A UMP packet can be sent/received in a sequencer event embedded by
+specifying the new event flag bit `SNDRV_SEQ_EVENT_UMP`. When this
+flag is set, the event has 16 byte (128 bit) data payload for holding
+the UMP packet. Without the `SNDRV_SEQ_EVENT_UMP` bit flag, the event
+is treated as a legacy event as it was (with max 12 byte data
+payload).
+
+With `SNDRV_SEQ_EVENT_UMP` flag set, the type field of a UMP sequencer
+event is ignored (but it should be set to 0 as default).
+
+The type of each client can be seen in `/proc/asound/seq/clients`.
+For example::
+
+ % cat /proc/asound/seq/clients
+ Client info
+ cur clients : 3
+ ....
+ Client 14 : "Midi Through" [Kernel Legacy]
+ Port 0 : "Midi Through Port-0" (RWe-)
+ Client 20 : "ProtoZOA" [Kernel UMP MIDI1]
+ UMP Endpoint: ProtoZOA
+ UMP Block 0: ProtoZOA Main [Active]
+ Groups: 1-1
+ UMP Block 1: ProtoZOA Ext IN [Active]
+ Groups: 2-2
+ UMP Block 2: ProtoZOA Ext OUT [Active]
+ Groups: 3-3
+ Port 0 : "MIDI 2.0" (RWeX) [In/Out]
+ Port 1 : "ProtoZOA Main" (RWeX) [In/Out]
+ Port 2 : "ProtoZOA Ext IN" (-We-) [Out]
+ Port 3 : "ProtoZOA Ext OUT" (R-e-) [In]
+
+Here you can find two types of kernel clients, "Legacy" for client 14,
+and "UMP MIDI1" for client 20, which is a USB MIDI 2.0 device.
+A USB MIDI 2.0 client gives always the port 0 as "MIDI 2.0" and the
+rest ports from 1 for each UMP Group (e.g. port 1 for Group 1).
+In this example, the device has three active groups (Main, Ext IN and
+Ext OUT), and those are exposed as sequencer ports from 1 to 3.
+The "MIDI 2.0" port is for a UMP Endpoint, and its difference from
+other UMP Group ports is that UMP Endpoint port sends the events from
+the all ports on the device ("catch-all"), while each UMP Group port
+sends only the events from the given UMP Group.
+Also, UMP groupless messages (such as the UMP message type 0x0f) are
+sent only to the UMP Endpoint port.
+
+Note that, although each UMP sequencer client usually creates 16
+ports, those ports that don't belong to any UMP Blocks (or belonging
+to inactive UMP Blocks) are marked as inactive, and they don't appear
+in the proc outputs. In the example above, the sequencer ports from 4
+to 16 are present but not shown there.
+
+The proc file above shows the UMP Block information, too. The same
+entry (but with more detailed information) is found in the rawmidi
+proc output.
+
+When clients are connected between different MIDI versions, the events
+are translated automatically depending on the client's version, not
+only between the legacy and the UMP MIDI 1.0/2.0 types, but also
+between UMP MIDI 1.0 and 2.0 types, too. For example, running
+`aseqdump` program on the ProtoZOA Main port in the legacy mode will
+give you the output like::
+
+ % aseqdump -p 20:1
+ Waiting for data. Press Ctrl+C to end.
+ Source Event Ch Data
+ 20:1 Note on 0, note 60, velocity 100
+ 20:1 Note off 0, note 60, velocity 100
+ 20:1 Control change 0, controller 11, value 4
+
+When you run `aseqdump` in MIDI 2.0 mode, it'll receive the high
+precision data like::
+
+ % aseqdump -u 2 -p 20:1
+ Waiting for data. Press Ctrl+C to end.
+ Source Event Ch Data
+ 20:1 Note on 0, note 60, velocity 0xc924, attr type = 0, data = 0x0
+ 20:1 Note off 0, note 60, velocity 0xc924, attr type = 0, data = 0x0
+ 20:1 Control change 0, controller 11, value 0x2000000
+
+while the data is automatically converted by ALSA sequencer core.
+
+
+Rawmidi API Extensions
+======================
+
+* The additional UMP Endpoint information can be obtained via the new
+ ioctl `SNDRV_UMP_IOCTL_ENDPOINT_INFO`. It contains the associated
+ card and device numbers, the bit flags, the protocols, the number of
+ UMP Blocks, the name string of the endpoint, etc.
+
+ The protocols are specified in two field, the protocol capabilities
+ and the current protocol. Both contain the bit flags specifying the
+ MIDI protocol version (`SNDRV_UMP_EP_INFO_PROTO_MIDI1` or
+ `SNDRV_UMP_EP_INFO_PROTO_MIDI2`) in the upper byte and the jitter
+ reduction timestamp (`SNDRV_UMP_EP_INFO_PROTO_JRTS_TX` and
+ `SNDRV_UMP_EP_INFO_PROTO_JRTS_RX`) in the lower byte.
+
+ A UMP Endpoint may contain up to 32 UMP Blocks, and the number of
+ the currently assigned blocks are shown in the Endpoint information.
+
+* Each UMP Block information can be obtained via another new ioctl
+ `SNDRV_UMP_IOCTL_BLOCK_INFO`. The block ID number (0-based) has to
+ be passed for the block to query. The received data contains the
+ associated the direction of the block, the first associated group ID
+ (0-based) and the number of groups, the name string of the block,
+ etc.
+
+ The direction is either `SNDRV_UMP_DIR_INPUT`,
+ `SNDRV_UMP_DIR_OUTPUT` or `SNDRV_UMP_DIR_BIDIRECTION`.
+
+* For the device supports UMP v1.1, the UMP MIDI protocol can be
+ switched via "Stream Configuration Request" message (UMP type 0x0f,
+ status 0x05). When UMP core receives such a message, it updates the
+ UMP EP info and the corresponding sequencer clients as well.
+
+
+Control API Extensions
+======================
+
+* The new ioctl `SNDRV_CTL_IOCTL_UMP_NEXT_DEVICE` is introduced for
+ querying the next UMP rawmidi device, while the existing ioctl
+ `SNDRV_CTL_IOCTL_RAWMIDI_NEXT_DEVICE` queries only the legacy
+ rawmidi devices.
+
+ For setting the subdevice (substream number) to be opened, use the
+ ioctl `SNDRV_CTL_IOCTL_RAWMIDI_PREFER_SUBDEVICE` like the normal
+ rawmidi.
+
+* Two new ioctls `SNDRV_CTL_IOCTL_UMP_ENDPOINT_INFO` and
+ `SNDRV_CTL_IOCTL_UMP_BLOCK_INFO` provide the UMP Endpoint and UMP
+ Block information of the specified UMP device via ALSA control API
+ without opening the actual (UMP) rawmidi device.
+ The `card` field is ignored upon inquiry, always tied with the card
+ of the control interface.
+
+
+Sequencer API Extensions
+========================
+
+* `midi_version` field is added to `snd_seq_client_info` to indicate
+ the current MIDI version (either 0, 1 or 2) of each client.
+ When `midi_version` is 1 or 2, the alignment of read from a UMP
+ sequencer client is also changed from the former 28 bytes to 32
+ bytes for the extended payload. The alignment size for the write
+ isn't changed, but each event size may differ depending on the new
+ bit flag below.
+
+* `SNDRV_SEQ_EVENT_UMP` flag bit is added for each sequencer event
+ flags. When this bit flag is set, the sequencer event is extended
+ to have a larger payload of 16 bytes instead of the legacy 12
+ bytes, and the event contains the UMP packet in the payload.
+
+* The new sequencer port type bit (`SNDRV_SEQ_PORT_TYPE_MIDI_UMP`)
+ indicates the port being UMP-capable.
+
+* The sequencer ports have new capability bits to indicate the
+ inactive ports (`SNDRV_SEQ_PORT_CAP_INACTIVE`) and the UMP Endpoint
+ port (`SNDRV_SEQ_PORT_CAP_UMP_ENDPOINT`).
+
+* The event conversion of ALSA sequencer clients can be suppressed the
+ new filter bit `SNDRV_SEQ_FILTER_NO_CONVERT` set to the client info.
+ For example, the kernel pass-through client (`snd-seq-dummy`) sets
+ this flag internally.
+
+* The port information gained the new field `direction` to indicate
+ the direction of the port (either `SNDRV_SEQ_PORT_DIR_INPUT`,
+ `SNDRV_SEQ_PORT_DIR_OUTPUT` or `SNDRV_SEQ_PORT_DIR_BIDIRECTION`).
+
+* Another additional field for the port information is `ump_group`
+ which specifies the associated UMP Group Number (1-based).
+ When it's non-zero, the UMP group field in the UMP packet updated
+ upon delivery to the specified group (corrected to be 0-based).
+ Each sequencer port is supposed to set this field if it's a port to
+ specific to a certain UMP group.
+
+* Each client may set the additional event filter for UMP Groups in
+ `group_filter` bitmap. The filter consists of bitmap from 1-based
+ Group numbers. For example, when the bit 1 is set, messages from
+ Group 1 (i.e. the very first group) are filtered and not delivered.
+ The bit 0 is used for filtering UMP groupless messages.
+
+* Two new ioctls are added for UMP-capable clients:
+ `SNDRV_SEQ_IOCTL_GET_CLIENT_UMP_INFO` and
+ `SNDRV_SEQ_IOCTL_SET_CLIENT_UMP_INFO`. They are used to get and set
+ either `snd_ump_endpoint_info` or `snd_ump_block_info` data
+ associated with the sequencer client. The USB MIDI driver provides
+ those information from the underlying UMP rawmidi, while a
+ user-space client may provide its own data via `*_SET` ioctl.
+ For an Endpoint data, pass 0 to the `type` field, while for a Block
+ data, pass the block number + 1 to the `type` field.
+ Setting the data for a kernel client shall result in an error.
+
+* With UMP 1.1, Function Block information may be changed
+ dynamically. When the update of Function Block is received from the
+ device, ALSA sequencer core changes the corresponding sequencer port
+ name and attributes accordingly, and notifies the changes via the
+ announcement to the ALSA sequencer system port, similarly like the
+ normal port change notification.
diff --git a/Documentation/subsystem-apis.rst b/Documentation/subsystem-apis.rst
index b51f385..b67a1b6 100644
--- a/Documentation/subsystem-apis.rst
+++ b/Documentation/subsystem-apis.rst
@@ -10,6 +10,30 @@
as needed (or at least as we managed to add it — probably *not* all that is
needed).
+Human interfaces
+----------------
+
+.. toctree::
+ :maxdepth: 1
+
+ input/index
+ hid/index
+ sound/index
+ gpu/index
+ fb/index
+
+Storage interfaces
+------------------
+
+.. toctree::
+ :maxdepth: 1
+
+ filesystems/index
+ block/index
+ cdrom/index
+ scsi/index
+ target/index
+
**Fixme**: much more organizational work is needed here.
.. toctree::
@@ -19,12 +43,8 @@
core-api/index
locking/index
accounting/index
- block/index
- cdrom/index
cpu-freq/index
- fb/index
fpga/index
- hid/index
i2c/index
iio/index
isdn/index
@@ -34,26 +54,21 @@
networking/index
pcmcia/index
power/index
- target/index
timers/index
spi/index
w1/index
watchdog/index
virt/index
- input/index
hwmon/index
- gpu/index
accel/index
security/index
- sound/index
crypto/index
- filesystems/index
mm/index
bpf/index
usb/index
PCI/index
- scsi/index
misc-devices/index
scheduler/index
mhi/index
peci/index
+ wmi/index
diff --git a/Documentation/target/scripts.rst b/Documentation/target/scripts.rst
index 172d42b..aa7b9c6 100644
--- a/Documentation/target/scripts.rst
+++ b/Documentation/target/scripts.rst
@@ -1,9 +1,3 @@
-TCM mod builder script
-----------------------
-
-.. literalinclude:: tcm_mod_builder.py
- :language: perl
-
Target export device script
---------------------------
diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py
deleted file mode 100755
index 54492aa..0000000
--- a/Documentation/target/tcm_mod_builder.py
+++ /dev/null
@@ -1,656 +0,0 @@
-#!/usr/bin/env python
-# The TCM v4 multi-protocol fabric module generation script for drivers/target/$NEW_MOD
-#
-# Copyright (c) 2010 Rising Tide Systems
-# Copyright (c) 2010 Linux-iSCSI.org
-#
-# Author: nab@kernel.org
-#
-import os, sys
-import subprocess as sub
-import string
-import re
-import optparse
-
-tcm_dir = ""
-
-fabric_ops = []
-fabric_mod_dir = ""
-fabric_mod_port = ""
-fabric_mod_init_port = ""
-
-def tcm_mod_err(msg):
- print msg
- sys.exit(1)
-
-def tcm_mod_create_module_subdir(fabric_mod_dir_var):
-
- if os.path.isdir(fabric_mod_dir_var) == True:
- return 1
-
- print "Creating fabric_mod_dir: " + fabric_mod_dir_var
- ret = os.mkdir(fabric_mod_dir_var)
- if ret:
- tcm_mod_err("Unable to mkdir " + fabric_mod_dir_var)
-
- return
-
-def tcm_mod_build_FC_include(fabric_mod_dir_var, fabric_mod_name):
- global fabric_mod_port
- global fabric_mod_init_port
- buf = ""
-
- f = fabric_mod_dir_var + "/" + fabric_mod_name + "_base.h"
- print "Writing file: " + f
-
- p = open(f, 'w');
- if not p:
- tcm_mod_err("Unable to open file: " + f)
-
- buf = "#define " + fabric_mod_name.upper() + "_VERSION \"v0.1\"\n"
- buf += "#define " + fabric_mod_name.upper() + "_NAMELEN 32\n"
- buf += "\n"
- buf += "struct " + fabric_mod_name + "_tpg {\n"
- buf += " /* FC lport target portal group tag for TCM */\n"
- buf += " u16 lport_tpgt;\n"
- buf += " /* Pointer back to " + fabric_mod_name + "_lport */\n"
- buf += " struct " + fabric_mod_name + "_lport *lport;\n"
- buf += " /* Returned by " + fabric_mod_name + "_make_tpg() */\n"
- buf += " struct se_portal_group se_tpg;\n"
- buf += "};\n"
- buf += "\n"
- buf += "struct " + fabric_mod_name + "_lport {\n"
- buf += " /* Binary World Wide unique Port Name for FC Target Lport */\n"
- buf += " u64 lport_wwpn;\n"
- buf += " /* ASCII formatted WWPN for FC Target Lport */\n"
- buf += " char lport_name[" + fabric_mod_name.upper() + "_NAMELEN];\n"
- buf += " /* Returned by " + fabric_mod_name + "_make_lport() */\n"
- buf += " struct se_wwn lport_wwn;\n"
- buf += "};\n"
-
- ret = p.write(buf)
- if ret:
- tcm_mod_err("Unable to write f: " + f)
-
- p.close()
-
- fabric_mod_port = "lport"
- fabric_mod_init_port = "nport"
-
- return
-
-def tcm_mod_build_SAS_include(fabric_mod_dir_var, fabric_mod_name):
- global fabric_mod_port
- global fabric_mod_init_port
- buf = ""
-
- f = fabric_mod_dir_var + "/" + fabric_mod_name + "_base.h"
- print "Writing file: " + f
-
- p = open(f, 'w');
- if not p:
- tcm_mod_err("Unable to open file: " + f)
-
- buf = "#define " + fabric_mod_name.upper() + "_VERSION \"v0.1\"\n"
- buf += "#define " + fabric_mod_name.upper() + "_NAMELEN 32\n"
- buf += "\n"
- buf += "struct " + fabric_mod_name + "_tpg {\n"
- buf += " /* SAS port target portal group tag for TCM */\n"
- buf += " u16 tport_tpgt;\n"
- buf += " /* Pointer back to " + fabric_mod_name + "_tport */\n"
- buf += " struct " + fabric_mod_name + "_tport *tport;\n"
- buf += " /* Returned by " + fabric_mod_name + "_make_tpg() */\n"
- buf += " struct se_portal_group se_tpg;\n"
- buf += "};\n\n"
- buf += "struct " + fabric_mod_name + "_tport {\n"
- buf += " /* Binary World Wide unique Port Name for SAS Target port */\n"
- buf += " u64 tport_wwpn;\n"
- buf += " /* ASCII formatted WWPN for SAS Target port */\n"
- buf += " char tport_name[" + fabric_mod_name.upper() + "_NAMELEN];\n"
- buf += " /* Returned by " + fabric_mod_name + "_make_tport() */\n"
- buf += " struct se_wwn tport_wwn;\n"
- buf += "};\n"
-
- ret = p.write(buf)
- if ret:
- tcm_mod_err("Unable to write f: " + f)
-
- p.close()
-
- fabric_mod_port = "tport"
- fabric_mod_init_port = "iport"
-
- return
-
-def tcm_mod_build_iSCSI_include(fabric_mod_dir_var, fabric_mod_name):
- global fabric_mod_port
- global fabric_mod_init_port
- buf = ""
-
- f = fabric_mod_dir_var + "/" + fabric_mod_name + "_base.h"
- print "Writing file: " + f
-
- p = open(f, 'w');
- if not p:
- tcm_mod_err("Unable to open file: " + f)
-
- buf = "#define " + fabric_mod_name.upper() + "_VERSION \"v0.1\"\n"
- buf += "#define " + fabric_mod_name.upper() + "_NAMELEN 32\n"
- buf += "\n"
- buf += "struct " + fabric_mod_name + "_tpg {\n"
- buf += " /* iSCSI target portal group tag for TCM */\n"
- buf += " u16 tport_tpgt;\n"
- buf += " /* Pointer back to " + fabric_mod_name + "_tport */\n"
- buf += " struct " + fabric_mod_name + "_tport *tport;\n"
- buf += " /* Returned by " + fabric_mod_name + "_make_tpg() */\n"
- buf += " struct se_portal_group se_tpg;\n"
- buf += "};\n\n"
- buf += "struct " + fabric_mod_name + "_tport {\n"
- buf += " /* ASCII formatted TargetName for IQN */\n"
- buf += " char tport_name[" + fabric_mod_name.upper() + "_NAMELEN];\n"
- buf += " /* Returned by " + fabric_mod_name + "_make_tport() */\n"
- buf += " struct se_wwn tport_wwn;\n"
- buf += "};\n"
-
- ret = p.write(buf)
- if ret:
- tcm_mod_err("Unable to write f: " + f)
-
- p.close()
-
- fabric_mod_port = "tport"
- fabric_mod_init_port = "iport"
-
- return
-
-def tcm_mod_build_base_includes(proto_ident, fabric_mod_dir_val, fabric_mod_name):
-
- if proto_ident == "FC":
- tcm_mod_build_FC_include(fabric_mod_dir_val, fabric_mod_name)
- elif proto_ident == "SAS":
- tcm_mod_build_SAS_include(fabric_mod_dir_val, fabric_mod_name)
- elif proto_ident == "iSCSI":
- tcm_mod_build_iSCSI_include(fabric_mod_dir_val, fabric_mod_name)
- else:
- print "Unsupported proto_ident: " + proto_ident
- sys.exit(1)
-
- return
-
-def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name):
- buf = ""
-
- f = fabric_mod_dir_var + "/" + fabric_mod_name + "_configfs.c"
- print "Writing file: " + f
-
- p = open(f, 'w');
- if not p:
- tcm_mod_err("Unable to open file: " + f)
-
- buf = "#include <linux/module.h>\n"
- buf += "#include <linux/moduleparam.h>\n"
- buf += "#include <linux/version.h>\n"
- buf += "#include <generated/utsrelease.h>\n"
- buf += "#include <linux/utsname.h>\n"
- buf += "#include <linux/init.h>\n"
- buf += "#include <linux/slab.h>\n"
- buf += "#include <linux/kthread.h>\n"
- buf += "#include <linux/types.h>\n"
- buf += "#include <linux/string.h>\n"
- buf += "#include <linux/configfs.h>\n"
- buf += "#include <linux/ctype.h>\n"
- buf += "#include <asm/unaligned.h>\n"
- buf += "#include <scsi/scsi_proto.h>\n\n"
- buf += "#include <target/target_core_base.h>\n"
- buf += "#include <target/target_core_fabric.h>\n"
- buf += "#include \"" + fabric_mod_name + "_base.h\"\n"
- buf += "#include \"" + fabric_mod_name + "_fabric.h\"\n\n"
-
- buf += "static const struct target_core_fabric_ops " + fabric_mod_name + "_ops;\n\n"
-
- buf += "static struct se_portal_group *" + fabric_mod_name + "_make_tpg(\n"
- buf += " struct se_wwn *wwn,\n"
- buf += " struct config_group *group,\n"
- buf += " const char *name)\n"
- buf += "{\n"
- buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + "*" + fabric_mod_port + " = container_of(wwn,\n"
- buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + ", " + fabric_mod_port + "_wwn);\n\n"
- buf += " struct " + fabric_mod_name + "_tpg *tpg;\n"
- buf += " unsigned long tpgt;\n"
- buf += " int ret;\n\n"
- buf += " if (strstr(name, \"tpgt_\") != name)\n"
- buf += " return ERR_PTR(-EINVAL);\n"
- buf += " if (kstrtoul(name + 5, 10, &tpgt) || tpgt > UINT_MAX)\n"
- buf += " return ERR_PTR(-EINVAL);\n\n"
- buf += " tpg = kzalloc(sizeof(struct " + fabric_mod_name + "_tpg), GFP_KERNEL);\n"
- buf += " if (!tpg) {\n"
- buf += " printk(KERN_ERR \"Unable to allocate struct " + fabric_mod_name + "_tpg\");\n"
- buf += " return ERR_PTR(-ENOMEM);\n"
- buf += " }\n"
- buf += " tpg->" + fabric_mod_port + " = " + fabric_mod_port + ";\n"
- buf += " tpg->" + fabric_mod_port + "_tpgt = tpgt;\n\n"
-
- if proto_ident == "FC":
- buf += " ret = core_tpg_register(wwn, &tpg->se_tpg, SCSI_PROTOCOL_FCP);\n"
- elif proto_ident == "SAS":
- buf += " ret = core_tpg_register(wwn, &tpg->se_tpg, SCSI_PROTOCOL_SAS);\n"
- elif proto_ident == "iSCSI":
- buf += " ret = core_tpg_register(wwn, &tpg->se_tpg, SCSI_PROTOCOL_ISCSI);\n"
-
- buf += " if (ret < 0) {\n"
- buf += " kfree(tpg);\n"
- buf += " return NULL;\n"
- buf += " }\n"
- buf += " return &tpg->se_tpg;\n"
- buf += "}\n\n"
- buf += "static void " + fabric_mod_name + "_drop_tpg(struct se_portal_group *se_tpg)\n"
- buf += "{\n"
- buf += " struct " + fabric_mod_name + "_tpg *tpg = container_of(se_tpg,\n"
- buf += " struct " + fabric_mod_name + "_tpg, se_tpg);\n\n"
- buf += " core_tpg_deregister(se_tpg);\n"
- buf += " kfree(tpg);\n"
- buf += "}\n\n"
-
- buf += "static struct se_wwn *" + fabric_mod_name + "_make_" + fabric_mod_port + "(\n"
- buf += " struct target_fabric_configfs *tf,\n"
- buf += " struct config_group *group,\n"
- buf += " const char *name)\n"
- buf += "{\n"
- buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + " *" + fabric_mod_port + ";\n"
-
- if proto_ident == "FC" or proto_ident == "SAS":
- buf += " u64 wwpn = 0;\n\n"
-
- buf += " /* if (" + fabric_mod_name + "_parse_wwn(name, &wwpn, 1) < 0)\n"
- buf += " return ERR_PTR(-EINVAL); */\n\n"
- buf += " " + fabric_mod_port + " = kzalloc(sizeof(struct " + fabric_mod_name + "_" + fabric_mod_port + "), GFP_KERNEL);\n"
- buf += " if (!" + fabric_mod_port + ") {\n"
- buf += " printk(KERN_ERR \"Unable to allocate struct " + fabric_mod_name + "_" + fabric_mod_port + "\");\n"
- buf += " return ERR_PTR(-ENOMEM);\n"
- buf += " }\n"
-
- if proto_ident == "FC" or proto_ident == "SAS":
- buf += " " + fabric_mod_port + "->" + fabric_mod_port + "_wwpn = wwpn;\n"
-
- buf += " /* " + fabric_mod_name + "_format_wwn(&" + fabric_mod_port + "->" + fabric_mod_port + "_name[0], " + fabric_mod_name.upper() + "_NAMELEN, wwpn); */\n\n"
- buf += " return &" + fabric_mod_port + "->" + fabric_mod_port + "_wwn;\n"
- buf += "}\n\n"
- buf += "static void " + fabric_mod_name + "_drop_" + fabric_mod_port + "(struct se_wwn *wwn)\n"
- buf += "{\n"
- buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + " *" + fabric_mod_port + " = container_of(wwn,\n"
- buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + ", " + fabric_mod_port + "_wwn);\n"
- buf += " kfree(" + fabric_mod_port + ");\n"
- buf += "}\n\n"
-
- buf += "static const struct target_core_fabric_ops " + fabric_mod_name + "_ops = {\n"
- buf += " .module = THIS_MODULE,\n"
- buf += " .name = \"" + fabric_mod_name + "\",\n"
- buf += " .get_fabric_name = " + fabric_mod_name + "_get_fabric_name,\n"
- buf += " .tpg_get_wwn = " + fabric_mod_name + "_get_fabric_wwn,\n"
- buf += " .tpg_get_tag = " + fabric_mod_name + "_get_tag,\n"
- buf += " .tpg_check_demo_mode = " + fabric_mod_name + "_check_false,\n"
- buf += " .tpg_check_demo_mode_cache = " + fabric_mod_name + "_check_true,\n"
- buf += " .tpg_check_demo_mode_write_protect = " + fabric_mod_name + "_check_true,\n"
- buf += " .tpg_check_prod_mode_write_protect = " + fabric_mod_name + "_check_false,\n"
- buf += " .tpg_get_inst_index = " + fabric_mod_name + "_tpg_get_inst_index,\n"
- buf += " .release_cmd = " + fabric_mod_name + "_release_cmd,\n"
- buf += " .sess_get_index = " + fabric_mod_name + "_sess_get_index,\n"
- buf += " .sess_get_initiator_sid = NULL,\n"
- buf += " .write_pending = " + fabric_mod_name + "_write_pending,\n"
- buf += " .set_default_node_attributes = " + fabric_mod_name + "_set_default_node_attrs,\n"
- buf += " .get_cmd_state = " + fabric_mod_name + "_get_cmd_state,\n"
- buf += " .queue_data_in = " + fabric_mod_name + "_queue_data_in,\n"
- buf += " .queue_status = " + fabric_mod_name + "_queue_status,\n"
- buf += " .queue_tm_rsp = " + fabric_mod_name + "_queue_tm_rsp,\n"
- buf += " .aborted_task = " + fabric_mod_name + "_aborted_task,\n"
- buf += " /*\n"
- buf += " * Setup function pointers for generic logic in target_core_fabric_configfs.c\n"
- buf += " */\n"
- buf += " .fabric_make_wwn = " + fabric_mod_name + "_make_" + fabric_mod_port + ",\n"
- buf += " .fabric_drop_wwn = " + fabric_mod_name + "_drop_" + fabric_mod_port + ",\n"
- buf += " .fabric_make_tpg = " + fabric_mod_name + "_make_tpg,\n"
- buf += " .fabric_drop_tpg = " + fabric_mod_name + "_drop_tpg,\n"
- buf += "};\n\n"
-
- buf += "static int __init " + fabric_mod_name + "_init(void)\n"
- buf += "{\n"
- buf += " return target_register_template(&" + fabric_mod_name + "_ops);\n"
- buf += "};\n\n"
-
- buf += "static void __exit " + fabric_mod_name + "_exit(void)\n"
- buf += "{\n"
- buf += " target_unregister_template(&" + fabric_mod_name + "_ops);\n"
- buf += "};\n\n"
-
- buf += "MODULE_DESCRIPTION(\"" + fabric_mod_name.upper() + " series fabric driver\");\n"
- buf += "MODULE_LICENSE(\"GPL\");\n"
- buf += "module_init(" + fabric_mod_name + "_init);\n"
- buf += "module_exit(" + fabric_mod_name + "_exit);\n"
-
- ret = p.write(buf)
- if ret:
- tcm_mod_err("Unable to write f: " + f)
-
- p.close()
-
- return
-
-def tcm_mod_scan_fabric_ops(tcm_dir):
-
- fabric_ops_api = tcm_dir + "include/target/target_core_fabric.h"
-
- print "Using tcm_mod_scan_fabric_ops: " + fabric_ops_api
- process_fo = 0;
-
- p = open(fabric_ops_api, 'r')
-
- line = p.readline()
- while line:
- if process_fo == 0 and re.search('struct target_core_fabric_ops {', line):
- line = p.readline()
- continue
-
- if process_fo == 0:
- process_fo = 1;
- line = p.readline()
- # Search for function pointer
- if not re.search('\(\*', line):
- continue
-
- fabric_ops.append(line.rstrip())
- continue
-
- line = p.readline()
- # Search for function pointer
- if not re.search('\(\*', line):
- continue
-
- fabric_ops.append(line.rstrip())
-
- p.close()
- return
-
-def tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir_var, fabric_mod_name):
- buf = ""
- bufi = ""
-
- f = fabric_mod_dir_var + "/" + fabric_mod_name + "_fabric.c"
- print "Writing file: " + f
-
- p = open(f, 'w')
- if not p:
- tcm_mod_err("Unable to open file: " + f)
-
- fi = fabric_mod_dir_var + "/" + fabric_mod_name + "_fabric.h"
- print "Writing file: " + fi
-
- pi = open(fi, 'w')
- if not pi:
- tcm_mod_err("Unable to open file: " + fi)
-
- buf = "#include <linux/slab.h>\n"
- buf += "#include <linux/kthread.h>\n"
- buf += "#include <linux/types.h>\n"
- buf += "#include <linux/list.h>\n"
- buf += "#include <linux/types.h>\n"
- buf += "#include <linux/string.h>\n"
- buf += "#include <linux/ctype.h>\n"
- buf += "#include <asm/unaligned.h>\n"
- buf += "#include <scsi/scsi_common.h>\n"
- buf += "#include <scsi/scsi_proto.h>\n"
- buf += "#include <target/target_core_base.h>\n"
- buf += "#include <target/target_core_fabric.h>\n"
- buf += "#include \"" + fabric_mod_name + "_base.h\"\n"
- buf += "#include \"" + fabric_mod_name + "_fabric.h\"\n\n"
-
- buf += "int " + fabric_mod_name + "_check_true(struct se_portal_group *se_tpg)\n"
- buf += "{\n"
- buf += " return 1;\n"
- buf += "}\n\n"
- bufi += "int " + fabric_mod_name + "_check_true(struct se_portal_group *);\n"
-
- buf += "int " + fabric_mod_name + "_check_false(struct se_portal_group *se_tpg)\n"
- buf += "{\n"
- buf += " return 0;\n"
- buf += "}\n\n"
- bufi += "int " + fabric_mod_name + "_check_false(struct se_portal_group *);\n"
-
- total_fabric_ops = len(fabric_ops)
- i = 0
-
- while i < total_fabric_ops:
- fo = fabric_ops[i]
- i += 1
-# print "fabric_ops: " + fo
-
- if re.search('get_fabric_name', fo):
- buf += "char *" + fabric_mod_name + "_get_fabric_name(void)\n"
- buf += "{\n"
- buf += " return \"" + fabric_mod_name + "\";\n"
- buf += "}\n\n"
- bufi += "char *" + fabric_mod_name + "_get_fabric_name(void);\n"
- continue
-
- if re.search('get_wwn', fo):
- buf += "char *" + fabric_mod_name + "_get_fabric_wwn(struct se_portal_group *se_tpg)\n"
- buf += "{\n"
- buf += " struct " + fabric_mod_name + "_tpg *tpg = container_of(se_tpg,\n"
- buf += " struct " + fabric_mod_name + "_tpg, se_tpg);\n"
- buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + " *" + fabric_mod_port + " = tpg->" + fabric_mod_port + ";\n\n"
- buf += " return &" + fabric_mod_port + "->" + fabric_mod_port + "_name[0];\n"
- buf += "}\n\n"
- bufi += "char *" + fabric_mod_name + "_get_fabric_wwn(struct se_portal_group *);\n"
-
- if re.search('get_tag', fo):
- buf += "u16 " + fabric_mod_name + "_get_tag(struct se_portal_group *se_tpg)\n"
- buf += "{\n"
- buf += " struct " + fabric_mod_name + "_tpg *tpg = container_of(se_tpg,\n"
- buf += " struct " + fabric_mod_name + "_tpg, se_tpg);\n"
- buf += " return tpg->" + fabric_mod_port + "_tpgt;\n"
- buf += "}\n\n"
- bufi += "u16 " + fabric_mod_name + "_get_tag(struct se_portal_group *);\n"
-
- if re.search('tpg_get_inst_index\)\(', fo):
- buf += "u32 " + fabric_mod_name + "_tpg_get_inst_index(struct se_portal_group *se_tpg)\n"
- buf += "{\n"
- buf += " return 1;\n"
- buf += "}\n\n"
- bufi += "u32 " + fabric_mod_name + "_tpg_get_inst_index(struct se_portal_group *);\n"
-
- if re.search('\*release_cmd\)\(', fo):
- buf += "void " + fabric_mod_name + "_release_cmd(struct se_cmd *se_cmd)\n"
- buf += "{\n"
- buf += " return;\n"
- buf += "}\n\n"
- bufi += "void " + fabric_mod_name + "_release_cmd(struct se_cmd *);\n"
-
- if re.search('sess_get_index\)\(', fo):
- buf += "u32 " + fabric_mod_name + "_sess_get_index(struct se_session *se_sess)\n"
- buf += "{\n"
- buf += " return 0;\n"
- buf += "}\n\n"
- bufi += "u32 " + fabric_mod_name + "_sess_get_index(struct se_session *);\n"
-
- if re.search('write_pending\)\(', fo):
- buf += "int " + fabric_mod_name + "_write_pending(struct se_cmd *se_cmd)\n"
- buf += "{\n"
- buf += " return 0;\n"
- buf += "}\n\n"
- bufi += "int " + fabric_mod_name + "_write_pending(struct se_cmd *);\n"
-
- if re.search('set_default_node_attributes\)\(', fo):
- buf += "void " + fabric_mod_name + "_set_default_node_attrs(struct se_node_acl *nacl)\n"
- buf += "{\n"
- buf += " return;\n"
- buf += "}\n\n"
- bufi += "void " + fabric_mod_name + "_set_default_node_attrs(struct se_node_acl *);\n"
-
- if re.search('get_cmd_state\)\(', fo):
- buf += "int " + fabric_mod_name + "_get_cmd_state(struct se_cmd *se_cmd)\n"
- buf += "{\n"
- buf += " return 0;\n"
- buf += "}\n\n"
- bufi += "int " + fabric_mod_name + "_get_cmd_state(struct se_cmd *);\n"
-
- if re.search('queue_data_in\)\(', fo):
- buf += "int " + fabric_mod_name + "_queue_data_in(struct se_cmd *se_cmd)\n"
- buf += "{\n"
- buf += " return 0;\n"
- buf += "}\n\n"
- bufi += "int " + fabric_mod_name + "_queue_data_in(struct se_cmd *);\n"
-
- if re.search('queue_status\)\(', fo):
- buf += "int " + fabric_mod_name + "_queue_status(struct se_cmd *se_cmd)\n"
- buf += "{\n"
- buf += " return 0;\n"
- buf += "}\n\n"
- bufi += "int " + fabric_mod_name + "_queue_status(struct se_cmd *);\n"
-
- if re.search('queue_tm_rsp\)\(', fo):
- buf += "void " + fabric_mod_name + "_queue_tm_rsp(struct se_cmd *se_cmd)\n"
- buf += "{\n"
- buf += " return;\n"
- buf += "}\n\n"
- bufi += "void " + fabric_mod_name + "_queue_tm_rsp(struct se_cmd *);\n"
-
- if re.search('aborted_task\)\(', fo):
- buf += "void " + fabric_mod_name + "_aborted_task(struct se_cmd *se_cmd)\n"
- buf += "{\n"
- buf += " return;\n"
- buf += "}\n\n"
- bufi += "void " + fabric_mod_name + "_aborted_task(struct se_cmd *);\n"
-
- ret = p.write(buf)
- if ret:
- tcm_mod_err("Unable to write f: " + f)
-
- p.close()
-
- ret = pi.write(bufi)
- if ret:
- tcm_mod_err("Unable to write fi: " + fi)
-
- pi.close()
- return
-
-def tcm_mod_build_kbuild(fabric_mod_dir_var, fabric_mod_name):
-
- buf = ""
- f = fabric_mod_dir_var + "/Makefile"
- print "Writing file: " + f
-
- p = open(f, 'w')
- if not p:
- tcm_mod_err("Unable to open file: " + f)
-
- buf += fabric_mod_name + "-objs := " + fabric_mod_name + "_fabric.o \\\n"
- buf += " " + fabric_mod_name + "_configfs.o\n"
- buf += "obj-$(CONFIG_" + fabric_mod_name.upper() + ") += " + fabric_mod_name + ".o\n"
-
- ret = p.write(buf)
- if ret:
- tcm_mod_err("Unable to write f: " + f)
-
- p.close()
- return
-
-def tcm_mod_build_kconfig(fabric_mod_dir_var, fabric_mod_name):
-
- buf = ""
- f = fabric_mod_dir_var + "/Kconfig"
- print "Writing file: " + f
-
- p = open(f, 'w')
- if not p:
- tcm_mod_err("Unable to open file: " + f)
-
- buf = "config " + fabric_mod_name.upper() + "\n"
- buf += " tristate \"" + fabric_mod_name.upper() + " fabric module\"\n"
- buf += " depends on TARGET_CORE && CONFIGFS_FS\n"
- buf += " default n\n"
- buf += " help\n"
- buf += " Say Y here to enable the " + fabric_mod_name.upper() + " fabric module\n"
-
- ret = p.write(buf)
- if ret:
- tcm_mod_err("Unable to write f: " + f)
-
- p.close()
- return
-
-def tcm_mod_add_kbuild(tcm_dir, fabric_mod_name):
- buf = "obj-$(CONFIG_" + fabric_mod_name.upper() + ") += " + fabric_mod_name.lower() + "/\n"
- kbuild = tcm_dir + "/drivers/target/Makefile"
-
- f = open(kbuild, 'a')
- f.write(buf)
- f.close()
- return
-
-def tcm_mod_add_kconfig(tcm_dir, fabric_mod_name):
- buf = "source \"drivers/target/" + fabric_mod_name.lower() + "/Kconfig\"\n"
- kconfig = tcm_dir + "/drivers/target/Kconfig"
-
- f = open(kconfig, 'a')
- f.write(buf)
- f.close()
- return
-
-def main(modname, proto_ident):
-# proto_ident = "FC"
-# proto_ident = "SAS"
-# proto_ident = "iSCSI"
-
- tcm_dir = os.getcwd();
- tcm_dir += "/../../"
- print "tcm_dir: " + tcm_dir
- fabric_mod_name = modname
- fabric_mod_dir = tcm_dir + "drivers/target/" + fabric_mod_name
- print "Set fabric_mod_name: " + fabric_mod_name
- print "Set fabric_mod_dir: " + fabric_mod_dir
- print "Using proto_ident: " + proto_ident
-
- if proto_ident != "FC" and proto_ident != "SAS" and proto_ident != "iSCSI":
- print "Unsupported proto_ident: " + proto_ident
- sys.exit(1)
-
- ret = tcm_mod_create_module_subdir(fabric_mod_dir)
- if ret:
- print "tcm_mod_create_module_subdir() failed because module already exists!"
- sys.exit(1)
-
- tcm_mod_build_base_includes(proto_ident, fabric_mod_dir, fabric_mod_name)
- tcm_mod_scan_fabric_ops(tcm_dir)
- tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir, fabric_mod_name)
- tcm_mod_build_configfs(proto_ident, fabric_mod_dir, fabric_mod_name)
- tcm_mod_build_kbuild(fabric_mod_dir, fabric_mod_name)
- tcm_mod_build_kconfig(fabric_mod_dir, fabric_mod_name)
-
- input = raw_input("Would you like to add " + fabric_mod_name + " to drivers/target/Makefile..? [yes,no]: ")
- if input == "yes" or input == "y":
- tcm_mod_add_kbuild(tcm_dir, fabric_mod_name)
-
- input = raw_input("Would you like to add " + fabric_mod_name + " to drivers/target/Kconfig..? [yes,no]: ")
- if input == "yes" or input == "y":
- tcm_mod_add_kconfig(tcm_dir, fabric_mod_name)
-
- return
-
-parser = optparse.OptionParser()
-parser.add_option('-m', '--modulename', help='Module name', dest='modname',
- action='store', nargs=1, type='string')
-parser.add_option('-p', '--protoident', help='Protocol Ident', dest='protoident',
- action='store', nargs=1, type='string')
-
-(opts, args) = parser.parse_args()
-
-mandatories = ['modname', 'protoident']
-for m in mandatories:
- if not opts.__dict__[m]:
- print "mandatory option is missing\n"
- parser.print_help()
- exit(-1)
-
-if __name__ == "__main__":
-
- main(str(opts.modname), opts.protoident)
diff --git a/Documentation/tools/rtla/common_options.rst b/Documentation/tools/rtla/common_options.rst
index af76df6..aeb91ff 100644
--- a/Documentation/tools/rtla/common_options.rst
+++ b/Documentation/tools/rtla/common_options.rst
@@ -2,6 +2,10 @@
Set the osnoise tracer to run the sample threads in the cpu-list.
+**-H**, **--house-keeping** *cpu-list*
+
+ Run rtla control threads only on the given cpu-list.
+
**-d**, **--duration** *time[s|m|h|d]*
Set the duration of the session.
@@ -42,6 +46,10 @@
- *f:prio* - use SCHED_FIFO with *prio*;
- *d:runtime[us|ms|s]:period[us|ms|s]* - use SCHED_DEADLINE with *runtime* and *period* in nanoseconds.
+**-C**, **--cgroup**\[*=cgroup*]
+
+ Set a *cgroup* to the tracer's threads. If the **-C** option is passed without arguments, the tracer's thread will inherit **rtla**'s *cgroup*. Otherwise, the threads will be placed on the *cgroup* passed to the option.
+
**-h**, **--help**
Print help menu.
diff --git a/Documentation/tools/rtla/common_timerlat_aa.rst b/Documentation/tools/rtla/common_timerlat_aa.rst
index 795b9fb..077029e 100644
--- a/Documentation/tools/rtla/common_timerlat_aa.rst
+++ b/Documentation/tools/rtla/common_timerlat_aa.rst
@@ -5,10 +5,3 @@
**--no-aa**
disable auto-analysis, reducing rtla timerlat cpu usage
-
-**--aa-only** *us*
-
- Set stop tracing conditions and run without collecting and displaying statistics.
- Print the auto-analysis if the system hits the stop tracing condition. This option
- is useful to reduce rtla timerlat CPU, enabling the debug without the overhead of
- collecting the statistics.
diff --git a/Documentation/tools/rtla/common_timerlat_options.rst b/Documentation/tools/rtla/common_timerlat_options.rst
index bacdea6..88506b3 100644
--- a/Documentation/tools/rtla/common_timerlat_options.rst
+++ b/Documentation/tools/rtla/common_timerlat_options.rst
@@ -26,3 +26,10 @@
Set the /dev/cpu_dma_latency to *us*, aiming to bound exit from idle latencies.
*cyclictest* sets this value to *0* by default, use **--dma-latency** *0* to have
similar results.
+
+**-u**, **--user-threads**
+
+ Set timerlat to run without a workload, and then dispatches user-space workloads
+ to wait on the timerlat_fd. Once the workload is awakes, it goes to sleep again
+ adding so the measurement for the kernel-to-user and user-to-kernel to the tracer
+ output.
diff --git a/Documentation/tools/rtla/rtla-timerlat-hist.rst b/Documentation/tools/rtla/rtla-timerlat-hist.rst
index 6bf7f0c..057db78 100644
--- a/Documentation/tools/rtla/rtla-timerlat-hist.rst
+++ b/Documentation/tools/rtla/rtla-timerlat-hist.rst
@@ -29,15 +29,18 @@
.. include:: common_options.rst
+.. include:: common_timerlat_aa.rst
+
EXAMPLE
=======
In the example below, **rtla timerlat hist** is set to run for *10* minutes,
in the cpus *0-4*, *skipping zero* only lines. Moreover, **rtla timerlat
hist** will change the priority of the *timerlat* threads to run under
*SCHED_DEADLINE* priority, with a *10us* runtime every *1ms* period. The
-*1ms* period is also passed to the *timerlat* tracer::
+*1ms* period is also passed to the *timerlat* tracer. Auto-analysis is disabled
+to reduce overhead ::
- [root@alien ~]# timerlat hist -d 10m -c 0-4 -P d:100us:1ms -p 1ms
+ [root@alien ~]# timerlat hist -d 10m -c 0-4 -P d:100us:1ms -p 1ms --no-aa
# RTLA timerlat histogram
# Time unit is microseconds (us)
# Duration: 0 00:10:00
diff --git a/Documentation/tools/rtla/rtla-timerlat-top.rst b/Documentation/tools/rtla/rtla-timerlat-top.rst
index 73799c1..1b7cf4e 100644
--- a/Documentation/tools/rtla/rtla-timerlat-top.rst
+++ b/Documentation/tools/rtla/rtla-timerlat-top.rst
@@ -32,6 +32,13 @@
.. include:: common_timerlat_aa.rst
+**--aa-only** *us*
+
+ Set stop tracing conditions and run without collecting and displaying statistics.
+ Print the auto-analysis if the system hits the stop tracing condition. This option
+ is useful to reduce rtla timerlat CPU, enabling the debug without the overhead of
+ collecting the statistics.
+
EXAMPLE
=======
diff --git a/Documentation/trace/coresight/coresight-dummy.rst b/Documentation/trace/coresight/coresight-dummy.rst
new file mode 100644
index 0000000..eff7c55
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-dummy.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================
+Coresight Dummy Trace Module
+=============================
+
+ :Author: Hao Zhang <quic_hazha@quicinc.com>
+ :Date: June 2023
+
+Introduction
+------------
+
+The Coresight dummy trace module is for the specific devices that kernel don't
+have permission to access or configure, e.g., CoreSight TPDMs on Qualcomm
+platforms. For these devices, a dummy driver is needed to register them as
+Coresight devices. The module may also be used to define components that may
+not have any programming interfaces, so that paths can be created in the driver.
+It provides Coresight API for operations on dummy devices, such as enabling and
+disabling them. It also provides the Coresight dummy sink/source paths for
+debugging.
+
+Config details
+--------------
+
+There are two types of nodes, dummy sink and dummy source. These nodes
+are available at ``/sys/bus/coresight/devices``.
+
+Example output::
+
+ $ ls -l /sys/bus/coresight/devices | grep dummy
+ dummy_sink0 -> ../../../devices/platform/soc@0/soc@0:sink/dummy_sink0
+ dummy_source0 -> ../../../devices/platform/soc@0/soc@0:source/dummy_source0
diff --git a/Documentation/trace/fprobetrace.rst b/Documentation/trace/fprobetrace.rst
new file mode 100644
index 0000000..7297f94
--- /dev/null
+++ b/Documentation/trace/fprobetrace.rst
@@ -0,0 +1,188 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================
+Fprobe-based Event Tracing
+==========================
+
+.. Author: Masami Hiramatsu <mhiramat@kernel.org>
+
+Overview
+--------
+
+Fprobe event is similar to the kprobe event, but limited to probe on
+the function entry and exit only. It is good enough for many use cases
+which only traces some specific functions.
+
+This document also covers tracepoint probe events (tprobe) since this
+is also works only on the tracepoint entry. User can trace a part of
+tracepoint argument, or the tracepoint without trace-event, which is
+not exposed on tracefs.
+
+As same as other dynamic events, fprobe events and tracepoint probe
+events are defined via `dynamic_events` interface file on tracefs.
+
+Synopsis of fprobe-events
+-------------------------
+::
+
+ f[:[GRP1/][EVENT1]] SYM [FETCHARGS] : Probe on function entry
+ f[MAXACTIVE][:[GRP1/][EVENT1]] SYM%return [FETCHARGS] : Probe on function exit
+ t[:[GRP2/][EVENT2]] TRACEPOINT [FETCHARGS] : Probe on tracepoint
+
+ GRP1 : Group name for fprobe. If omitted, use "fprobes" for it.
+ GRP2 : Group name for tprobe. If omitted, use "tracepoints" for it.
+ EVENT1 : Event name for fprobe. If omitted, the event name is
+ "SYM__entry" or "SYM__exit".
+ EVENT2 : Event name for tprobe. If omitted, the event name is
+ the same as "TRACEPOINT", but if the "TRACEPOINT" starts
+ with a digit character, "_TRACEPOINT" is used.
+ MAXACTIVE : Maximum number of instances of the specified function that
+ can be probed simultaneously, or 0 for the default value
+ as defined in Documentation/trace/fprobe.rst
+
+ FETCHARGS : Arguments. Each probe can have up to 128 args.
+ ARG : Fetch "ARG" function argument using BTF (only for function
+ entry or tracepoint.) (\*1)
+ @ADDR : Fetch memory at ADDR (ADDR should be in kernel)
+ @SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)
+ $stackN : Fetch Nth entry of stack (N >= 0)
+ $stack : Fetch stack address.
+ $argN : Fetch the Nth function argument. (N >= 1) (\*2)
+ $retval : Fetch return value.(\*3)
+ $comm : Fetch current task comm.
+ +|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*4)(\*5)
+ \IMM : Store an immediate value to the argument.
+ NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
+ FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types
+ (u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types
+ (x8/x16/x32/x64), "char", "string", "ustring", "symbol", "symstr"
+ and bitfield are supported.
+
+ (\*1) This is available only when BTF is enabled.
+ (\*2) only for the probe on function entry (offs == 0).
+ (\*3) only for return probe.
+ (\*4) this is useful for fetching a field of data structures.
+ (\*5) "u" means user-space dereference.
+
+For the details of TYPE, see :ref:`kprobetrace documentation <kprobetrace_types>`.
+
+BTF arguments
+-------------
+BTF (BPF Type Format) argument allows user to trace function and tracepoint
+parameters by its name instead of ``$argN``. This feature is available if the
+kernel is configured with CONFIG_BPF_SYSCALL and CONFIG_DEBUG_INFO_BTF.
+If user only specify the BTF argument, the event's argument name is also
+automatically set by the given name. ::
+
+ # echo 'f:myprobe vfs_read count pos' >> dynamic_events
+ # cat dynamic_events
+ f:fprobes/myprobe vfs_read count=count pos=pos
+
+It also chooses the fetch type from BTF information. For example, in the above
+example, the ``count`` is unsigned long, and the ``pos`` is a pointer. Thus, both
+are converted to 64bit unsigned long, but only ``pos`` has "%Lx" print-format as
+below ::
+
+ # cat events/fprobes/myprobe/format
+ name: myprobe
+ ID: 1313
+ format:
+ field:unsigned short common_type; offset:0; size:2; signed:0;
+ field:unsigned char common_flags; offset:2; size:1; signed:0;
+ field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
+ field:int common_pid; offset:4; size:4; signed:1;
+
+ field:unsigned long __probe_ip; offset:8; size:8; signed:0;
+ field:u64 count; offset:16; size:8; signed:0;
+ field:u64 pos; offset:24; size:8; signed:0;
+
+ print fmt: "(%lx) count=%Lu pos=0x%Lx", REC->__probe_ip, REC->count, REC->pos
+
+If user unsures the name of arguments, ``$arg*`` will be helpful. The ``$arg*``
+is expanded to all function arguments of the function or the tracepoint. ::
+
+ # echo 'f:myprobe vfs_read $arg*' >> dynamic_events
+ # cat dynamic_events
+ f:fprobes/myprobe vfs_read file=file buf=buf count=count pos=pos
+
+BTF also affects the ``$retval``. If user doesn't set any type, the retval type is
+automatically picked from the BTF. If the function returns ``void``, ``$retval``
+is rejected.
+
+Usage examples
+--------------
+Here is an example to add fprobe events on ``vfs_read()`` function entry
+and exit, with BTF arguments.
+::
+
+ # echo 'f vfs_read $arg*' >> dynamic_events
+ # echo 'f vfs_read%return $retval' >> dynamic_events
+ # cat dynamic_events
+ f:fprobes/vfs_read__entry vfs_read file=file buf=buf count=count pos=pos
+ f:fprobes/vfs_read__exit vfs_read%return arg1=$retval
+ # echo 1 > events/fprobes/enable
+ # head -n 20 trace | tail
+ # TASK-PID CPU# ||||| TIMESTAMP FUNCTION
+ # | | | ||||| | |
+ sh-70 [000] ...1. 335.883195: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c6879 count=1 pos=0xffffc900005aff08
+ sh-70 [000] ..... 335.883208: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1
+ sh-70 [000] ...1. 335.883220: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c6879 count=1 pos=0xffffc900005aff08
+ sh-70 [000] ..... 335.883224: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1
+ sh-70 [000] ...1. 335.883232: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c687a count=1 pos=0xffffc900005aff08
+ sh-70 [000] ..... 335.883237: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1
+ sh-70 [000] ...1. 336.050329: vfs_read__entry: (vfs_read+0x4/0x340) file=0xffff888005cf9a80 buf=0x7ffef36c6879 count=1 pos=0xffffc900005aff08
+ sh-70 [000] ..... 336.050343: vfs_read__exit: (ksys_read+0x75/0x100 <- vfs_read) arg1=1
+
+You can see all function arguments and return values are recorded as signed int.
+
+Also, here is an example of tracepoint events on ``sched_switch`` tracepoint.
+To compare the result, this also enables the ``sched_switch`` traceevent too.
+::
+
+ # echo 't sched_switch $arg*' >> dynamic_events
+ # echo 1 > events/sched/sched_switch/enable
+ # echo 1 > events/tracepoints/sched_switch/enable
+ # echo > trace
+ # head -n 20 trace | tail
+ # TASK-PID CPU# ||||| TIMESTAMP FUNCTION
+ # | | | ||||| | |
+ sh-70 [000] d..2. 3912.083993: sched_switch: prev_comm=sh prev_pid=70 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120
+ sh-70 [000] d..3. 3912.083995: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffff88800664e100 next=0xffffffff828229c0 prev_state=1
+ <idle>-0 [000] d..2. 3912.084183: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=16 next_prio=120
+ <idle>-0 [000] d..3. 3912.084184: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffffffff828229c0 next=0xffff888004208000 prev_state=0
+ rcu_preempt-16 [000] d..2. 3912.084196: sched_switch: prev_comm=rcu_preempt prev_pid=16 prev_prio=120 prev_state=I ==> next_comm=swapper/0 next_pid=0 next_prio=120
+ rcu_preempt-16 [000] d..3. 3912.084196: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffff888004208000 next=0xffffffff828229c0 prev_state=1026
+ <idle>-0 [000] d..2. 3912.085191: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=16 next_prio=120
+ <idle>-0 [000] d..3. 3912.085191: sched_switch: (__probestub_sched_switch+0x4/0x10) preempt=0 prev=0xffffffff828229c0 next=0xffff888004208000 prev_state=0
+
+As you can see, the ``sched_switch`` trace-event shows *cooked* parameters, on
+the other hand, the ``sched_switch`` tracepoint probe event shows *raw*
+parameters. This means you can access any field values in the task
+structure pointed by the ``prev`` and ``next`` arguments.
+
+For example, usually ``task_struct::start_time`` is not traced, but with this
+traceprobe event, you can trace it as below.
+::
+
+ # echo 't sched_switch comm=+1896(next):string start_time=+1728(next):u64' > dynamic_events
+ # head -n 20 trace | tail
+ # TASK-PID CPU# ||||| TIMESTAMP FUNCTION
+ # | | | ||||| | |
+ sh-70 [000] d..3. 5606.686577: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="rcu_preempt" usage=1 start_time=245000000
+ rcu_preempt-16 [000] d..3. 5606.686602: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="sh" usage=1 start_time=1596095526
+ sh-70 [000] d..3. 5606.686637: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0
+ <idle>-0 [000] d..3. 5606.687190: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="rcu_preempt" usage=1 start_time=245000000
+ rcu_preempt-16 [000] d..3. 5606.687202: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0
+ <idle>-0 [000] d..3. 5606.690317: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000
+ kworker/0:1-14 [000] d..3. 5606.690339: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0
+ <idle>-0 [000] d..3. 5606.692368: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000
+
+Currently, to find the offset of a specific field in the data structure,
+you need to build kernel with debuginfo and run `perf probe` command with
+`-D` option. e.g.
+::
+
+ # perf probe -D "__probestub_sched_switch next->comm:string next->start_time"
+ p:probe/__probestub_sched_switch __probestub_sched_switch+0 comm=+1896(%cx):string start_time=+1728(%cx):u64
+
+And replace the ``%cx`` with the ``next``.
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 027437b..f606c5b 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -324,6 +324,12 @@
"set_graph_function", or "set_graph_notrace".
(See the section "dynamic ftrace" below for more details.)
+ available_filter_functions_addrs:
+
+ Similar to available_filter_functions, but with address displayed
+ for each function. The displayed address is the patch-site address
+ and can differ from /proc/kallsyms address.
+
dyn_ftrace_total_info:
This file is for debugging purposes. The number of functions that
@@ -1359,6 +1365,19 @@
only a closing curly bracket "}" is displayed for
the return of a function.
+ funcgraph-retval
+ When set, the return value of each traced function
+ will be printed after an equal sign "=". By default
+ this is off.
+
+ funcgraph-retval-hex
+ When set, the return value will always be printed
+ in hexadecimal format. If the option is not set and
+ the return value is an error code, it will be printed
+ in signed decimal format; otherwise it will also be
+ printed in hexadecimal format. By default, this option
+ is off.
+
sleep-time
When running function graph tracer, to include
the time a task schedules out in its function.
@@ -2704,6 +2723,119 @@
0) 1.757 us | } /* kmem_cache_free() */
0) 2.861 us | } /* putname() */
+The return value of each traced function can be displayed after
+an equal sign "=". When encountering system call failures, it
+can be verfy helpful to quickly locate the function that first
+returns an error code.
+
+ - hide: echo nofuncgraph-retval > trace_options
+ - show: echo funcgraph-retval > trace_options
+
+ Example with funcgraph-retval::
+
+ 1) | cgroup_migrate() {
+ 1) 0.651 us | cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
+ 1) | cgroup_migrate_execute() {
+ 1) | cpu_cgroup_can_attach() {
+ 1) | cgroup_taskset_first() {
+ 1) 0.732 us | cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
+ 1) 1.232 us | } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
+ 1) 0.380 us | sched_rt_can_attach(); /* = 0x0 */
+ 1) 2.335 us | } /* cpu_cgroup_can_attach = -22 */
+ 1) 4.369 us | } /* cgroup_migrate_execute = -22 */
+ 1) 7.143 us | } /* cgroup_migrate = -22 */
+
+The above example shows that the function cpu_cgroup_can_attach
+returned the error code -22 firstly, then we can read the code
+of this function to get the root cause.
+
+When the option funcgraph-retval-hex is not set, the return value can
+be displayed in a smart way. Specifically, if it is an error code,
+it will be printed in signed decimal format, otherwise it will
+printed in hexadecimal format.
+
+ - smart: echo nofuncgraph-retval-hex > trace_options
+ - hexadecimal: echo funcgraph-retval-hex > trace_options
+
+ Example with funcgraph-retval-hex::
+
+ 1) | cgroup_migrate() {
+ 1) 0.651 us | cgroup_migrate_add_task(); /* = 0xffff93fcfd346c00 */
+ 1) | cgroup_migrate_execute() {
+ 1) | cpu_cgroup_can_attach() {
+ 1) | cgroup_taskset_first() {
+ 1) 0.732 us | cgroup_taskset_next(); /* = 0xffff93fc8fb20000 */
+ 1) 1.232 us | } /* cgroup_taskset_first = 0xffff93fc8fb20000 */
+ 1) 0.380 us | sched_rt_can_attach(); /* = 0x0 */
+ 1) 2.335 us | } /* cpu_cgroup_can_attach = 0xffffffea */
+ 1) 4.369 us | } /* cgroup_migrate_execute = 0xffffffea */
+ 1) 7.143 us | } /* cgroup_migrate = 0xffffffea */
+
+At present, there are some limitations when using the funcgraph-retval
+option, and these limitations will be eliminated in the future:
+
+- Even if the function return type is void, a return value will still
+ be printed, and you can just ignore it.
+
+- Even if return values are stored in multiple registers, only the
+ value contained in the first register will be recorded and printed.
+ To illustrate, in the x86 architecture, eax and edx are used to store
+ a 64-bit return value, with the lower 32 bits saved in eax and the
+ upper 32 bits saved in edx. However, only the value stored in eax
+ will be recorded and printed.
+
+- In certain procedure call standards, such as arm64's AAPCS64, when a
+ type is smaller than a GPR, it is the responsibility of the consumer
+ to perform the narrowing, and the upper bits may contain UNKNOWN values.
+ Therefore, it is advisable to check the code for such cases. For instance,
+ when using a u8 in a 64-bit GPR, bits [63:8] may contain arbitrary values,
+ especially when larger types are truncated, whether explicitly or implicitly.
+ Here are some specific cases to illustrate this point:
+
+ **Case One**:
+
+ The function narrow_to_u8 is defined as follows::
+
+ u8 narrow_to_u8(u64 val)
+ {
+ // implicitly truncated
+ return val;
+ }
+
+ It may be compiled to::
+
+ narrow_to_u8:
+ < ... ftrace instrumentation ... >
+ RET
+
+ If you pass 0x123456789abcdef to this function and want to narrow it,
+ it may be recorded as 0x123456789abcdef instead of 0xef.
+
+ **Case Two**:
+
+ The function error_if_not_4g_aligned is defined as follows::
+
+ int error_if_not_4g_aligned(u64 val)
+ {
+ if (val & GENMASK(31, 0))
+ return -EINVAL;
+
+ return 0;
+ }
+
+ It could be compiled to::
+
+ error_if_not_4g_aligned:
+ CBNZ w0, .Lnot_aligned
+ RET // bits [31:0] are zero, bits
+ // [63:32] are UNKNOWN
+ .Lnot_aligned:
+ MOV x0, #-EINVAL
+ RET
+
+ When passing 0x2_0000_0000 to it, the return value may be recorded as
+ 0x2_0000_0000 instead of 0.
+
You can put some comments on specific functions by using
trace_printk() For example, if you want to put a comment inside
the __might_sleep() function, you just have to include
diff --git a/Documentation/trace/hisi-ptt.rst b/Documentation/trace/hisi-ptt.rst
index 4f87d8e..989255eb 100644
--- a/Documentation/trace/hisi-ptt.rst
+++ b/Documentation/trace/hisi-ptt.rst
@@ -148,14 +148,20 @@
value will be 0x00101. If the desired filter is Root Port 0000:00:10.0 then
then filter value is calculated as 0x80001.
+The driver also presents every supported Root Port and Requester filter through
+sysfs. Each filter will be an individual file with name of its related PCIe
+device name (domain:bus:device.function). The files of Root Port filters are
+under $(PTT PMU dir)/root_port_filters and files of Requester filters
+are under $(PTT PMU dir)/requester_filters.
+
Note that multiple Root Ports can be specified at one time, but only one
Endpoint function can be specified in one trace. Specifying both Root Port
and function at the same time is not supported. Driver maintains a list of
available filters and will check the invalid inputs.
-Currently the available filters are detected in driver's probe. If the supported
-devices are removed/added after probe, you may need to reload the driver to update
-the filters.
+The available filters will be dynamically updated, which means you will always
+get correct filter information when hotplug events happen, or when you manually
+remove/rescan the devices.
2. Type
-------
diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
index ea25a92..5092d6c 100644
--- a/Documentation/trace/index.rst
+++ b/Documentation/trace/index.rst
@@ -13,6 +13,7 @@
kprobes
kprobetrace
uprobetracer
+ fprobetrace
tracepoints
events
events-kmem
diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst
index 651f9ab..8a2dfee 100644
--- a/Documentation/trace/kprobetrace.rst
+++ b/Documentation/trace/kprobetrace.rst
@@ -66,6 +66,8 @@
(\*3) this is useful for fetching a field of data structures.
(\*4) "u" means user-space dereference. See :ref:`user_mem_access`.
+.. _kprobetrace_types:
+
Types
-----
Several types are supported for fetchargs. Kprobe tracer will access memory
diff --git a/Documentation/trace/timerlat-tracer.rst b/Documentation/trace/timerlat-tracer.rst
index db17df3..53a5682 100644
--- a/Documentation/trace/timerlat-tracer.rst
+++ b/Documentation/trace/timerlat-tracer.rst
@@ -180,3 +180,81 @@
return 0;
}
+
+User-space interface
+---------------------------
+
+Timerlat allows user-space threads to use timerlat infra-structure to
+measure scheduling latency. This interface is accessible via a per-CPU
+file descriptor inside $tracing_dir/osnoise/per_cpu/cpu$ID/timerlat_fd.
+
+This interface is accessible under the following conditions:
+
+ - timerlat tracer is enable
+ - osnoise workload option is set to NO_OSNOISE_WORKLOAD
+ - The user-space thread is affined to a single processor
+ - The thread opens the file associated with its single processor
+ - Only one thread can access the file at a time
+
+The open() syscall will fail if any of these conditions are not met.
+After opening the file descriptor, the user space can read from it.
+
+The read() system call will run a timerlat code that will arm the
+timer in the future and wait for it as the regular kernel thread does.
+
+When the timer IRQ fires, the timerlat IRQ will execute, report the
+IRQ latency and wake up the thread waiting in the read. The thread will be
+scheduled and report the thread latency via tracer - as for the kernel
+thread.
+
+The difference from the in-kernel timerlat is that, instead of re-arming
+the timer, timerlat will return to the read() system call. At this point,
+the user can run any code.
+
+If the application rereads the file timerlat file descriptor, the tracer
+will report the return from user-space latency, which is the total
+latency. If this is the end of the work, it can be interpreted as the
+response time for the request.
+
+After reporting the total latency, timerlat will restart the cycle, arm
+a timer, and go to sleep for the following activation.
+
+If at any time one of the conditions is broken, e.g., the thread migrates
+while in user space, or the timerlat tracer is disabled, the SIG_KILL
+signal will be sent to the user-space thread.
+
+Here is an basic example of user-space code for timerlat::
+
+ int main(void)
+ {
+ char buffer[1024];
+ int timerlat_fd;
+ int retval;
+ long cpu = 0; /* place in CPU 0 */
+ cpu_set_t set;
+
+ CPU_ZERO(&set);
+ CPU_SET(cpu, &set);
+
+ if (sched_setaffinity(gettid(), sizeof(set), &set) == -1)
+ return 1;
+
+ snprintf(buffer, sizeof(buffer),
+ "/sys/kernel/tracing/osnoise/per_cpu/cpu%ld/timerlat_fd",
+ cpu);
+
+ timerlat_fd = open(buffer, O_RDONLY);
+ if (timerlat_fd < 0) {
+ printf("error opening %s: %s\n", buffer, strerror(errno));
+ exit(1);
+ }
+
+ for (;;) {
+ retval = read(timerlat_fd, buffer, 1024);
+ if (retval < 0)
+ break;
+ }
+
+ close(timerlat_fd);
+ exit(0);
+ }
diff --git a/Documentation/trace/user_events.rst b/Documentation/trace/user_events.rst
index f79987e..e7b0731 100644
--- a/Documentation/trace/user_events.rst
+++ b/Documentation/trace/user_events.rst
@@ -14,10 +14,6 @@
/sys/kernel/tracing/user_events_status and can both register and write
data out via /sys/kernel/tracing/user_events_data.
-Programs can also use /sys/kernel/tracing/dynamic_events to register and
-delete user based events via the u: prefix. The format of the command to
-dynamic_events is the same as the ioctl with the u: prefix applied.
-
Typically programs will register a set of events that they wish to expose to
tools that can read trace_events (such as ftrace and perf). The registration
process tells the kernel which address and bit to reflect if any tool has
@@ -144,6 +140,9 @@
event (in both user and kernel space). User programs should use a separate file
to request deletes than the one used for registration due to this.
+**NOTE:** By default events will auto-delete when there are no references left
+to the event. Flags in the future may change this logic.
+
Unregistering
-------------
If after registering an event it is no longer wanted to be updated then it can
diff --git a/Documentation/translations/zh_CN/arch/arm/Booting b/Documentation/translations/zh_CN/arch/arm/Booting
new file mode 100644
index 0000000..f185851
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm/Booting
@@ -0,0 +1,175 @@
+Chinese translated version of Documentation/arch/arm/booting.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Russell King <linux@arm.linux.org.uk>
+Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
+---------------------------------------------------------------------
+Documentation/arch/arm/booting.rst 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+
+英文版维护者： Russell King <linux@arm.linux.org.uk>
+中文版维护者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
+中文版翻译者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
+中文版校译者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
+
+以下为正文
+---------------------------------------------------------------------
+
+ 启动 ARM Linux
+ ==============
+
+作者：Russell King
+日期：2002年5月18日
+
+以下文档适用于 2.4.18-rmk6 及以上版本。
+
+为了启动 ARM Linux，你需要一个引导装载程序（boot loader），
+它是一个在主内核启动前运行的一个小程序。引导装载程序需要初始化各种
+设备，并最终调用 Linux 内核，将信息传递给内核。
+
+从本质上讲，引导装载程序应提供（至少）以下功能：
+
+1、设置和初始化 RAM。
+2、初始化一个串口。
+3、检测机器的类型（machine type）。
+4、设置内核标签列表（tagged list）。
+5、调用内核映像。
+
+
+1、设置和初始化 RAM
+-------------------
+
+现有的引导加载程序: 强制
+新开发的引导加载程序: 强制
+
+引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。
+这个操作的执行是设备依赖的。（它可能使用内部算法来自动定位和计算所有
+RAM，或可能使用对这个设备已知的 RAM 信息，还可能使用任何引导装载程序
+设计者想到的匹配方法。）
+
+
+2、初始化一个串口
+-----------------------------
+
+现有的引导加载程序: 可选、建议
+新开发的引导加载程序: 可选、建议
+
+引导加载程序应该初始化并使能一个目标板上的串口。这允许内核串口驱动
+自动检测哪个串口用于内核控制台。(一般用于调试或与目标板通信。)
+
+作为替代方案，引导加载程序也可以通过标签列表传递相关的'console='
+选项给内核以指定某个串口，而串口数据格式的选项在以下文档中描述：
+
+ Documentation/admin-guide/kernel-parameters.rst。
+
+
+3、检测机器类型
+--------------------------
+
+现有的引导加载程序: 可选
+新开发的引导加载程序: 强制
+
+引导加载程序应该通过某些方式检测自身所处的机器类型。这是一个硬件
+代码或通过查看所连接的硬件用某些算法得到，这些超出了本文档的范围。
+引导加载程序最终必须能提供一个 MACH_TYPE_xxx 值给内核。
+(详见 linux/arch/arm/tools/mach-types )。
+
+4、设置启动数据
+------------------
+
+现有的引导加载程序: 可选、强烈建议
+新开发的引导加载程序: 强制
+
+引导加载程序必须提供标签列表或者 dtb 映像以传递配置数据给内核。启动
+数据的物理地址通过寄存器 r2 传递给内核。
+
+4a、设置内核标签列表
+--------------------------------
+
+bootloader 必须创建和初始化内核标签列表。一个有效的标签列表以
+ATAG_CORE 标签开始，并以 ATAG_NONE 标签结束。ATAG_CORE 标签可以是
+空的，也可以是非空。一个空 ATAG_CORE 标签其 size 域设置为
+‘2’(0x00000002)。ATAG_NONE 标签的 size 域必须设置为零。
+
+在列表中可以保存任意数量的标签。对于一个重复的标签是追加到之前标签
+所携带的信息之后，还是会覆盖原来的信息，是未定义的。某些标签的行为
+是前者，其他是后者。
+
+bootloader 必须传递一个系统内存的位置和最小值，以及根文件系统位置。
+因此，最小的标签列表如下所示：
+
+ +-----------+
+基地址 -> | ATAG_CORE | |
+ +-----------+ |
+ | ATAG_MEM | | 地址增长方向
+ +-----------+ |
+ | ATAG_NONE | |
+ +-----------+ v
+
+标签列表应该保存在系统的 RAM 中。
+
+标签列表必须置于内核自解压和 initrd'bootp' 程序都不会覆盖的内存区。
+建议放在 RAM 的头 16KiB 中。
+
+4b、设置设备树
+-------------------------
+
+bootloader 必须以 64bit 地址对齐的形式加载一个设备树映像(dtb)到系统
+RAM 中，并用启动数据初始化它。dtb 格式在文档
+https://www.devicetree.org/specifications/ 中。内核将会在
+dtb 物理地址处查找 dtb 魔数值（0xd00dfeed），以确定 dtb 是否已经代替
+标签列表被传递进来。
+
+bootloader 必须传递一个系统内存的位置和最小值，以及根文件系统位置。
+dtb 必须置于内核自解压不会覆盖的内存区。建议将其放置于 RAM 的头 16KiB
+中。但是不可将其放置于“0”物理地址处，因为内核认为：r2 中为 0，意味着
+没有标签列表和 dtb 传递过来。
+
+5、调用内核映像
+---------------------------
+
+现有的引导加载程序: 强制
+新开发的引导加载程序: 强制
+
+调用内核映像 zImage 有两个选择。如果 zImge 保存在 flash 中，且是为了
+在 flash 中直接运行而被正确链接的。这样引导加载程序就可以在 flash 中
+直接调用 zImage。
+
+zImage 也可以被放在系统 RAM（任意位置）中被调用。注意：内核使用映像
+基地址的前 16KB RAM 空间来保存页表。建议将映像置于 RAM 的 32KB 处。
+
+对于以上任意一种情况，都必须符合以下启动状态：
+
+- 停止所有 DMA 设备，这样内存数据就不会因为虚假网络包或磁盘数据而被破坏。
+ 这可能可以节省你许多的调试时间。
+
+- CPU 寄存器配置
+ r0 = 0，
+ r1 = （在上面 3 中获取的）机器类型码。
+ r2 = 标签列表在系统 RAM 中的物理地址，或
+ 设备树块(dtb)在系统 RAM 中的物理地址
+
+- CPU 模式
+ 所有形式的中断必须被禁止 (IRQs 和 FIQs)
+ CPU 必须处于 SVC 模式。(对于 Angel 调试有特例存在)
+
+- 缓存，MMUs
+ MMU 必须关闭。
+ 指令缓存开启或关闭都可以。
+ 数据缓存必须关闭。
+
+- 引导加载程序应该通过直接跳转到内核映像的第一条指令来调用内核映像。
+
+ 对于支持 ARM 指令集的 CPU，跳入内核入口时必须处在 ARM 状态，即使
+ 对于 Thumb-2 内核也是如此。
+
+ 对于仅支持 Thumb 指令集的 CPU，比如 Cortex-M 系列的 CPU，跳入
+ 内核入口时必须处于 Thumb 状态。
diff --git a/Documentation/translations/zh_CN/arch/arm/kernel_user_helpers.txt b/Documentation/translations/zh_CN/arch/arm/kernel_user_helpers.txt
new file mode 100644
index 0000000..018eb7d
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm/kernel_user_helpers.txt
@@ -0,0 +1,284 @@
+Chinese translated version of Documentation/arch/arm/kernel_user_helpers.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Nicolas Pitre <nicolas.pitre@linaro.org>
+ Dave Martin <dave.martin@linaro.org>
+Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
+---------------------------------------------------------------------
+Documentation/arch/arm/kernel_user_helpers.rst 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+英文版维护者： Nicolas Pitre <nicolas.pitre@linaro.org>
+ Dave Martin <dave.martin@linaro.org>
+中文版维护者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
+中文版翻译者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
+中文版校译者： 宋冬生 Dongsheng Song <dongshneg.song@gmail.com>
+ 傅炜 Fu Wei <tekkamanninja@gmail.com>
+
+
+以下为正文
+---------------------------------------------------------------------
+内核提供的用户空间辅助代码
+=========================
+
+在内核内存空间的固定地址处，有一个由内核提供并可从用户空间访问的代码
+段。它用于向用户空间提供因在许多 ARM CPU 中未实现的特性和/或指令而需
+内核提供帮助的某些操作。这些代码直接在用户模式下执行的想法是为了获得
+最佳效率，但那些与内核计数器联系过于紧密的部分，则被留给了用户库实现。
+事实上，此代码甚至可能因不同的 CPU 而异，这取决于其可用的指令集或它
+是否为 SMP 系统。换句话说，内核保留在不作出警告的情况下根据需要更改
+这些代码的权利。只有本文档描述的入口及其结果是保证稳定的。
+
+这与完全成熟的 VDSO 实现不同（但两者并不冲突），尽管如此，VDSO 可阻止
+某些通过常量高效跳转到那些代码段的汇编技巧。且由于那些代码段在返回用户
+代码前仅使用少量的代码周期，则一个 VDSO 间接远程调用将会在这些简单的
+操作上增加一个可测量的开销。
+
+在对那些拥有原生支持的新型处理器进行代码优化时，仅在已为其他操作使用
+了类似的新增指令，而导致二进制结果已与早期 ARM 处理器不兼容的情况下，
+用户空间才应绕过这些辅助代码，并在内联函数中实现这些操作（无论是通过
+编译器在代码中直接放置，还是作为库函数调用实现的一部分）。也就是说，
+如果你编译的代码不会为了其他目的使用新指令，则不要仅为了避免使用这些
+内核辅助代码，导致二进制程序无法在早期处理器上运行。
+
+新的辅助代码可能随着时间的推移而增加，所以新内核中的某些辅助代码在旧
+内核中可能不存在。因此，程序必须在对任何辅助代码调用假设是安全之前，
+检测 __kuser_helper_version 的值（见下文）。理想情况下，这种检测应该
+只在进程启动时执行一次；如果内核版本不支持所需辅助代码，则该进程可尽早
+中止执行。
+
+kuser_helper_version
+--------------------
+
+位置: 0xffff0ffc
+
+参考声明:
+
+ extern int32_t __kuser_helper_version;
+
+定义:
+
+ 这个区域包含了当前运行内核实现的辅助代码版本号。用户空间可以通过读
+ 取此版本号以确定特定的辅助代码是否存在。
+
+使用范例:
+
+#define __kuser_helper_version (*(int32_t *)0xffff0ffc)
+
+void check_kuser_version(void)
+{
+ if (__kuser_helper_version < 2) {
+ fprintf(stderr, "can't do atomic operations, kernel too old\n");
+ abort();
+ }
+}
+
+注意:
+
+ 用户空间可以假设这个域的值不会在任何单个进程的生存期内改变。也就
+ 是说，这个域可以仅在库的初始化阶段或进程启动阶段读取一次。
+
+kuser_get_tls
+-------------
+
+位置: 0xffff0fe0
+
+参考原型:
+
+ void * __kuser_get_tls(void);
+
+输入:
+
+ lr = 返回地址
+
+输出:
+
+ r0 = TLS 值
+
+被篡改的寄存器:
+
+ 无
+
+定义:
+
+ 获取之前通过 __ARM_NR_set_tls 系统调用设置的 TLS 值。
+
+使用范例:
+
+typedef void * (__kuser_get_tls_t)(void);
+#define __kuser_get_tls (*(__kuser_get_tls_t *)0xffff0fe0)
+
+void foo()
+{
+ void *tls = __kuser_get_tls();
+ printf("TLS = %p\n", tls);
+}
+
+注意:
+
+ - 仅在 __kuser_helper_version >= 1 时，此辅助代码存在
+ （从内核版本 2.6.12 开始）。
+
+kuser_cmpxchg
+-------------
+
+位置: 0xffff0fc0
+
+参考原型:
+
+ int __kuser_cmpxchg(int32_t oldval, int32_t newval, volatile int32_t *ptr);
+
+输入:
+
+ r0 = oldval
+ r1 = newval
+ r2 = ptr
+ lr = 返回地址
+
+输出:
+
+ r0 = 成功代码 (零或非零)
+ C flag = 如果 r0 == 0 则置 1，如果 r0 != 0 则清零。
+
+被篡改的寄存器:
+
+ r3, ip, flags
+
+定义:
+
+ 仅在 *ptr 为 oldval 时原子保存 newval 于 *ptr 中。
+ 如果 *ptr 被改变，则返回值为零，否则为非零值。
+ 如果 *ptr 被改变，则 C flag 也会被置 1，以实现调用代码中的汇编
+ 优化。
+
+使用范例:
+
+typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr);
+#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0xffff0fc0)
+
+int atomic_add(volatile int *ptr, int val)
+{
+ int old, new;
+
+ do {
+ old = *ptr;
+ new = old + val;
+ } while(__kuser_cmpxchg(old, new, ptr));
+
+ return new;
+}
+
+注意:
+
+ - 这个例程已根据需要包含了内存屏障。
+
+ - 仅在 __kuser_helper_version >= 2 时，此辅助代码存在
+ （从内核版本 2.6.12 开始）。
+
+kuser_memory_barrier
+--------------------
+
+位置: 0xffff0fa0
+
+参考原型:
+
+ void __kuser_memory_barrier(void);
+
+输入:
+
+ lr = 返回地址
+
+输出:
+
+ 无
+
+被篡改的寄存器:
+
+ 无
+
+定义:
+
+ 应用于任何需要内存屏障以防止手动数据修改带来的一致性问题，以及
+ __kuser_cmpxchg 中。
+
+使用范例:
+
+typedef void (__kuser_dmb_t)(void);
+#define __kuser_dmb (*(__kuser_dmb_t *)0xffff0fa0)
+
+注意:
+
+ - 仅在 __kuser_helper_version >= 3 时，此辅助代码存在
+ （从内核版本 2.6.15 开始）。
+
+kuser_cmpxchg64
+---------------
+
+位置: 0xffff0f60
+
+参考原型:
+
+ int __kuser_cmpxchg64(const int64_t *oldval,
+ const int64_t *newval,
+ volatile int64_t *ptr);
+
+输入:
+
+ r0 = 指向 oldval
+ r1 = 指向 newval
+ r2 = 指向目标值
+ lr = 返回地址
+
+输出:
+
+ r0 = 成功代码 (零或非零)
+ C flag = 如果 r0 == 0 则置 1，如果 r0 != 0 则清零。
+
+被篡改的寄存器:
+
+ r3, lr, flags
+
+定义:
+
+ 仅在 *ptr 等于 *oldval 指向的 64 位值时，原子保存 *newval
+ 指向的 64 位值于 *ptr 中。如果 *ptr 被改变，则返回值为零，
+ 否则为非零值。
+
+ 如果 *ptr 被改变，则 C flag 也会被置 1，以实现调用代码中的汇编
+ 优化。
+
+使用范例:
+
+typedef int (__kuser_cmpxchg64_t)(const int64_t *oldval,
+ const int64_t *newval,
+ volatile int64_t *ptr);
+#define __kuser_cmpxchg64 (*(__kuser_cmpxchg64_t *)0xffff0f60)
+
+int64_t atomic_add64(volatile int64_t *ptr, int64_t val)
+{
+ int64_t old, new;
+
+ do {
+ old = *ptr;
+ new = old + val;
+ } while(__kuser_cmpxchg64(&old, &new, ptr));
+
+ return new;
+}
+
+注意:
+
+ - 这个例程已根据需要包含了内存屏障。
+
+ - 由于这个过程的代码长度（此辅助代码跨越 2 个常规的 kuser “槽”），
+ 因此 0xffff0f80 不被作为有效的入口点。
+
+ - 仅在 __kuser_helper_version >= 5 时，此辅助代码存在
+ （从内核版本 3.1 开始）。
diff --git a/Documentation/translations/zh_CN/arch/arm64/amu.rst b/Documentation/translations/zh_CN/arch/arm64/amu.rst
new file mode 100644
index 0000000..f8e09fd
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/amu.rst
@@ -0,0 +1,100 @@
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/arch/arm64/amu.rst <amu_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+
+==================================
+AArch64 Linux 中扩展的活动监控单元
+==================================
+
+作者: Ionela Voinescu <ionela.voinescu@arm.com>
+
+日期: 2019-09-10
+
+本文档简要描述了 AArch64 Linux 支持的活动监控单元的规范。
+
+
+架构总述
+--------
+
+活动监控是 ARMv8.4 CPU 架构引入的一个可选扩展特性。
+
+活动监控单元(在每个 CPU 中实现)为系统管理提供了性能计数器。既可以通
+过系统寄存器的方式访问计数器，同时也支持外部内存映射的方式访问计数器。
+
+AMUv1 架构实现了一个由4个固定的64位事件计数器组成的计数器组。
+
+ - CPU 周期计数器：同 CPU 的频率增长
+ - 常量计数器：同固定的系统时钟频率增长
+ - 淘汰指令计数器: 同每次架构指令执行增长
+ - 内存停顿周期计数器：计算由在时钟域内的最后一级缓存中未命中而引起
+ 的指令调度停顿周期数
+
+当处于 WFI 或者 WFE 状态时，计数器不会增长。
+
+AMU 架构提供了一个高达16位的事件计数器空间，未来新的 AMU 版本中可能
+用它来实现新增的事件计数器。
+
+另外，AMUv1 实现了一个多达16个64位辅助事件计数器的计数器组。
+
+冷复位时所有的计数器会清零。
+
+
+基本支持
+--------
+
+内核可以安全地运行在支持 AMU 和不支持 AMU 的 CPU 组合中。
+因此，当配置 CONFIG_ARM64_AMU_EXTN 后我们无条件使能后续
+(secondary or hotplugged) CPU 检测和使用这个特性。
+
+当在 CPU 上检测到该特性时，我们会标记为特性可用但是不能保证计数器的功能，
+仅表明有扩展属性。
+
+固件(代码运行在高异常级别，例如 arm-tf )需支持以下功能：
+
+ - 提供低异常级别(EL2 和 EL1)访问 AMU 寄存器的能力。
+ - 使能计数器。如果未使能，它的值应为 0。
+ - 在从电源关闭状态启动 CPU 前或后保存或者恢复计数器。
+
+当使用使能了该特性的内核启动但固件损坏时，访问计数器寄存器可能会遭遇
+panic 或者死锁。即使未发现这些症状，计数器寄存器返回的数据结果并不一
+定能反映真实情况。通常，计数器会返回 0，表明他们未被使能。
+
+如果固件没有提供适当的支持最好关闭 CONFIG_ARM64_AMU_EXTN。
+值得注意的是，出于安全原因，不要绕过 AMUSERRENR_EL0 设置而捕获从
+EL0(用户空间) 访问 EL1(内核空间)。 因此，固件应该确保访问 AMU寄存器
+不会困在 EL2或EL3。
+
+AMUv1 的固定计数器可以通过如下系统寄存器访问：
+
+ - SYS_AMEVCNTR0_CORE_EL0
+ - SYS_AMEVCNTR0_CONST_EL0
+ - SYS_AMEVCNTR0_INST_RET_EL0
+ - SYS_AMEVCNTR0_MEM_STALL_EL0
+
+特定辅助计数器可以通过 SYS_AMEVCNTR1_EL0(n) 访问，其中n介于0到15。
+
+详细信息定义在目录：arch/arm64/include/asm/sysreg.h。
+
+
+用户空间访问
+------------
+
+由于以下原因，当前禁止从用户空间访问 AMU 的寄存器：
+
+ - 安全因数：可能会暴露处于安全模式执行的代码信息。
+ - 意愿：AMU 是用于系统管理的。
+
+同样，该功能对用户空间不可见。
+
+
+虚拟化
+------
+
+由于以下原因，当前禁止从 KVM 客户端的用户空间(EL0)和内核空间(EL1)
+访问 AMU 的寄存器：
+
+ - 安全因数：可能会暴露给其他客户端或主机端执行的代码信息。
+
+任何试图访问 AMU 寄存器的行为都会触发一个注册在客户端的未定义异常。
diff --git a/Documentation/translations/zh_CN/arch/arm64/booting.txt b/Documentation/translations/zh_CN/arch/arm64/booting.txt
new file mode 100644
index 0000000..630eb32
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/booting.txt
@@ -0,0 +1,246 @@
+Chinese translated version of Documentation/arch/arm64/booting.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+M: Will Deacon <will.deacon@arm.com>
+zh_CN: Fu Wei <wefu@redhat.com>
+C: 55f058e7574c3615dea4615573a19bdb258696c6
+---------------------------------------------------------------------
+Documentation/arch/arm64/booting.rst 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+
+英文版维护者： Will Deacon <will.deacon@arm.com>
+中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
+本文翻译提交时的 Git 检出点为： 55f058e7574c3615dea4615573a19bdb258696c6
+
+以下为正文
+---------------------------------------------------------------------
+ 启动 AArch64 Linux
+ ==================
+
+作者: Will Deacon <will.deacon@arm.com>
+日期: 2012 年 09 月 07 日
+
+本文档基于 Russell King 的 ARM 启动文档，且适用于所有公开发布的
+AArch64 Linux 内核代码。
+
+AArch64 异常模型由多个异常级（EL0 - EL3）组成，对于 EL0 和 EL1 异常级
+有对应的安全和非安全模式。EL2 是系统管理级，且仅存在于非安全模式下。
+EL3 是最高特权级，且仅存在于安全模式下。
+
+基于本文档的目的，我们将简单地使用‘引导装载程序’（‘boot loader’）
+这个术语来定义在将控制权交给 Linux 内核前 CPU 上执行的所有软件。
+这可能包含安全监控和系统管理代码，或者它可能只是一些用于准备最小启动
+环境的指令。
+
+基本上，引导装载程序（至少）应实现以下操作：
+
+1、设置和初始化 RAM
+2、设置设备树数据
+3、解压内核映像
+4、调用内核映像
+
+
+1、设置和初始化 RAM
+-----------------
+
+必要性: 强制
+
+引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。
+这个操作的执行方式因设备而异。（它可能使用内部算法来自动定位和计算所有
+RAM，或可能使用对这个设备已知的 RAM 信息，还可能是引导装载程序设计者
+想到的任何合适的方法。）
+
+
+2、设置设备树数据
+---------------
+
+必要性: 强制
+
+设备树数据块（dtb）必须 8 字节对齐，且大小不能超过 2MB。由于设备树
+数据块将在使能缓存的情况下以 2MB 粒度被映射，故其不能被置于必须以特定
+属性映射的2M区域内。
+
+注： v4.2 之前的版本同时要求设备树数据块被置于从内核映像以下
+text_offset 字节处算起第一个 512MB 内。
+
+3、解压内核映像
+-------------
+
+必要性: 可选
+
+AArch64 内核当前没有提供自解压代码，因此如果使用了压缩内核映像文件
+（比如 Image.gz），则需要通过引导装载程序（使用 gzip 等）来进行解压。
+若引导装载程序没有实现这个功能，就要使用非压缩内核映像文件。
+
+
+4、调用内核映像
+-------------
+
+必要性: 强制
+
+已解压的内核映像包含一个 64 字节的头，内容如下：
+
+ u32 code0; /* 可执行代码 */
+ u32 code1; /* 可执行代码 */
+ u64 text_offset; /* 映像装载偏移，小端模式 */
+ u64 image_size; /* 映像实际大小, 小端模式 */
+ u64 flags; /* 内核旗标, 小端模式 *
+ u64 res2 = 0; /* 保留 */
+ u64 res3 = 0; /* 保留 */
+ u64 res4 = 0; /* 保留 */
+ u32 magic = 0x644d5241; /* 魔数, 小端, "ARM\x64" */
+ u32 res5; /* 保留 （用于 PE COFF 偏移） */
+
+
+映像头注释：
+
+- 自 v3.17 起，除非另有说明，所有域都是小端模式。
+
+- code0/code1 负责跳转到 stext.
+
+- 当通过 EFI 启动时， 最初 code0/code1 被跳过。
+ res5 是到 PE 文件头的偏移，而 PE 文件头含有 EFI 的启动入口点
+ （efi_stub_entry）。当 stub 代码完成了它的使命，它会跳转到 code0
+ 继续正常的启动流程。
+
+- v3.17 之前，未明确指定 text_offset 的字节序。此时，image_size 为零，
+ 且 text_offset 依照内核字节序为 0x80000。
+ 当 image_size 非零，text_offset 为小端模式且是有效值，应被引导加载
+ 程序使用。当 image_size 为零，text_offset 可假定为 0x80000。
+
+- flags 域 (v3.17 引入) 为 64 位小端模式，其编码如下：
+ 位 0: 内核字节序。 1 表示大端模式，0 表示小端模式。
+ 位 1-2: 内核页大小。
+ 0 - 未指定。
+ 1 - 4K
+ 2 - 16K
+ 3 - 64K
+ 位 3: 内核物理位置
+ 0 - 2MB 对齐基址应尽量靠近内存起始处，因为
+ 其基址以下的内存无法通过线性映射访问
+ 1 - 2MB 对齐基址可以在物理内存的任意位置
+ 位 4-63: 保留。
+
+- 当 image_size 为零时，引导装载程序应试图在内核映像末尾之后尽可能
+ 多地保留空闲内存供内核直接使用。对内存空间的需求量因所选定的内核
+ 特性而异, 并无实际限制。
+
+内核映像必须被放置在任意一个可用系统内存 2MB 对齐基址的 text_offset
+字节处，并从该处被调用。2MB 对齐基址和内核映像起始地址之间的区域对于
+内核来说没有特殊意义，且可能被用于其他目的。
+从映像起始地址算起，最少必须准备 image_size 字节的空闲内存供内核使用。
+注： v4.6 之前的版本无法使用内核映像物理偏移以下的内存，所以当时建议
+将映像尽量放置在靠近系统内存起始的地方。
+
+任何提供给内核的内存（甚至在映像起始地址之前），若未从内核中标记为保留
+(如在设备树（dtb）的 memreserve 区域），都将被认为对内核是可用。
+
+在跳转入内核前，必须符合以下状态：
+
+- 停止所有 DMA 设备，这样内存数据就不会因为虚假网络包或磁盘数据而
+ 被破坏。这可能可以节省你许多的调试时间。
+
+- 主 CPU 通用寄存器设置
+ x0 = 系统 RAM 中设备树数据块（dtb）的物理地址。
+ x1 = 0 (保留，将来可能使用)
+ x2 = 0 (保留，将来可能使用)
+ x3 = 0 (保留，将来可能使用)
+
+- CPU 模式
+ 所有形式的中断必须在 PSTATE.DAIF 中被屏蔽（Debug、SError、IRQ
+ 和 FIQ）。
+ CPU 必须处于 EL2（推荐，可访问虚拟化扩展）或非安全 EL1 模式下。
+
+- 高速缓存、MMU
+ MMU 必须关闭。
+ 指令缓存开启或关闭皆可。
+ 已载入的内核映像的相应内存区必须被清理，以达到缓存一致性点（PoC）。
+ 当存在系统缓存或其他使能缓存的一致性主控器时，通常需使用虚拟地址
+ 维护其缓存，而非 set/way 操作。
+ 遵从通过虚拟地址操作维护构架缓存的系统缓存必须被配置，并可以被使能。
+ 而不通过虚拟地址操作维护构架缓存的系统缓存（不推荐），必须被配置且
+ 禁用。
+
+ *译者注：对于 PoC 以及缓存相关内容，请参考 ARMv8 构架参考手册
+ ARM DDI 0487A
+
+- 架构计时器
+ CNTFRQ 必须设定为计时器的频率，且 CNTVOFF 必须设定为对所有 CPU
+ 都一致的值。如果在 EL1 模式下进入内核，则 CNTHCTL_EL2 中的
+ EL1PCTEN (bit 0) 必须置位。
+
+- 一致性
+ 通过内核启动的所有 CPU 在内核入口地址上必须处于相同的一致性域中。
+ 这可能要根据具体实现来定义初始化过程，以使能每个CPU上对维护操作的
+ 接收。
+
+- 系统寄存器
+ 在进入内核映像的异常级中，所有构架中可写的系统寄存器必须通过软件
+ 在一个更高的异常级别下初始化，以防止在 未知 状态下运行。
+
+ 对于拥有 GICv3 中断控制器并以 v3 模式运行的系统：
+ - 如果 EL3 存在：
+ ICC_SRE_EL3.Enable (位 3) 必须初始化为 0b1。
+ ICC_SRE_EL3.SRE (位 0) 必须初始化为 0b1。
+ - 若内核运行在 EL1：
+ ICC_SRE_EL2.Enable (位 3) 必须初始化为 0b1。
+ ICC_SRE_EL2.SRE (位 0) 必须初始化为 0b1。
+ - 设备树（DT）或 ACPI 表必须描述一个 GICv3 中断控制器。
+
+ 对于拥有 GICv3 中断控制器并以兼容（v2）模式运行的系统：
+ - 如果 EL3 存在：
+ ICC_SRE_EL3.SRE (位 0) 必须初始化为 0b0。
+ - 若内核运行在 EL1：
+ ICC_SRE_EL2.SRE (位 0) 必须初始化为 0b0。
+ - 设备树（DT）或 ACPI 表必须描述一个 GICv2 中断控制器。
+
+以上对于 CPU 模式、高速缓存、MMU、架构计时器、一致性、系统寄存器的
+必要条件描述适用于所有 CPU。所有 CPU 必须在同一异常级别跳入内核。
+
+引导装载程序必须在每个 CPU 处于以下状态时跳入内核入口：
+
+- 主 CPU 必须直接跳入内核映像的第一条指令。通过此 CPU 传递的设备树
+ 数据块必须在每个 CPU 节点中包含一个 ‘enable-method’ 属性，所
+ 支持的 enable-method 请见下文。
+
+ 引导装载程序必须生成这些设备树属性，并在跳入内核入口之前将其插入
+ 数据块。
+
+- enable-method 为 “spin-table” 的 CPU 必须在它们的 CPU
+ 节点中包含一个 ‘cpu-release-addr’ 属性。这个属性标识了一个
+ 64 位自然对齐且初始化为零的内存位置。
+
+ 这些 CPU 必须在内存保留区（通过设备树中的 /memreserve/ 域传递
+ 给内核）中自旋于内核之外，轮询它们的 cpu-release-addr 位置（必须
+ 包含在保留区中）。可通过插入 wfe 指令来降低忙循环开销，而主 CPU 将
+ 发出 sev 指令。当对 cpu-release-addr 所指位置的读取操作返回非零值
+ 时，CPU 必须跳入此值所指向的地址。此值为一个单独的 64 位小端值，
+ 因此 CPU 须在跳转前将所读取的值转换为其本身的端模式。
+
+- enable-method 为 “psci” 的 CPU 保持在内核外（比如，在
+ memory 节点中描述为内核空间的内存区外，或在通过设备树 /memreserve/
+ 域中描述为内核保留区的空间中）。内核将会发起在 ARM 文档（编号
+ ARM DEN 0022A：用于 ARM 上的电源状态协调接口系统软件）中描述的
+ CPU_ON 调用来将 CPU 带入内核。
+
+ *译者注: ARM DEN 0022A 已更新到 ARM DEN 0022C。
+
+ 设备树必须包含一个 ‘psci’ 节点，请参考以下文档：
+ Documentation/devicetree/bindings/arm/psci.yaml
+
+
+- 辅助 CPU 通用寄存器设置
+ x0 = 0 (保留，将来可能使用)
+ x1 = 0 (保留，将来可能使用)
+ x2 = 0 (保留，将来可能使用)
+ x3 = 0 (保留，将来可能使用)
diff --git a/Documentation/translations/zh_CN/arch/arm64/elf_hwcaps.rst b/Documentation/translations/zh_CN/arch/arm64/elf_hwcaps.rst
new file mode 100644
index 0000000..f60ac15
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/elf_hwcaps.rst
@@ -0,0 +1,240 @@
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/arch/arm64/elf_hwcaps.rst <elf_hwcaps_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+
+================
+ARM64 ELF hwcaps
+================
+
+这篇文档描述了 arm64 ELF hwcaps 的用法和语义。
+
+
+1. 简介
+-------
+
+有些硬件或软件功能仅在某些 CPU 实现上和/或在具体某个内核配置上可用，但
+对于处于 EL0 的用户空间代码没有可用的架构发现机制。内核通过在辅助向量表
+公开一组称为 hwcaps 的标志而把这些功能暴露给用户空间。
+
+用户空间软件可以通过获取辅助向量的 AT_HWCAP 或 AT_HWCAP2 条目来测试功能，
+并测试是否设置了相关标志，例如::
+
+ bool floating_point_is_present(void)
+ {
+ unsigned long hwcaps = getauxval(AT_HWCAP);
+ if (hwcaps & HWCAP_FP)
+ return true;
+
+ return false;
+ }
+
+如果软件依赖于 hwcap 描述的功能，在尝试使用该功能前则应检查相关的 hwcap
+标志以验证该功能是否存在。
+
+不能通过其他方式探查这些功能。当一个功能不可用时，尝试使用它可能导致不可
+预测的行为，并且无法保证能确切的知道该功能不可用，例如 SIGILL。
+
+
+2. Hwcaps 的说明
+----------------
+
+大多数 hwcaps 旨在说明通过架构 ID 寄存器(处于 EL0 的用户空间代码无法访问)
+描述的功能的存在。这些 hwcap 通过 ID 寄存器字段定义，并且应根据 ARM 体系
+结构参考手册（ARM ARM）中定义的字段来解释说明。
+
+这些 hwcaps 以下面的形式描述::
+
+ idreg.field == val 表示有某个功能。
+
+当 idreg.field 中有 val 时，hwcaps 表示 ARM ARM 定义的功能是有效的，但是
+并不是说要完全和 val 相等，也不是说 idreg.field 描述的其他功能就是缺失的。
+
+其他 hwcaps 可能表明无法仅由 ID 寄存器描述的功能的存在。这些 hwcaps 可能
+没有被 ID 寄存器描述，需要参考其他文档。
+
+
+3. AT_HWCAP 中揭示的 hwcaps
+---------------------------
+
+HWCAP_FP
+ ID_AA64PFR0_EL1.FP == 0b0000 表示有此功能。
+
+HWCAP_ASIMD
+ ID_AA64PFR0_EL1.AdvSIMD == 0b0000 表示有此功能。
+
+HWCAP_EVTSTRM
+ 通用计时器频率配置为大约100KHz以生成事件。
+
+HWCAP_AES
+ ID_AA64ISAR0_EL1.AES == 0b0001 表示有此功能。
+
+HWCAP_PMULL
+ ID_AA64ISAR0_EL1.AES == 0b0010 表示有此功能。
+
+HWCAP_SHA1
+ ID_AA64ISAR0_EL1.SHA1 == 0b0001 表示有此功能。
+
+HWCAP_SHA2
+ ID_AA64ISAR0_EL1.SHA2 == 0b0001 表示有此功能。
+
+HWCAP_CRC32
+ ID_AA64ISAR0_EL1.CRC32 == 0b0001 表示有此功能。
+
+HWCAP_ATOMICS
+ ID_AA64ISAR0_EL1.Atomic == 0b0010 表示有此功能。
+
+HWCAP_FPHP
+ ID_AA64PFR0_EL1.FP == 0b0001 表示有此功能。
+
+HWCAP_ASIMDHP
+ ID_AA64PFR0_EL1.AdvSIMD == 0b0001 表示有此功能。
+
+HWCAP_CPUID
+ 根据 Documentation/arch/arm64/cpu-feature-registers.rst 描述，EL0 可以访问
+ 某些 ID 寄存器。
+
+ 这些 ID 寄存器可能表示功能的可用性。
+
+HWCAP_ASIMDRDM
+ ID_AA64ISAR0_EL1.RDM == 0b0001 表示有此功能。
+
+HWCAP_JSCVT
+ ID_AA64ISAR1_EL1.JSCVT == 0b0001 表示有此功能。
+
+HWCAP_FCMA
+ ID_AA64ISAR1_EL1.FCMA == 0b0001 表示有此功能。
+
+HWCAP_LRCPC
+ ID_AA64ISAR1_EL1.LRCPC == 0b0001 表示有此功能。
+
+HWCAP_DCPOP
+ ID_AA64ISAR1_EL1.DPB == 0b0001 表示有此功能。
+
+HWCAP_SHA3
+ ID_AA64ISAR0_EL1.SHA3 == 0b0001 表示有此功能。
+
+HWCAP_SM3
+ ID_AA64ISAR0_EL1.SM3 == 0b0001 表示有此功能。
+
+HWCAP_SM4
+ ID_AA64ISAR0_EL1.SM4 == 0b0001 表示有此功能。
+
+HWCAP_ASIMDDP
+ ID_AA64ISAR0_EL1.DP == 0b0001 表示有此功能。
+
+HWCAP_SHA512
+ ID_AA64ISAR0_EL1.SHA2 == 0b0010 表示有此功能。
+
+HWCAP_SVE
+ ID_AA64PFR0_EL1.SVE == 0b0001 表示有此功能。
+
+HWCAP_ASIMDFHM
+ ID_AA64ISAR0_EL1.FHM == 0b0001 表示有此功能。
+
+HWCAP_DIT
+ ID_AA64PFR0_EL1.DIT == 0b0001 表示有此功能。
+
+HWCAP_USCAT
+ ID_AA64MMFR2_EL1.AT == 0b0001 表示有此功能。
+
+HWCAP_ILRCPC
+ ID_AA64ISAR1_EL1.LRCPC == 0b0010 表示有此功能。
+
+HWCAP_FLAGM
+ ID_AA64ISAR0_EL1.TS == 0b0001 表示有此功能。
+
+HWCAP_SSBS
+ ID_AA64PFR1_EL1.SSBS == 0b0010 表示有此功能。
+
+HWCAP_SB
+ ID_AA64ISAR1_EL1.SB == 0b0001 表示有此功能。
+
+HWCAP_PACA
+ 如 Documentation/arch/arm64/pointer-authentication.rst 所描述，
+ ID_AA64ISAR1_EL1.APA == 0b0001 或 ID_AA64ISAR1_EL1.API == 0b0001
+ 表示有此功能。
+
+HWCAP_PACG
+ 如 Documentation/arch/arm64/pointer-authentication.rst 所描述，
+ ID_AA64ISAR1_EL1.GPA == 0b0001 或 ID_AA64ISAR1_EL1.GPI == 0b0001
+ 表示有此功能。
+
+HWCAP2_DCPODP
+
+ ID_AA64ISAR1_EL1.DPB == 0b0010 表示有此功能。
+
+HWCAP2_SVE2
+
+ ID_AA64ZFR0_EL1.SVEVer == 0b0001 表示有此功能。
+
+HWCAP2_SVEAES
+
+ ID_AA64ZFR0_EL1.AES == 0b0001 表示有此功能。
+
+HWCAP2_SVEPMULL
+
+ ID_AA64ZFR0_EL1.AES == 0b0010 表示有此功能。
+
+HWCAP2_SVEBITPERM
+
+ ID_AA64ZFR0_EL1.BitPerm == 0b0001 表示有此功能。
+
+HWCAP2_SVESHA3
+
+ ID_AA64ZFR0_EL1.SHA3 == 0b0001 表示有此功能。
+
+HWCAP2_SVESM4
+
+ ID_AA64ZFR0_EL1.SM4 == 0b0001 表示有此功能。
+
+HWCAP2_FLAGM2
+
+ ID_AA64ISAR0_EL1.TS == 0b0010 表示有此功能。
+
+HWCAP2_FRINT
+
+ ID_AA64ISAR1_EL1.FRINTTS == 0b0001 表示有此功能。
+
+HWCAP2_SVEI8MM
+
+ ID_AA64ZFR0_EL1.I8MM == 0b0001 表示有此功能。
+
+HWCAP2_SVEF32MM
+
+ ID_AA64ZFR0_EL1.F32MM == 0b0001 表示有此功能。
+
+HWCAP2_SVEF64MM
+
+ ID_AA64ZFR0_EL1.F64MM == 0b0001 表示有此功能。
+
+HWCAP2_SVEBF16
+
+ ID_AA64ZFR0_EL1.BF16 == 0b0001 表示有此功能。
+
+HWCAP2_I8MM
+
+ ID_AA64ISAR1_EL1.I8MM == 0b0001 表示有此功能。
+
+HWCAP2_BF16
+
+ ID_AA64ISAR1_EL1.BF16 == 0b0001 表示有此功能。
+
+HWCAP2_DGH
+
+ ID_AA64ISAR1_EL1.DGH == 0b0001 表示有此功能。
+
+HWCAP2_RNG
+
+ ID_AA64ISAR0_EL1.RNDR == 0b0001 表示有此功能。
+
+HWCAP2_BTI
+
+ ID_AA64PFR0_EL1.BT == 0b0001 表示有此功能。
+
+
+4. 未使用的 AT_HWCAP 位
+-----------------------
+
+为了与用户空间交互，内核保证 AT_HWCAP 的第62、63位将始终返回0。
diff --git a/Documentation/translations/zh_CN/arch/arm64/hugetlbpage.rst b/Documentation/translations/zh_CN/arch/arm64/hugetlbpage.rst
new file mode 100644
index 0000000..8079ead
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/hugetlbpage.rst
@@ -0,0 +1,45 @@
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/arch/arm64/hugetlbpage.rst <hugetlbpage_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+
+=====================
+ARM64中的 HugeTLBpage
+=====================
+
+大页依靠有效利用 TLBs 来提高地址翻译的性能。这取决于以下
+两点 -
+
+ - 大页的大小
+ - TLBs 支持的条目大小
+
+ARM64 接口支持2种大页方式。
+
+1) pud/pmd 级别的块映射
+-----------------------
+
+这是常规大页，他们的 pmd 或 pud 页面表条目指向一个内存块。
+不管 TLB 中支持的条目大小如何，块映射可以减少翻译大页地址
+所需遍历的页表深度。
+
+2) 使用连续位
+-------------
+
+架构中转换页表条目(D4.5.3, ARM DDI 0487C.a)中提供一个连续
+位告诉 MMU 这个条目是一个连续条目集的一员，它可以被缓存在单
+个 TLB 条目中。
+
+在 Linux 中连续位用来增加 pmd 和 pte(最后一级)级别映射的大
+小。受支持的连续页表条目数量因页面大小和页表级别而异。
+
+
+支持以下大页尺寸配置 -
+
+ ====== ======== ==== ======== ===
+ - CONT PTE PMD CONT PMD PUD
+ ====== ======== ==== ======== ===
+ 4K: 64K 2M 32M 1G
+ 16K: 2M 32M 1G
+ 64K: 2M 512M 16G
+ ====== ======== ==== ======== ===
diff --git a/Documentation/translations/zh_CN/arch/arm64/index.rst b/Documentation/translations/zh_CN/arch/arm64/index.rst
new file mode 100644
index 0000000..e12b9f6
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/index.rst
@@ -0,0 +1,19 @@
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/arch/arm64/index.rst <arm64_index>`
+:Translator: Bailu Lin <bailu.lin@vivo.com>
+
+.. _cn_arm64_index:
+
+
+==========
+ARM64 架构
+==========
+
+.. toctree::
+ :maxdepth: 2
+
+ amu
+ hugetlbpage
+ perf
+ elf_hwcaps
diff --git a/Documentation/translations/zh_CN/arch/arm64/legacy_instructions.txt b/Documentation/translations/zh_CN/arch/arm64/legacy_instructions.txt
new file mode 100644
index 0000000..e469fcc
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/legacy_instructions.txt
@@ -0,0 +1,72 @@
+Chinese translated version of Documentation/arch/arm64/legacy_instructions.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Punit Agrawal <punit.agrawal@arm.com>
+ Suzuki K. Poulose <suzuki.poulose@arm.com>
+Chinese maintainer: Fu Wei <wefu@redhat.com>
+---------------------------------------------------------------------
+Documentation/arch/arm64/legacy_instructions.rst 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+
+本文翻译提交时的 Git 检出点为： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
+
+英文版维护者： Punit Agrawal <punit.agrawal@arm.com>
+ Suzuki K. Poulose <suzuki.poulose@arm.com>
+中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
+
+以下为正文
+---------------------------------------------------------------------
+Linux 内核在 arm64 上的移植提供了一个基础框架，以支持构架中正在被淘汰或已废弃指令的模拟执行。
+这个基础框架的代码使用未定义指令钩子（hooks）来支持模拟。如果指令存在，它也允许在硬件中启用该指令。
+
+模拟模式可通过写 sysctl 节点（/proc/sys/abi）来控制。
+不同的执行方式及 sysctl 节点的相应值，解释如下：
+
+* Undef（未定义）
+ 值： 0
+ 产生未定义指令终止异常。它是那些构架中已废弃的指令，如 SWP，的默认处理方式。
+
+* Emulate（模拟）
+ 值： 1
+ 使用软件模拟方式。为解决软件迁移问题，这种模拟指令模式的使用是被跟踪的，并会发出速率限制警告。
+ 它是那些构架中正在被淘汰的指令，如 CP15 barriers（隔离指令），的默认处理方式。
+
+* Hardware Execution（硬件执行）
+ 值： 2
+ 虽然标记为正在被淘汰，但一些实现可能提供硬件执行这些指令的使能/禁用操作。
+ 使用硬件执行一般会有更好的性能，但将无法收集运行时对正被淘汰指令的使用统计数据。
+
+默认执行模式依赖于指令在构架中状态。正在被淘汰的指令应该以模拟（Emulate）作为默认模式，
+而已废弃的指令必须默认使用未定义（Undef）模式
+
+注意：指令模拟可能无法应对所有情况。更多详情请参考单独的指令注释。
+
+受支持的遗留指令
+-------------
+* SWP{B}
+节点: /proc/sys/abi/swp
+状态: 已废弃
+默认执行方式: Undef (0)
+
+* CP15 Barriers
+节点: /proc/sys/abi/cp15_barrier
+状态: 正被淘汰，不推荐使用
+默认执行方式: Emulate (1)
+
+* SETEND
+节点: /proc/sys/abi/setend
+状态: 正被淘汰，不推荐使用
+默认执行方式: Emulate (1)*
+注：为了使能这个特性，系统中的所有 CPU 必须在 EL0 支持混合字节序。
+如果一个新的 CPU （不支持混合字节序） 在使能这个特性后被热插入系统，
+在应用中可能会出现不可预期的结果。
diff --git a/Documentation/translations/zh_CN/arch/arm64/memory.txt b/Documentation/translations/zh_CN/arch/arm64/memory.txt
new file mode 100644
index 0000000..c6962e9
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/memory.txt
@@ -0,0 +1,114 @@
+Chinese translated version of Documentation/arch/arm64/memory.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Catalin Marinas <catalin.marinas@arm.com>
+Chinese maintainer: Fu Wei <wefu@redhat.com>
+---------------------------------------------------------------------
+Documentation/arch/arm64/memory.rst 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+
+本文翻译提交时的 Git 检出点为： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
+
+英文版维护者： Catalin Marinas <catalin.marinas@arm.com>
+中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
+
+以下为正文
+---------------------------------------------------------------------
+ Linux 在 AArch64 中的内存布局
+ ===========================
+
+作者: Catalin Marinas <catalin.marinas@arm.com>
+
+本文档描述 AArch64 Linux 内核所使用的虚拟内存布局。此构架可以实现
+页大小为 4KB 的 4 级转换表和页大小为 64KB 的 3 级转换表。
+
+AArch64 Linux 使用 3 级或 4 级转换表，其页大小配置为 4KB，对于用户和内核
+分别都有 39-bit (512GB) 或 48-bit (256TB) 的虚拟地址空间。
+对于页大小为 64KB的配置，仅使用 2 级转换表，有 42-bit (4TB) 的虚拟地址空间，但内存布局相同。
+
+用户地址空间的 63:48 位为 0，而内核地址空间的相应位为 1。TTBRx 的
+选择由虚拟地址的 63 位给出。swapper_pg_dir 仅包含内核（全局）映射，
+而用户 pgd 仅包含用户（非全局）映射。swapper_pg_dir 地址被写入
+TTBR1 中，且从不写入 TTBR0。
+
+
+AArch64 Linux 在页大小为 4KB，并使用 3 级转换表时的内存布局：
+
+起始地址 结束地址 大小 用途
+-----------------------------------------------------------------------
+0000000000000000 0000007fffffffff 512GB 用户空间
+ffffff8000000000 ffffffffffffffff 512GB 内核空间
+
+
+AArch64 Linux 在页大小为 4KB，并使用 4 级转换表时的内存布局：
+
+起始地址 结束地址 大小 用途
+-----------------------------------------------------------------------
+0000000000000000 0000ffffffffffff 256TB 用户空间
+ffff000000000000 ffffffffffffffff 256TB 内核空间
+
+
+AArch64 Linux 在页大小为 64KB，并使用 2 级转换表时的内存布局：
+
+起始地址 结束地址 大小 用途
+-----------------------------------------------------------------------
+0000000000000000 000003ffffffffff 4TB 用户空间
+fffffc0000000000 ffffffffffffffff 4TB 内核空间
+
+
+AArch64 Linux 在页大小为 64KB，并使用 3 级转换表时的内存布局：
+
+起始地址 结束地址 大小 用途
+-----------------------------------------------------------------------
+0000000000000000 0000ffffffffffff 256TB 用户空间
+ffff000000000000 ffffffffffffffff 256TB 内核空间
+
+
+更详细的内核虚拟内存布局，请参阅内核启动信息。
+
+
+4KB 页大小的转换表查找：
+
++--------+--------+--------+--------+--------+--------+--------+--------+
+|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
++--------+--------+--------+--------+--------+--------+--------+--------+
+ | | | | | |
+ | | | | | v
+ | | | | | [11:0] 页内偏移
+ | | | | +-> [20:12] L3 索引
+ | | | +-----------> [29:21] L2 索引
+ | | +---------------------> [38:30] L1 索引
+ | +-------------------------------> [47:39] L0 索引
+ +-------------------------------------------------> [63] TTBR0/1
+
+
+64KB 页大小的转换表查找：
+
++--------+--------+--------+--------+--------+--------+--------+--------+
+|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
++--------+--------+--------+--------+--------+--------+--------+--------+
+ | | | | |
+ | | | | v
+ | | | | [15:0] 页内偏移
+ | | | +----------> [28:16] L3 索引
+ | | +--------------------------> [41:29] L2 索引
+ | +-------------------------------> [47:42] L1 索引
+ +-------------------------------------------------> [63] TTBR0/1
+
+
+当使用 KVM 时, 管理程序（hypervisor）在 EL2 中通过相对内核虚拟地址的
+一个固定偏移来映射内核页（内核虚拟地址的高 24 位设为零）:
+
+起始地址 结束地址 大小 用途
+-----------------------------------------------------------------------
+0000004000000000 0000007fffffffff 256GB 在 HYP 中映射的内核对象
diff --git a/Documentation/translations/zh_CN/arch/arm64/perf.rst b/Documentation/translations/zh_CN/arch/arm64/perf.rst
new file mode 100644
index 0000000..6be7270
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/perf.rst
@@ -0,0 +1,86 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/arch/arm64/perf.rst <perf_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+
+=============
+Perf 事件属性
+=============
+
+:作者: Andrew Murray <andrew.murray@arm.com>
+:日期: 2019-03-06
+
+exclude_user
+------------
+
+该属性排除用户空间。
+
+用户空间始终运行在 EL0，因此该属性将排除 EL0。
+
+
+exclude_kernel
+--------------
+
+该属性排除内核空间。
+
+打开 VHE 时内核运行在 EL2，不打开 VHE 时内核运行在 EL1。客户机
+内核总是运行在 EL1。
+
+对于宿主机，该属性排除 EL1 和 VHE 上的 EL2。
+
+对于客户机，该属性排除 EL1。请注意客户机从来不会运行在 EL2。
+
+
+exclude_hv
+----------
+
+该属性排除虚拟机监控器。
+
+对于 VHE 宿主机该属性将被忽略，此时我们认为宿主机内核是虚拟机监
+控器。
+
+对于 non-VHE 宿主机该属性将排除 EL2，因为虚拟机监控器运行在 EL2
+的任何代码主要用于客户机和宿主机的切换。
+
+对于客户机该属性无效。请注意客户机从来不会运行在 EL2。
+
+
+exclude_host / exclude_guest
+----------------------------
+
+这些属性分别排除了 KVM 宿主机和客户机。
+
+KVM 宿主机可能运行在 EL0（用户空间），EL1（non-VHE 内核）和
+EL2（VHE 内核 或 non-VHE 虚拟机监控器）。
+
+KVM 客户机可能运行在 EL0（用户空间）和 EL1（内核）。
+
+由于宿主机和客户机之间重叠的异常级别，我们不能仅仅依靠 PMU 的硬件异
+常过滤机制-因此我们必须启用/禁用对于客户机进入和退出的计数。而这在
+VHE 和 non-VHE 系统上表现不同。
+
+对于 non-VHE 系统的 exclude_host 属性排除 EL2 - 在进入和退出客户
+机时，我们会根据 exclude_host 和 exclude_guest 属性在适当的情况下
+禁用/启用该事件。
+
+对于 VHE 系统的 exclude_guest 属性排除 EL1，而对其中的 exclude_host
+属性同时排除 EL0，EL2。在进入和退出客户机时，我们会适当地根据
+exclude_host 和 exclude_guest 属性包括/排除 EL0。
+
+以上声明也适用于在 not-VHE 客户机使用这些属性时，但是请注意客户机从
+来不会运行在 EL2。
+
+
+准确性
+------
+
+在 non-VHE 宿主机上，我们在 EL2 进入/退出宿主机/客户机的切换时启用/
+关闭计数器 -但是在启用/禁用计数器和进入/退出客户机之间存在一段延时。
+对于 exclude_host， 我们可以通过过滤 EL2 消除在客户机进入/退出边界
+上用于计数客户机事件的宿主机事件计数器。但是当使用 !exclude_hv 时，
+在客户机进入/退出有一个小的停电窗口无法捕获到宿主机的事件。
+
+在 VHE 系统没有停电窗口。
diff --git a/Documentation/translations/zh_CN/arch/arm64/silicon-errata.txt b/Documentation/translations/zh_CN/arch/arm64/silicon-errata.txt
new file mode 100644
index 0000000..f4767ff
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/silicon-errata.txt
@@ -0,0 +1,74 @@
+Chinese translated version of Documentation/arch/arm64/silicon-errata.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+M: Will Deacon <will.deacon@arm.com>
+zh_CN: Fu Wei <wefu@redhat.com>
+C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
+---------------------------------------------------------------------
+Documentation/arch/arm64/silicon-errata.rst 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+
+英文版维护者： Will Deacon <will.deacon@arm.com>
+中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
+本文翻译提交时的 Git 检出点为： 1926e54f115725a9248d0c4c65c22acaf94de4c4
+
+以下为正文
+---------------------------------------------------------------------
+ 芯片勘误和软件补救措施
+ ==================
+
+作者: Will Deacon <will.deacon@arm.com>
+日期: 2015年11月27日
+
+一个不幸的现实：硬件经常带有一些所谓的“瑕疵（errata）”，导致其在
+某些特定情况下会违背构架定义的行为。就基于 ARM 的硬件而言，这些瑕疵
+大体可分为以下几类：
+
+ A 类：无可行补救措施的严重缺陷。
+ B 类：有可接受的补救措施的重大或严重缺陷。
+ C 类：在正常操作中不会显现的小瑕疵。
+
+更多资讯，请在 infocenter.arm.com （需注册）中查阅“软件开发者勘误
+笔记”（“Software Developers Errata Notice”）文档。
+
+对于 Linux 而言，B 类缺陷可能需要操作系统的某些特别处理。例如，避免
+一个特殊的代码序列，或是以一种特定的方式配置处理器。在某种不太常见的
+情况下，为将 A 类缺陷当作 C 类处理，可能需要用类似的手段。这些手段被
+统称为“软件补救措施”，且仅在少数情况需要（例如，那些需要一个运行在
+非安全异常级的补救措施 *并且* 能被 Linux 触发的情况）。
+
+对于尚在讨论中的可能对未受瑕疵影响的系统产生干扰的软件补救措施，有一个
+相应的内核配置（Kconfig）选项被加在 “内核特性（Kernel Features）”->
+“基于可选方法框架的 ARM 瑕疵补救措施（ARM errata workarounds via
+the alternatives framework）"。这些选项被默认开启，若探测到受影响的CPU，
+补丁将在运行时被使用。至于对系统运行影响较小的补救措施，内核配置选项
+并不存在，且代码以某种规避瑕疵的方式被构造（带注释为宜）。
+
+这种做法对于在任意内核源代码树中准确地判断出哪个瑕疵已被软件方法所补救
+稍微有点麻烦，所以在 Linux 内核中此文件作为软件补救措施的注册表，
+并将在新的软件补救措施被提交和向后移植（backported）到稳定内核时被更新。
+
+| 实现者 | 受影响的组件 | 勘误编号 | 内核配置 |
++----------------+-----------------+-----------------+-------------------------+
+| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
+| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
+| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
+| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
+| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
+| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
+| ARM | Cortex-A57 | #852523 | N/A |
+| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
+| | | | |
+| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
+| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
diff --git a/Documentation/translations/zh_CN/arch/arm64/tagged-pointers.txt b/Documentation/translations/zh_CN/arch/arm64/tagged-pointers.txt
new file mode 100644
index 0000000..27577c3
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/arm64/tagged-pointers.txt
@@ -0,0 +1,52 @@
+Chinese translated version of Documentation/arch/arm64/tagged-pointers.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Will Deacon <will.deacon@arm.com>
+Chinese maintainer: Fu Wei <wefu@redhat.com>
+---------------------------------------------------------------------
+Documentation/arch/arm64/tagged-pointers.rst 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+
+英文版维护者： Will Deacon <will.deacon@arm.com>
+中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
+中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
+
+以下为正文
+---------------------------------------------------------------------
+ Linux 在 AArch64 中带标记的虚拟地址
+ =================================
+
+作者: Will Deacon <will.deacon@arm.com>
+日期: 2013 年 06 月 12 日
+
+本文档简述了在 AArch64 地址转换系统中提供的带标记的虚拟地址及其在
+AArch64 Linux 中的潜在用途。
+
+内核提供的地址转换表配置使通过 TTBR0 完成的虚拟地址转换（即用户空间
+映射），其虚拟地址的最高 8 位（63:56）会被转换硬件所忽略。这种机制
+让这些位可供应用程序自由使用，其注意事项如下：
+
+ (1) 内核要求所有传递到 EL1 的用户空间地址带有 0x00 标记。
+ 这意味着任何携带用户空间虚拟地址的系统调用（syscall）
+ 参数 *必须* 在陷入内核前使它们的最高字节被清零。
+
+ (2) 非零标记在传递信号时不被保存。这意味着在应用程序中利用了
+ 标记的信号处理函数无法依赖 siginfo_t 的用户空间虚拟
+ 地址所携带的包含其内部域信息的标记。此规则的一个例外是
+ 当信号是在调试观察点的异常处理程序中产生的，此时标记的
+ 信息将被保存。
+
+ (3) 当使用带标记的指针时需特别留心，因为仅对两个虚拟地址
+ 的高字节，C 编译器很可能无法判断它们是不同的。
+
+此构架会阻止对带标记的 PC 指针的利用，因此在异常返回时，其高字节
+将被设置成一个为 “55” 的扩展符。
diff --git a/Documentation/translations/zh_CN/arch/index.rst b/Documentation/translations/zh_CN/arch/index.rst
index 908ea13..6fa0cb6 100644
--- a/Documentation/translations/zh_CN/arch/index.rst
+++ b/Documentation/translations/zh_CN/arch/index.rst
@@ -9,7 +9,7 @@
:maxdepth: 2
../mips/index
- ../arm64/index
+ arm64/index
../riscv/index
openrisc/index
parisc/index
diff --git a/Documentation/translations/zh_CN/arm/Booting b/Documentation/translations/zh_CN/arm/Booting
deleted file mode 100644
index 5ecea07..0000000
--- a/Documentation/translations/zh_CN/arm/Booting
+++ /dev/null
@@ -1,175 +0,0 @@
-Chinese translated version of Documentation/arm/booting.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-Maintainer: Russell King <linux@arm.linux.org.uk>
-Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
----------------------------------------------------------------------
-Documentation/arm/booting.rst 的中文翻译
-
-如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
-交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
-译存在问题，请联系中文版维护者。
-
-英文版维护者： Russell King <linux@arm.linux.org.uk>
-中文版维护者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
-中文版翻译者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
-中文版校译者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
-
-以下为正文
----------------------------------------------------------------------
-
- 启动 ARM Linux
- ==============
-
-作者：Russell King
-日期：2002年5月18日
-
-以下文档适用于 2.4.18-rmk6 及以上版本。
-
-为了启动 ARM Linux，你需要一个引导装载程序（boot loader），
-它是一个在主内核启动前运行的一个小程序。引导装载程序需要初始化各种
-设备，并最终调用 Linux 内核，将信息传递给内核。
-
-从本质上讲，引导装载程序应提供（至少）以下功能：
-
-1、设置和初始化 RAM。
-2、初始化一个串口。
-3、检测机器的类型（machine type）。
-4、设置内核标签列表（tagged list）。
-5、调用内核映像。
-
-
-1、设置和初始化 RAM
--------------------
-
-现有的引导加载程序: 强制
-新开发的引导加载程序: 强制
-
-引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。
-这个操作的执行是设备依赖的。（它可能使用内部算法来自动定位和计算所有
-RAM，或可能使用对这个设备已知的 RAM 信息，还可能使用任何引导装载程序
-设计者想到的匹配方法。）
-
-
-2、初始化一个串口
------------------------------
-
-现有的引导加载程序: 可选、建议
-新开发的引导加载程序: 可选、建议
-
-引导加载程序应该初始化并使能一个目标板上的串口。这允许内核串口驱动
-自动检测哪个串口用于内核控制台。(一般用于调试或与目标板通信。)
-
-作为替代方案，引导加载程序也可以通过标签列表传递相关的'console='
-选项给内核以指定某个串口，而串口数据格式的选项在以下文档中描述：
-
- Documentation/admin-guide/kernel-parameters.rst。
-
-
-3、检测机器类型
---------------------------
-
-现有的引导加载程序: 可选
-新开发的引导加载程序: 强制
-
-引导加载程序应该通过某些方式检测自身所处的机器类型。这是一个硬件
-代码或通过查看所连接的硬件用某些算法得到，这些超出了本文档的范围。
-引导加载程序最终必须能提供一个 MACH_TYPE_xxx 值给内核。
-(详见 linux/arch/arm/tools/mach-types )。
-
-4、设置启动数据
-------------------
-
-现有的引导加载程序: 可选、强烈建议
-新开发的引导加载程序: 强制
-
-引导加载程序必须提供标签列表或者 dtb 映像以传递配置数据给内核。启动
-数据的物理地址通过寄存器 r2 传递给内核。
-
-4a、设置内核标签列表
---------------------------------
-
-bootloader 必须创建和初始化内核标签列表。一个有效的标签列表以
-ATAG_CORE 标签开始，并以 ATAG_NONE 标签结束。ATAG_CORE 标签可以是
-空的，也可以是非空。一个空 ATAG_CORE 标签其 size 域设置为
-‘2’(0x00000002)。ATAG_NONE 标签的 size 域必须设置为零。
-
-在列表中可以保存任意数量的标签。对于一个重复的标签是追加到之前标签
-所携带的信息之后，还是会覆盖原来的信息，是未定义的。某些标签的行为
-是前者，其他是后者。
-
-bootloader 必须传递一个系统内存的位置和最小值，以及根文件系统位置。
-因此，最小的标签列表如下所示：
-
- +-----------+
-基地址 -> | ATAG_CORE | |
- +-----------+ |
- | ATAG_MEM | | 地址增长方向
- +-----------+ |
- | ATAG_NONE | |
- +-----------+ v
-
-标签列表应该保存在系统的 RAM 中。
-
-标签列表必须置于内核自解压和 initrd'bootp' 程序都不会覆盖的内存区。
-建议放在 RAM 的头 16KiB 中。
-
-4b、设置设备树
--------------------------
-
-bootloader 必须以 64bit 地址对齐的形式加载一个设备树映像(dtb)到系统
-RAM 中，并用启动数据初始化它。dtb 格式在文档
-https://www.devicetree.org/specifications/ 中。内核将会在
-dtb 物理地址处查找 dtb 魔数值（0xd00dfeed），以确定 dtb 是否已经代替
-标签列表被传递进来。
-
-bootloader 必须传递一个系统内存的位置和最小值，以及根文件系统位置。
-dtb 必须置于内核自解压不会覆盖的内存区。建议将其放置于 RAM 的头 16KiB
-中。但是不可将其放置于“0”物理地址处，因为内核认为：r2 中为 0，意味着
-没有标签列表和 dtb 传递过来。
-
-5、调用内核映像
----------------------------
-
-现有的引导加载程序: 强制
-新开发的引导加载程序: 强制
-
-调用内核映像 zImage 有两个选择。如果 zImge 保存在 flash 中，且是为了
-在 flash 中直接运行而被正确链接的。这样引导加载程序就可以在 flash 中
-直接调用 zImage。
-
-zImage 也可以被放在系统 RAM（任意位置）中被调用。注意：内核使用映像
-基地址的前 16KB RAM 空间来保存页表。建议将映像置于 RAM 的 32KB 处。
-
-对于以上任意一种情况，都必须符合以下启动状态：
-
-- 停止所有 DMA 设备，这样内存数据就不会因为虚假网络包或磁盘数据而被破坏。
- 这可能可以节省你许多的调试时间。
-
-- CPU 寄存器配置
- r0 = 0，
- r1 = （在上面 3 中获取的）机器类型码。
- r2 = 标签列表在系统 RAM 中的物理地址，或
- 设备树块(dtb)在系统 RAM 中的物理地址
-
-- CPU 模式
- 所有形式的中断必须被禁止 (IRQs 和 FIQs)
- CPU 必须处于 SVC 模式。(对于 Angel 调试有特例存在)
-
-- 缓存，MMUs
- MMU 必须关闭。
- 指令缓存开启或关闭都可以。
- 数据缓存必须关闭。
-
-- 引导加载程序应该通过直接跳转到内核映像的第一条指令来调用内核映像。
-
- 对于支持 ARM 指令集的 CPU，跳入内核入口时必须处在 ARM 状态，即使
- 对于 Thumb-2 内核也是如此。
-
- 对于仅支持 Thumb 指令集的 CPU，比如 Cortex-M 系列的 CPU，跳入
- 内核入口时必须处于 Thumb 状态。
diff --git a/Documentation/translations/zh_CN/arm/kernel_user_helpers.txt b/Documentation/translations/zh_CN/arm/kernel_user_helpers.txt
deleted file mode 100644
index 99af4363..0000000
--- a/Documentation/translations/zh_CN/arm/kernel_user_helpers.txt
+++ /dev/null
@@ -1,284 +0,0 @@
-Chinese translated version of Documentation/arm/kernel_user_helpers.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-Maintainer: Nicolas Pitre <nicolas.pitre@linaro.org>
- Dave Martin <dave.martin@linaro.org>
-Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
----------------------------------------------------------------------
-Documentation/arm/kernel_user_helpers.rst 的中文翻译
-
-如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
-交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
-译存在问题，请联系中文版维护者。
-英文版维护者： Nicolas Pitre <nicolas.pitre@linaro.org>
- Dave Martin <dave.martin@linaro.org>
-中文版维护者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
-中文版翻译者： 傅炜 Fu Wei <tekkamanninja@gmail.com>
-中文版校译者： 宋冬生 Dongsheng Song <dongshneg.song@gmail.com>
- 傅炜 Fu Wei <tekkamanninja@gmail.com>
-
-
-以下为正文
----------------------------------------------------------------------
-内核提供的用户空间辅助代码
-=========================
-
-在内核内存空间的固定地址处，有一个由内核提供并可从用户空间访问的代码
-段。它用于向用户空间提供因在许多 ARM CPU 中未实现的特性和/或指令而需
-内核提供帮助的某些操作。这些代码直接在用户模式下执行的想法是为了获得
-最佳效率，但那些与内核计数器联系过于紧密的部分，则被留给了用户库实现。
-事实上，此代码甚至可能因不同的 CPU 而异，这取决于其可用的指令集或它
-是否为 SMP 系统。换句话说，内核保留在不作出警告的情况下根据需要更改
-这些代码的权利。只有本文档描述的入口及其结果是保证稳定的。
-
-这与完全成熟的 VDSO 实现不同（但两者并不冲突），尽管如此，VDSO 可阻止
-某些通过常量高效跳转到那些代码段的汇编技巧。且由于那些代码段在返回用户
-代码前仅使用少量的代码周期，则一个 VDSO 间接远程调用将会在这些简单的
-操作上增加一个可测量的开销。
-
-在对那些拥有原生支持的新型处理器进行代码优化时，仅在已为其他操作使用
-了类似的新增指令，而导致二进制结果已与早期 ARM 处理器不兼容的情况下，
-用户空间才应绕过这些辅助代码，并在内联函数中实现这些操作（无论是通过
-编译器在代码中直接放置，还是作为库函数调用实现的一部分）。也就是说，
-如果你编译的代码不会为了其他目的使用新指令，则不要仅为了避免使用这些
-内核辅助代码，导致二进制程序无法在早期处理器上运行。
-
-新的辅助代码可能随着时间的推移而增加，所以新内核中的某些辅助代码在旧
-内核中可能不存在。因此，程序必须在对任何辅助代码调用假设是安全之前，
-检测 __kuser_helper_version 的值（见下文）。理想情况下，这种检测应该
-只在进程启动时执行一次；如果内核版本不支持所需辅助代码，则该进程可尽早
-中止执行。
-
-kuser_helper_version
---------------------
-
-位置: 0xffff0ffc
-
-参考声明:
-
- extern int32_t __kuser_helper_version;
-
-定义:
-
- 这个区域包含了当前运行内核实现的辅助代码版本号。用户空间可以通过读
- 取此版本号以确定特定的辅助代码是否存在。
-
-使用范例:
-
-#define __kuser_helper_version (*(int32_t *)0xffff0ffc)
-
-void check_kuser_version(void)
-{
- if (__kuser_helper_version < 2) {
- fprintf(stderr, "can't do atomic operations, kernel too old\n");
- abort();
- }
-}
-
-注意:
-
- 用户空间可以假设这个域的值不会在任何单个进程的生存期内改变。也就
- 是说，这个域可以仅在库的初始化阶段或进程启动阶段读取一次。
-
-kuser_get_tls
--------------
-
-位置: 0xffff0fe0
-
-参考原型:
-
- void * __kuser_get_tls(void);
-
-输入:
-
- lr = 返回地址
-
-输出:
-
- r0 = TLS 值
-
-被篡改的寄存器:
-
- 无
-
-定义:
-
- 获取之前通过 __ARM_NR_set_tls 系统调用设置的 TLS 值。
-
-使用范例:
-
-typedef void * (__kuser_get_tls_t)(void);
-#define __kuser_get_tls (*(__kuser_get_tls_t *)0xffff0fe0)
-
-void foo()
-{
- void *tls = __kuser_get_tls();
- printf("TLS = %p\n", tls);
-}
-
-注意:
-
- - 仅在 __kuser_helper_version >= 1 时，此辅助代码存在
- （从内核版本 2.6.12 开始）。
-
-kuser_cmpxchg
--------------
-
-位置: 0xffff0fc0
-
-参考原型:
-
- int __kuser_cmpxchg(int32_t oldval, int32_t newval, volatile int32_t *ptr);
-
-输入:
-
- r0 = oldval
- r1 = newval
- r2 = ptr
- lr = 返回地址
-
-输出:
-
- r0 = 成功代码 (零或非零)
- C flag = 如果 r0 == 0 则置 1，如果 r0 != 0 则清零。
-
-被篡改的寄存器:
-
- r3, ip, flags
-
-定义:
-
- 仅在 *ptr 为 oldval 时原子保存 newval 于 *ptr 中。
- 如果 *ptr 被改变，则返回值为零，否则为非零值。
- 如果 *ptr 被改变，则 C flag 也会被置 1，以实现调用代码中的汇编
- 优化。
-
-使用范例:
-
-typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr);
-#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0xffff0fc0)
-
-int atomic_add(volatile int *ptr, int val)
-{
- int old, new;
-
- do {
- old = *ptr;
- new = old + val;
- } while(__kuser_cmpxchg(old, new, ptr));
-
- return new;
-}
-
-注意:
-
- - 这个例程已根据需要包含了内存屏障。
-
- - 仅在 __kuser_helper_version >= 2 时，此辅助代码存在
- （从内核版本 2.6.12 开始）。
-
-kuser_memory_barrier
---------------------
-
-位置: 0xffff0fa0
-
-参考原型:
-
- void __kuser_memory_barrier(void);
-
-输入:
-
- lr = 返回地址
-
-输出:
-
- 无
-
-被篡改的寄存器:
-
- 无
-
-定义:
-
- 应用于任何需要内存屏障以防止手动数据修改带来的一致性问题，以及
- __kuser_cmpxchg 中。
-
-使用范例:
-
-typedef void (__kuser_dmb_t)(void);
-#define __kuser_dmb (*(__kuser_dmb_t *)0xffff0fa0)
-
-注意:
-
- - 仅在 __kuser_helper_version >= 3 时，此辅助代码存在
- （从内核版本 2.6.15 开始）。
-
-kuser_cmpxchg64
----------------
-
-位置: 0xffff0f60
-
-参考原型:
-
- int __kuser_cmpxchg64(const int64_t *oldval,
- const int64_t *newval,
- volatile int64_t *ptr);
-
-输入:
-
- r0 = 指向 oldval
- r1 = 指向 newval
- r2 = 指向目标值
- lr = 返回地址
-
-输出:
-
- r0 = 成功代码 (零或非零)
- C flag = 如果 r0 == 0 则置 1，如果 r0 != 0 则清零。
-
-被篡改的寄存器:
-
- r3, lr, flags
-
-定义:
-
- 仅在 *ptr 等于 *oldval 指向的 64 位值时，原子保存 *newval
- 指向的 64 位值于 *ptr 中。如果 *ptr 被改变，则返回值为零，
- 否则为非零值。
-
- 如果 *ptr 被改变，则 C flag 也会被置 1，以实现调用代码中的汇编
- 优化。
-
-使用范例:
-
-typedef int (__kuser_cmpxchg64_t)(const int64_t *oldval,
- const int64_t *newval,
- volatile int64_t *ptr);
-#define __kuser_cmpxchg64 (*(__kuser_cmpxchg64_t *)0xffff0f60)
-
-int64_t atomic_add64(volatile int64_t *ptr, int64_t val)
-{
- int64_t old, new;
-
- do {
- old = *ptr;
- new = old + val;
- } while(__kuser_cmpxchg64(&old, &new, ptr));
-
- return new;
-}
-
-注意:
-
- - 这个例程已根据需要包含了内存屏障。
-
- - 由于这个过程的代码长度（此辅助代码跨越 2 个常规的 kuser “槽”），
- 因此 0xffff0f80 不被作为有效的入口点。
-
- - 仅在 __kuser_helper_version >= 5 时，此辅助代码存在
- （从内核版本 3.1 开始）。
diff --git a/Documentation/translations/zh_CN/arm64/amu.rst b/Documentation/translations/zh_CN/arm64/amu.rst
deleted file mode 100644
index ab7180f..0000000
--- a/Documentation/translations/zh_CN/arm64/amu.rst
+++ /dev/null
@@ -1,100 +0,0 @@
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: :ref:`Documentation/arm64/amu.rst <amu_index>`
-
-Translator: Bailu Lin <bailu.lin@vivo.com>
-
-==================================
-AArch64 Linux 中扩展的活动监控单元
-==================================
-
-作者: Ionela Voinescu <ionela.voinescu@arm.com>
-
-日期: 2019-09-10
-
-本文档简要描述了 AArch64 Linux 支持的活动监控单元的规范。
-
-
-架构总述
---------
-
-活动监控是 ARMv8.4 CPU 架构引入的一个可选扩展特性。
-
-活动监控单元(在每个 CPU 中实现)为系统管理提供了性能计数器。既可以通
-过系统寄存器的方式访问计数器，同时也支持外部内存映射的方式访问计数器。
-
-AMUv1 架构实现了一个由4个固定的64位事件计数器组成的计数器组。
-
- - CPU 周期计数器：同 CPU 的频率增长
- - 常量计数器：同固定的系统时钟频率增长
- - 淘汰指令计数器: 同每次架构指令执行增长
- - 内存停顿周期计数器：计算由在时钟域内的最后一级缓存中未命中而引起
- 的指令调度停顿周期数
-
-当处于 WFI 或者 WFE 状态时，计数器不会增长。
-
-AMU 架构提供了一个高达16位的事件计数器空间，未来新的 AMU 版本中可能
-用它来实现新增的事件计数器。
-
-另外，AMUv1 实现了一个多达16个64位辅助事件计数器的计数器组。
-
-冷复位时所有的计数器会清零。
-
-
-基本支持
---------
-
-内核可以安全地运行在支持 AMU 和不支持 AMU 的 CPU 组合中。
-因此，当配置 CONFIG_ARM64_AMU_EXTN 后我们无条件使能后续
-(secondary or hotplugged) CPU 检测和使用这个特性。
-
-当在 CPU 上检测到该特性时，我们会标记为特性可用但是不能保证计数器的功能，
-仅表明有扩展属性。
-
-固件(代码运行在高异常级别，例如 arm-tf )需支持以下功能：
-
- - 提供低异常级别(EL2 和 EL1)访问 AMU 寄存器的能力。
- - 使能计数器。如果未使能，它的值应为 0。
- - 在从电源关闭状态启动 CPU 前或后保存或者恢复计数器。
-
-当使用使能了该特性的内核启动但固件损坏时，访问计数器寄存器可能会遭遇
-panic 或者死锁。即使未发现这些症状，计数器寄存器返回的数据结果并不一
-定能反映真实情况。通常，计数器会返回 0，表明他们未被使能。
-
-如果固件没有提供适当的支持最好关闭 CONFIG_ARM64_AMU_EXTN。
-值得注意的是，出于安全原因，不要绕过 AMUSERRENR_EL0 设置而捕获从
-EL0(用户空间) 访问 EL1(内核空间)。 因此，固件应该确保访问 AMU寄存器
-不会困在 EL2或EL3。
-
-AMUv1 的固定计数器可以通过如下系统寄存器访问：
-
- - SYS_AMEVCNTR0_CORE_EL0
- - SYS_AMEVCNTR0_CONST_EL0
- - SYS_AMEVCNTR0_INST_RET_EL0
- - SYS_AMEVCNTR0_MEM_STALL_EL0
-
-特定辅助计数器可以通过 SYS_AMEVCNTR1_EL0(n) 访问，其中n介于0到15。
-
-详细信息定义在目录：arch/arm64/include/asm/sysreg.h。
-
-
-用户空间访问
-------------
-
-由于以下原因，当前禁止从用户空间访问 AMU 的寄存器：
-
- - 安全因数：可能会暴露处于安全模式执行的代码信息。
- - 意愿：AMU 是用于系统管理的。
-
-同样，该功能对用户空间不可见。
-
-
-虚拟化
-------
-
-由于以下原因，当前禁止从 KVM 客户端的用户空间(EL0)和内核空间(EL1)
-访问 AMU 的寄存器：
-
- - 安全因数：可能会暴露给其他客户端或主机端执行的代码信息。
-
-任何试图访问 AMU 寄存器的行为都会触发一个注册在客户端的未定义异常。
diff --git a/Documentation/translations/zh_CN/arm64/booting.txt b/Documentation/translations/zh_CN/arm64/booting.txt
deleted file mode 100644
index 5b01641..0000000
--- a/Documentation/translations/zh_CN/arm64/booting.txt
+++ /dev/null
@@ -1,246 +0,0 @@
-Chinese translated version of Documentation/arm64/booting.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-M: Will Deacon <will.deacon@arm.com>
-zh_CN: Fu Wei <wefu@redhat.com>
-C: 55f058e7574c3615dea4615573a19bdb258696c6
----------------------------------------------------------------------
-Documentation/arm64/booting.rst 的中文翻译
-
-如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
-交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
-译存在问题，请联系中文版维护者。
-
-英文版维护者： Will Deacon <will.deacon@arm.com>
-中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
-本文翻译提交时的 Git 检出点为： 55f058e7574c3615dea4615573a19bdb258696c6
-
-以下为正文
----------------------------------------------------------------------
- 启动 AArch64 Linux
- ==================
-
-作者: Will Deacon <will.deacon@arm.com>
-日期: 2012 年 09 月 07 日
-
-本文档基于 Russell King 的 ARM 启动文档，且适用于所有公开发布的
-AArch64 Linux 内核代码。
-
-AArch64 异常模型由多个异常级（EL0 - EL3）组成，对于 EL0 和 EL1 异常级
-有对应的安全和非安全模式。EL2 是系统管理级，且仅存在于非安全模式下。
-EL3 是最高特权级，且仅存在于安全模式下。
-
-基于本文档的目的，我们将简单地使用‘引导装载程序’（‘boot loader’）
-这个术语来定义在将控制权交给 Linux 内核前 CPU 上执行的所有软件。
-这可能包含安全监控和系统管理代码，或者它可能只是一些用于准备最小启动
-环境的指令。
-
-基本上，引导装载程序（至少）应实现以下操作：
-
-1、设置和初始化 RAM
-2、设置设备树数据
-3、解压内核映像
-4、调用内核映像
-
-
-1、设置和初始化 RAM
------------------
-
-必要性: 强制
-
-引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。
-这个操作的执行方式因设备而异。（它可能使用内部算法来自动定位和计算所有
-RAM，或可能使用对这个设备已知的 RAM 信息，还可能是引导装载程序设计者
-想到的任何合适的方法。）
-
-
-2、设置设备树数据
----------------
-
-必要性: 强制
-
-设备树数据块（dtb）必须 8 字节对齐，且大小不能超过 2MB。由于设备树
-数据块将在使能缓存的情况下以 2MB 粒度被映射，故其不能被置于必须以特定
-属性映射的2M区域内。
-
-注： v4.2 之前的版本同时要求设备树数据块被置于从内核映像以下
-text_offset 字节处算起第一个 512MB 内。
-
-3、解压内核映像
--------------
-
-必要性: 可选
-
-AArch64 内核当前没有提供自解压代码，因此如果使用了压缩内核映像文件
-（比如 Image.gz），则需要通过引导装载程序（使用 gzip 等）来进行解压。
-若引导装载程序没有实现这个功能，就要使用非压缩内核映像文件。
-
-
-4、调用内核映像
--------------
-
-必要性: 强制
-
-已解压的内核映像包含一个 64 字节的头，内容如下：
-
- u32 code0; /* 可执行代码 */
- u32 code1; /* 可执行代码 */
- u64 text_offset; /* 映像装载偏移，小端模式 */
- u64 image_size; /* 映像实际大小, 小端模式 */
- u64 flags; /* 内核旗标, 小端模式 *
- u64 res2 = 0; /* 保留 */
- u64 res3 = 0; /* 保留 */
- u64 res4 = 0; /* 保留 */
- u32 magic = 0x644d5241; /* 魔数, 小端, "ARM\x64" */
- u32 res5; /* 保留 （用于 PE COFF 偏移） */
-
-
-映像头注释：
-
-- 自 v3.17 起，除非另有说明，所有域都是小端模式。
-
-- code0/code1 负责跳转到 stext.
-
-- 当通过 EFI 启动时， 最初 code0/code1 被跳过。
- res5 是到 PE 文件头的偏移，而 PE 文件头含有 EFI 的启动入口点
- （efi_stub_entry）。当 stub 代码完成了它的使命，它会跳转到 code0
- 继续正常的启动流程。
-
-- v3.17 之前，未明确指定 text_offset 的字节序。此时，image_size 为零，
- 且 text_offset 依照内核字节序为 0x80000。
- 当 image_size 非零，text_offset 为小端模式且是有效值，应被引导加载
- 程序使用。当 image_size 为零，text_offset 可假定为 0x80000。
-
-- flags 域 (v3.17 引入) 为 64 位小端模式，其编码如下：
- 位 0: 内核字节序。 1 表示大端模式，0 表示小端模式。
- 位 1-2: 内核页大小。
- 0 - 未指定。
- 1 - 4K
- 2 - 16K
- 3 - 64K
- 位 3: 内核物理位置
- 0 - 2MB 对齐基址应尽量靠近内存起始处，因为
- 其基址以下的内存无法通过线性映射访问
- 1 - 2MB 对齐基址可以在物理内存的任意位置
- 位 4-63: 保留。
-
-- 当 image_size 为零时，引导装载程序应试图在内核映像末尾之后尽可能
- 多地保留空闲内存供内核直接使用。对内存空间的需求量因所选定的内核
- 特性而异, 并无实际限制。
-
-内核映像必须被放置在任意一个可用系统内存 2MB 对齐基址的 text_offset
-字节处，并从该处被调用。2MB 对齐基址和内核映像起始地址之间的区域对于
-内核来说没有特殊意义，且可能被用于其他目的。
-从映像起始地址算起，最少必须准备 image_size 字节的空闲内存供内核使用。
-注： v4.6 之前的版本无法使用内核映像物理偏移以下的内存，所以当时建议
-将映像尽量放置在靠近系统内存起始的地方。
-
-任何提供给内核的内存（甚至在映像起始地址之前），若未从内核中标记为保留
-(如在设备树（dtb）的 memreserve 区域），都将被认为对内核是可用。
-
-在跳转入内核前，必须符合以下状态：
-
-- 停止所有 DMA 设备，这样内存数据就不会因为虚假网络包或磁盘数据而
- 被破坏。这可能可以节省你许多的调试时间。
-
-- 主 CPU 通用寄存器设置
- x0 = 系统 RAM 中设备树数据块（dtb）的物理地址。
- x1 = 0 (保留，将来可能使用)
- x2 = 0 (保留，将来可能使用)
- x3 = 0 (保留，将来可能使用)
-
-- CPU 模式
- 所有形式的中断必须在 PSTATE.DAIF 中被屏蔽（Debug、SError、IRQ
- 和 FIQ）。
- CPU 必须处于 EL2（推荐，可访问虚拟化扩展）或非安全 EL1 模式下。
-
-- 高速缓存、MMU
- MMU 必须关闭。
- 指令缓存开启或关闭皆可。
- 已载入的内核映像的相应内存区必须被清理，以达到缓存一致性点（PoC）。
- 当存在系统缓存或其他使能缓存的一致性主控器时，通常需使用虚拟地址
- 维护其缓存，而非 set/way 操作。
- 遵从通过虚拟地址操作维护构架缓存的系统缓存必须被配置，并可以被使能。
- 而不通过虚拟地址操作维护构架缓存的系统缓存（不推荐），必须被配置且
- 禁用。
-
- *译者注：对于 PoC 以及缓存相关内容，请参考 ARMv8 构架参考手册
- ARM DDI 0487A
-
-- 架构计时器
- CNTFRQ 必须设定为计时器的频率，且 CNTVOFF 必须设定为对所有 CPU
- 都一致的值。如果在 EL1 模式下进入内核，则 CNTHCTL_EL2 中的
- EL1PCTEN (bit 0) 必须置位。
-
-- 一致性
- 通过内核启动的所有 CPU 在内核入口地址上必须处于相同的一致性域中。
- 这可能要根据具体实现来定义初始化过程，以使能每个CPU上对维护操作的
- 接收。
-
-- 系统寄存器
- 在进入内核映像的异常级中，所有构架中可写的系统寄存器必须通过软件
- 在一个更高的异常级别下初始化，以防止在 未知 状态下运行。
-
- 对于拥有 GICv3 中断控制器并以 v3 模式运行的系统：
- - 如果 EL3 存在：
- ICC_SRE_EL3.Enable (位 3) 必须初始化为 0b1。
- ICC_SRE_EL3.SRE (位 0) 必须初始化为 0b1。
- - 若内核运行在 EL1：
- ICC_SRE_EL2.Enable (位 3) 必须初始化为 0b1。
- ICC_SRE_EL2.SRE (位 0) 必须初始化为 0b1。
- - 设备树（DT）或 ACPI 表必须描述一个 GICv3 中断控制器。
-
- 对于拥有 GICv3 中断控制器并以兼容（v2）模式运行的系统：
- - 如果 EL3 存在：
- ICC_SRE_EL3.SRE (位 0) 必须初始化为 0b0。
- - 若内核运行在 EL1：
- ICC_SRE_EL2.SRE (位 0) 必须初始化为 0b0。
- - 设备树（DT）或 ACPI 表必须描述一个 GICv2 中断控制器。
-
-以上对于 CPU 模式、高速缓存、MMU、架构计时器、一致性、系统寄存器的
-必要条件描述适用于所有 CPU。所有 CPU 必须在同一异常级别跳入内核。
-
-引导装载程序必须在每个 CPU 处于以下状态时跳入内核入口：
-
-- 主 CPU 必须直接跳入内核映像的第一条指令。通过此 CPU 传递的设备树
- 数据块必须在每个 CPU 节点中包含一个 ‘enable-method’ 属性，所
- 支持的 enable-method 请见下文。
-
- 引导装载程序必须生成这些设备树属性，并在跳入内核入口之前将其插入
- 数据块。
-
-- enable-method 为 “spin-table” 的 CPU 必须在它们的 CPU
- 节点中包含一个 ‘cpu-release-addr’ 属性。这个属性标识了一个
- 64 位自然对齐且初始化为零的内存位置。
-
- 这些 CPU 必须在内存保留区（通过设备树中的 /memreserve/ 域传递
- 给内核）中自旋于内核之外，轮询它们的 cpu-release-addr 位置（必须
- 包含在保留区中）。可通过插入 wfe 指令来降低忙循环开销，而主 CPU 将
- 发出 sev 指令。当对 cpu-release-addr 所指位置的读取操作返回非零值
- 时，CPU 必须跳入此值所指向的地址。此值为一个单独的 64 位小端值，
- 因此 CPU 须在跳转前将所读取的值转换为其本身的端模式。
-
-- enable-method 为 “psci” 的 CPU 保持在内核外（比如，在
- memory 节点中描述为内核空间的内存区外，或在通过设备树 /memreserve/
- 域中描述为内核保留区的空间中）。内核将会发起在 ARM 文档（编号
- ARM DEN 0022A：用于 ARM 上的电源状态协调接口系统软件）中描述的
- CPU_ON 调用来将 CPU 带入内核。
-
- *译者注: ARM DEN 0022A 已更新到 ARM DEN 0022C。
-
- 设备树必须包含一个 ‘psci’ 节点，请参考以下文档：
- Documentation/devicetree/bindings/arm/psci.yaml
-
-
-- 辅助 CPU 通用寄存器设置
- x0 = 0 (保留，将来可能使用)
- x1 = 0 (保留，将来可能使用)
- x2 = 0 (保留，将来可能使用)
- x3 = 0 (保留，将来可能使用)
diff --git a/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst b/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
deleted file mode 100644
index 9aa4637..0000000
--- a/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
+++ /dev/null
@@ -1,240 +0,0 @@
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: :ref:`Documentation/arm64/elf_hwcaps.rst <elf_hwcaps_index>`
-
-Translator: Bailu Lin <bailu.lin@vivo.com>
-
-================
-ARM64 ELF hwcaps
-================
-
-这篇文档描述了 arm64 ELF hwcaps 的用法和语义。
-
-
-1. 简介
--------
-
-有些硬件或软件功能仅在某些 CPU 实现上和/或在具体某个内核配置上可用，但
-对于处于 EL0 的用户空间代码没有可用的架构发现机制。内核通过在辅助向量表
-公开一组称为 hwcaps 的标志而把这些功能暴露给用户空间。
-
-用户空间软件可以通过获取辅助向量的 AT_HWCAP 或 AT_HWCAP2 条目来测试功能，
-并测试是否设置了相关标志，例如::
-
- bool floating_point_is_present(void)
- {
- unsigned long hwcaps = getauxval(AT_HWCAP);
- if (hwcaps & HWCAP_FP)
- return true;
-
- return false;
- }
-
-如果软件依赖于 hwcap 描述的功能，在尝试使用该功能前则应检查相关的 hwcap
-标志以验证该功能是否存在。
-
-不能通过其他方式探查这些功能。当一个功能不可用时，尝试使用它可能导致不可
-预测的行为，并且无法保证能确切的知道该功能不可用，例如 SIGILL。
-
-
-2. Hwcaps 的说明
-----------------
-
-大多数 hwcaps 旨在说明通过架构 ID 寄存器(处于 EL0 的用户空间代码无法访问)
-描述的功能的存在。这些 hwcap 通过 ID 寄存器字段定义，并且应根据 ARM 体系
-结构参考手册（ARM ARM）中定义的字段来解释说明。
-
-这些 hwcaps 以下面的形式描述::
-
- idreg.field == val 表示有某个功能。
-
-当 idreg.field 中有 val 时，hwcaps 表示 ARM ARM 定义的功能是有效的，但是
-并不是说要完全和 val 相等，也不是说 idreg.field 描述的其他功能就是缺失的。
-
-其他 hwcaps 可能表明无法仅由 ID 寄存器描述的功能的存在。这些 hwcaps 可能
-没有被 ID 寄存器描述，需要参考其他文档。
-
-
-3. AT_HWCAP 中揭示的 hwcaps
----------------------------
-
-HWCAP_FP
- ID_AA64PFR0_EL1.FP == 0b0000 表示有此功能。
-
-HWCAP_ASIMD
- ID_AA64PFR0_EL1.AdvSIMD == 0b0000 表示有此功能。
-
-HWCAP_EVTSTRM
- 通用计时器频率配置为大约100KHz以生成事件。
-
-HWCAP_AES
- ID_AA64ISAR0_EL1.AES == 0b0001 表示有此功能。
-
-HWCAP_PMULL
- ID_AA64ISAR0_EL1.AES == 0b0010 表示有此功能。
-
-HWCAP_SHA1
- ID_AA64ISAR0_EL1.SHA1 == 0b0001 表示有此功能。
-
-HWCAP_SHA2
- ID_AA64ISAR0_EL1.SHA2 == 0b0001 表示有此功能。
-
-HWCAP_CRC32
- ID_AA64ISAR0_EL1.CRC32 == 0b0001 表示有此功能。
-
-HWCAP_ATOMICS
- ID_AA64ISAR0_EL1.Atomic == 0b0010 表示有此功能。
-
-HWCAP_FPHP
- ID_AA64PFR0_EL1.FP == 0b0001 表示有此功能。
-
-HWCAP_ASIMDHP
- ID_AA64PFR0_EL1.AdvSIMD == 0b0001 表示有此功能。
-
-HWCAP_CPUID
- 根据 Documentation/arm64/cpu-feature-registers.rst 描述，EL0 可以访问
- 某些 ID 寄存器。
-
- 这些 ID 寄存器可能表示功能的可用性。
-
-HWCAP_ASIMDRDM
- ID_AA64ISAR0_EL1.RDM == 0b0001 表示有此功能。
-
-HWCAP_JSCVT
- ID_AA64ISAR1_EL1.JSCVT == 0b0001 表示有此功能。
-
-HWCAP_FCMA
- ID_AA64ISAR1_EL1.FCMA == 0b0001 表示有此功能。
-
-HWCAP_LRCPC
- ID_AA64ISAR1_EL1.LRCPC == 0b0001 表示有此功能。
-
-HWCAP_DCPOP
- ID_AA64ISAR1_EL1.DPB == 0b0001 表示有此功能。
-
-HWCAP_SHA3
- ID_AA64ISAR0_EL1.SHA3 == 0b0001 表示有此功能。
-
-HWCAP_SM3
- ID_AA64ISAR0_EL1.SM3 == 0b0001 表示有此功能。
-
-HWCAP_SM4
- ID_AA64ISAR0_EL1.SM4 == 0b0001 表示有此功能。
-
-HWCAP_ASIMDDP
- ID_AA64ISAR0_EL1.DP == 0b0001 表示有此功能。
-
-HWCAP_SHA512
- ID_AA64ISAR0_EL1.SHA2 == 0b0010 表示有此功能。
-
-HWCAP_SVE
- ID_AA64PFR0_EL1.SVE == 0b0001 表示有此功能。
-
-HWCAP_ASIMDFHM
- ID_AA64ISAR0_EL1.FHM == 0b0001 表示有此功能。
-
-HWCAP_DIT
- ID_AA64PFR0_EL1.DIT == 0b0001 表示有此功能。
-
-HWCAP_USCAT
- ID_AA64MMFR2_EL1.AT == 0b0001 表示有此功能。
-
-HWCAP_ILRCPC
- ID_AA64ISAR1_EL1.LRCPC == 0b0010 表示有此功能。
-
-HWCAP_FLAGM
- ID_AA64ISAR0_EL1.TS == 0b0001 表示有此功能。
-
-HWCAP_SSBS
- ID_AA64PFR1_EL1.SSBS == 0b0010 表示有此功能。
-
-HWCAP_SB
- ID_AA64ISAR1_EL1.SB == 0b0001 表示有此功能。
-
-HWCAP_PACA
- 如 Documentation/arm64/pointer-authentication.rst 所描述，
- ID_AA64ISAR1_EL1.APA == 0b0001 或 ID_AA64ISAR1_EL1.API == 0b0001
- 表示有此功能。
-
-HWCAP_PACG
- 如 Documentation/arm64/pointer-authentication.rst 所描述，
- ID_AA64ISAR1_EL1.GPA == 0b0001 或 ID_AA64ISAR1_EL1.GPI == 0b0001
- 表示有此功能。
-
-HWCAP2_DCPODP
-
- ID_AA64ISAR1_EL1.DPB == 0b0010 表示有此功能。
-
-HWCAP2_SVE2
-
- ID_AA64ZFR0_EL1.SVEVer == 0b0001 表示有此功能。
-
-HWCAP2_SVEAES
-
- ID_AA64ZFR0_EL1.AES == 0b0001 表示有此功能。
-
-HWCAP2_SVEPMULL
-
- ID_AA64ZFR0_EL1.AES == 0b0010 表示有此功能。
-
-HWCAP2_SVEBITPERM
-
- ID_AA64ZFR0_EL1.BitPerm == 0b0001 表示有此功能。
-
-HWCAP2_SVESHA3
-
- ID_AA64ZFR0_EL1.SHA3 == 0b0001 表示有此功能。
-
-HWCAP2_SVESM4
-
- ID_AA64ZFR0_EL1.SM4 == 0b0001 表示有此功能。
-
-HWCAP2_FLAGM2
-
- ID_AA64ISAR0_EL1.TS == 0b0010 表示有此功能。
-
-HWCAP2_FRINT
-
- ID_AA64ISAR1_EL1.FRINTTS == 0b0001 表示有此功能。
-
-HWCAP2_SVEI8MM
-
- ID_AA64ZFR0_EL1.I8MM == 0b0001 表示有此功能。
-
-HWCAP2_SVEF32MM
-
- ID_AA64ZFR0_EL1.F32MM == 0b0001 表示有此功能。
-
-HWCAP2_SVEF64MM
-
- ID_AA64ZFR0_EL1.F64MM == 0b0001 表示有此功能。
-
-HWCAP2_SVEBF16
-
- ID_AA64ZFR0_EL1.BF16 == 0b0001 表示有此功能。
-
-HWCAP2_I8MM
-
- ID_AA64ISAR1_EL1.I8MM == 0b0001 表示有此功能。
-
-HWCAP2_BF16
-
- ID_AA64ISAR1_EL1.BF16 == 0b0001 表示有此功能。
-
-HWCAP2_DGH
-
- ID_AA64ISAR1_EL1.DGH == 0b0001 表示有此功能。
-
-HWCAP2_RNG
-
- ID_AA64ISAR0_EL1.RNDR == 0b0001 表示有此功能。
-
-HWCAP2_BTI
-
- ID_AA64PFR0_EL1.BT == 0b0001 表示有此功能。
-
-
-4. 未使用的 AT_HWCAP 位
------------------------
-
-为了与用户空间交互，内核保证 AT_HWCAP 的第62、63位将始终返回0。
diff --git a/Documentation/translations/zh_CN/arm64/hugetlbpage.rst b/Documentation/translations/zh_CN/arm64/hugetlbpage.rst
deleted file mode 100644
index 13304d2..0000000
--- a/Documentation/translations/zh_CN/arm64/hugetlbpage.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: :ref:`Documentation/arm64/hugetlbpage.rst <hugetlbpage_index>`
-
-Translator: Bailu Lin <bailu.lin@vivo.com>
-
-=====================
-ARM64中的 HugeTLBpage
-=====================
-
-大页依靠有效利用 TLBs 来提高地址翻译的性能。这取决于以下
-两点 -
-
- - 大页的大小
- - TLBs 支持的条目大小
-
-ARM64 接口支持2种大页方式。
-
-1) pud/pmd 级别的块映射
------------------------
-
-这是常规大页，他们的 pmd 或 pud 页面表条目指向一个内存块。
-不管 TLB 中支持的条目大小如何，块映射可以减少翻译大页地址
-所需遍历的页表深度。
-
-2) 使用连续位
--------------
-
-架构中转换页表条目(D4.5.3, ARM DDI 0487C.a)中提供一个连续
-位告诉 MMU 这个条目是一个连续条目集的一员，它可以被缓存在单
-个 TLB 条目中。
-
-在 Linux 中连续位用来增加 pmd 和 pte(最后一级)级别映射的大
-小。受支持的连续页表条目数量因页面大小和页表级别而异。
-
-
-支持以下大页尺寸配置 -
-
- ====== ======== ==== ======== ===
- - CONT PTE PMD CONT PMD PUD
- ====== ======== ==== ======== ===
- 4K: 64K 2M 32M 1G
- 16K: 2M 32M 1G
- 64K: 2M 512M 16G
- ====== ======== ==== ======== ===
diff --git a/Documentation/translations/zh_CN/arm64/index.rst b/Documentation/translations/zh_CN/arm64/index.rst
deleted file mode 100644
index 57dc5de..0000000
--- a/Documentation/translations/zh_CN/arm64/index.rst
+++ /dev/null
@@ -1,19 +0,0 @@
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: :ref:`Documentation/arm64/index.rst <arm64_index>`
-:Translator: Bailu Lin <bailu.lin@vivo.com>
-
-.. _cn_arm64_index:
-
-
-==========
-ARM64 架构
-==========
-
-.. toctree::
- :maxdepth: 2
-
- amu
- hugetlbpage
- perf
- elf_hwcaps
diff --git a/Documentation/translations/zh_CN/arm64/legacy_instructions.txt b/Documentation/translations/zh_CN/arm64/legacy_instructions.txt
deleted file mode 100644
index e295cf7..0000000
--- a/Documentation/translations/zh_CN/arm64/legacy_instructions.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-Chinese translated version of Documentation/arm64/legacy_instructions.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-Maintainer: Punit Agrawal <punit.agrawal@arm.com>
- Suzuki K. Poulose <suzuki.poulose@arm.com>
-Chinese maintainer: Fu Wei <wefu@redhat.com>
----------------------------------------------------------------------
-Documentation/arm64/legacy_instructions.rst 的中文翻译
-
-如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
-交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
-译存在问题，请联系中文版维护者。
-
-本文翻译提交时的 Git 检出点为： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
-
-英文版维护者： Punit Agrawal <punit.agrawal@arm.com>
- Suzuki K. Poulose <suzuki.poulose@arm.com>
-中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
-
-以下为正文
----------------------------------------------------------------------
-Linux 内核在 arm64 上的移植提供了一个基础框架，以支持构架中正在被淘汰或已废弃指令的模拟执行。
-这个基础框架的代码使用未定义指令钩子（hooks）来支持模拟。如果指令存在，它也允许在硬件中启用该指令。
-
-模拟模式可通过写 sysctl 节点（/proc/sys/abi）来控制。
-不同的执行方式及 sysctl 节点的相应值，解释如下：
-
-* Undef（未定义）
- 值： 0
- 产生未定义指令终止异常。它是那些构架中已废弃的指令，如 SWP，的默认处理方式。
-
-* Emulate（模拟）
- 值： 1
- 使用软件模拟方式。为解决软件迁移问题，这种模拟指令模式的使用是被跟踪的，并会发出速率限制警告。
- 它是那些构架中正在被淘汰的指令，如 CP15 barriers（隔离指令），的默认处理方式。
-
-* Hardware Execution（硬件执行）
- 值： 2
- 虽然标记为正在被淘汰，但一些实现可能提供硬件执行这些指令的使能/禁用操作。
- 使用硬件执行一般会有更好的性能，但将无法收集运行时对正被淘汰指令的使用统计数据。
-
-默认执行模式依赖于指令在构架中状态。正在被淘汰的指令应该以模拟（Emulate）作为默认模式，
-而已废弃的指令必须默认使用未定义（Undef）模式
-
-注意：指令模拟可能无法应对所有情况。更多详情请参考单独的指令注释。
-
-受支持的遗留指令
--------------
-* SWP{B}
-节点: /proc/sys/abi/swp
-状态: 已废弃
-默认执行方式: Undef (0)
-
-* CP15 Barriers
-节点: /proc/sys/abi/cp15_barrier
-状态: 正被淘汰，不推荐使用
-默认执行方式: Emulate (1)
-
-* SETEND
-节点: /proc/sys/abi/setend
-状态: 正被淘汰，不推荐使用
-默认执行方式: Emulate (1)*
-注：为了使能这个特性，系统中的所有 CPU 必须在 EL0 支持混合字节序。
-如果一个新的 CPU （不支持混合字节序） 在使能这个特性后被热插入系统，
-在应用中可能会出现不可预期的结果。
diff --git a/Documentation/translations/zh_CN/arm64/memory.txt b/Documentation/translations/zh_CN/arm64/memory.txt
deleted file mode 100644
index be20f82..0000000
--- a/Documentation/translations/zh_CN/arm64/memory.txt
+++ /dev/null
@@ -1,114 +0,0 @@
-Chinese translated version of Documentation/arm64/memory.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-Maintainer: Catalin Marinas <catalin.marinas@arm.com>
-Chinese maintainer: Fu Wei <wefu@redhat.com>
----------------------------------------------------------------------
-Documentation/arm64/memory.rst 的中文翻译
-
-如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
-交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
-译存在问题，请联系中文版维护者。
-
-本文翻译提交时的 Git 检出点为： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
-
-英文版维护者： Catalin Marinas <catalin.marinas@arm.com>
-中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
-
-以下为正文
----------------------------------------------------------------------
- Linux 在 AArch64 中的内存布局
- ===========================
-
-作者: Catalin Marinas <catalin.marinas@arm.com>
-
-本文档描述 AArch64 Linux 内核所使用的虚拟内存布局。此构架可以实现
-页大小为 4KB 的 4 级转换表和页大小为 64KB 的 3 级转换表。
-
-AArch64 Linux 使用 3 级或 4 级转换表，其页大小配置为 4KB，对于用户和内核
-分别都有 39-bit (512GB) 或 48-bit (256TB) 的虚拟地址空间。
-对于页大小为 64KB的配置，仅使用 2 级转换表，有 42-bit (4TB) 的虚拟地址空间，但内存布局相同。
-
-用户地址空间的 63:48 位为 0，而内核地址空间的相应位为 1。TTBRx 的
-选择由虚拟地址的 63 位给出。swapper_pg_dir 仅包含内核（全局）映射，
-而用户 pgd 仅包含用户（非全局）映射。swapper_pg_dir 地址被写入
-TTBR1 中，且从不写入 TTBR0。
-
-
-AArch64 Linux 在页大小为 4KB，并使用 3 级转换表时的内存布局：
-
-起始地址 结束地址 大小 用途
------------------------------------------------------------------------
-0000000000000000 0000007fffffffff 512GB 用户空间
-ffffff8000000000 ffffffffffffffff 512GB 内核空间
-
-
-AArch64 Linux 在页大小为 4KB，并使用 4 级转换表时的内存布局：
-
-起始地址 结束地址 大小 用途
------------------------------------------------------------------------
-0000000000000000 0000ffffffffffff 256TB 用户空间
-ffff000000000000 ffffffffffffffff 256TB 内核空间
-
-
-AArch64 Linux 在页大小为 64KB，并使用 2 级转换表时的内存布局：
-
-起始地址 结束地址 大小 用途
------------------------------------------------------------------------
-0000000000000000 000003ffffffffff 4TB 用户空间
-fffffc0000000000 ffffffffffffffff 4TB 内核空间
-
-
-AArch64 Linux 在页大小为 64KB，并使用 3 级转换表时的内存布局：
-
-起始地址 结束地址 大小 用途
------------------------------------------------------------------------
-0000000000000000 0000ffffffffffff 256TB 用户空间
-ffff000000000000 ffffffffffffffff 256TB 内核空间
-
-
-更详细的内核虚拟内存布局，请参阅内核启动信息。
-
-
-4KB 页大小的转换表查找：
-
-+--------+--------+--------+--------+--------+--------+--------+--------+
-|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
-+--------+--------+--------+--------+--------+--------+--------+--------+
- | | | | | |
- | | | | | v
- | | | | | [11:0] 页内偏移
- | | | | +-> [20:12] L3 索引
- | | | +-----------> [29:21] L2 索引
- | | +---------------------> [38:30] L1 索引
- | +-------------------------------> [47:39] L0 索引
- +-------------------------------------------------> [63] TTBR0/1
-
-
-64KB 页大小的转换表查找：
-
-+--------+--------+--------+--------+--------+--------+--------+--------+
-|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
-+--------+--------+--------+--------+--------+--------+--------+--------+
- | | | | |
- | | | | v
- | | | | [15:0] 页内偏移
- | | | +----------> [28:16] L3 索引
- | | +--------------------------> [41:29] L2 索引
- | +-------------------------------> [47:42] L1 索引
- +-------------------------------------------------> [63] TTBR0/1
-
-
-当使用 KVM 时, 管理程序（hypervisor）在 EL2 中通过相对内核虚拟地址的
-一个固定偏移来映射内核页（内核虚拟地址的高 24 位设为零）:
-
-起始地址 结束地址 大小 用途
------------------------------------------------------------------------
-0000004000000000 0000007fffffffff 256GB 在 HYP 中映射的内核对象
diff --git a/Documentation/translations/zh_CN/arm64/perf.rst b/Documentation/translations/zh_CN/arm64/perf.rst
deleted file mode 100644
index 9bf21d7..0000000
--- a/Documentation/translations/zh_CN/arm64/perf.rst
+++ /dev/null
@@ -1,86 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: :ref:`Documentation/arm64/perf.rst <perf_index>`
-
-Translator: Bailu Lin <bailu.lin@vivo.com>
-
-=============
-Perf 事件属性
-=============
-
-:作者: Andrew Murray <andrew.murray@arm.com>
-:日期: 2019-03-06
-
-exclude_user
-------------
-
-该属性排除用户空间。
-
-用户空间始终运行在 EL0，因此该属性将排除 EL0。
-
-
-exclude_kernel
---------------
-
-该属性排除内核空间。
-
-打开 VHE 时内核运行在 EL2，不打开 VHE 时内核运行在 EL1。客户机
-内核总是运行在 EL1。
-
-对于宿主机，该属性排除 EL1 和 VHE 上的 EL2。
-
-对于客户机，该属性排除 EL1。请注意客户机从来不会运行在 EL2。
-
-
-exclude_hv
-----------
-
-该属性排除虚拟机监控器。
-
-对于 VHE 宿主机该属性将被忽略，此时我们认为宿主机内核是虚拟机监
-控器。
-
-对于 non-VHE 宿主机该属性将排除 EL2，因为虚拟机监控器运行在 EL2
-的任何代码主要用于客户机和宿主机的切换。
-
-对于客户机该属性无效。请注意客户机从来不会运行在 EL2。
-
-
-exclude_host / exclude_guest
-----------------------------
-
-这些属性分别排除了 KVM 宿主机和客户机。
-
-KVM 宿主机可能运行在 EL0（用户空间），EL1（non-VHE 内核）和
-EL2（VHE 内核 或 non-VHE 虚拟机监控器）。
-
-KVM 客户机可能运行在 EL0（用户空间）和 EL1（内核）。
-
-由于宿主机和客户机之间重叠的异常级别，我们不能仅仅依靠 PMU 的硬件异
-常过滤机制-因此我们必须启用/禁用对于客户机进入和退出的计数。而这在
-VHE 和 non-VHE 系统上表现不同。
-
-对于 non-VHE 系统的 exclude_host 属性排除 EL2 - 在进入和退出客户
-机时，我们会根据 exclude_host 和 exclude_guest 属性在适当的情况下
-禁用/启用该事件。
-
-对于 VHE 系统的 exclude_guest 属性排除 EL1，而对其中的 exclude_host
-属性同时排除 EL0，EL2。在进入和退出客户机时，我们会适当地根据
-exclude_host 和 exclude_guest 属性包括/排除 EL0。
-
-以上声明也适用于在 not-VHE 客户机使用这些属性时，但是请注意客户机从
-来不会运行在 EL2。
-
-
-准确性
-------
-
-在 non-VHE 宿主机上，我们在 EL2 进入/退出宿主机/客户机的切换时启用/
-关闭计数器 -但是在启用/禁用计数器和进入/退出客户机之间存在一段延时。
-对于 exclude_host， 我们可以通过过滤 EL2 消除在客户机进入/退出边界
-上用于计数客户机事件的宿主机事件计数器。但是当使用 !exclude_hv 时，
-在客户机进入/退出有一个小的停电窗口无法捕获到宿主机的事件。
-
-在 VHE 系统没有停电窗口。
diff --git a/Documentation/translations/zh_CN/arm64/silicon-errata.txt b/Documentation/translations/zh_CN/arm64/silicon-errata.txt
deleted file mode 100644
index 440c59a..0000000
--- a/Documentation/translations/zh_CN/arm64/silicon-errata.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Chinese translated version of Documentation/arm64/silicon-errata.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-M: Will Deacon <will.deacon@arm.com>
-zh_CN: Fu Wei <wefu@redhat.com>
-C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
----------------------------------------------------------------------
-Documentation/arm64/silicon-errata.rst 的中文翻译
-
-如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
-交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
-译存在问题，请联系中文版维护者。
-
-英文版维护者： Will Deacon <will.deacon@arm.com>
-中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
-本文翻译提交时的 Git 检出点为： 1926e54f115725a9248d0c4c65c22acaf94de4c4
-
-以下为正文
----------------------------------------------------------------------
- 芯片勘误和软件补救措施
- ==================
-
-作者: Will Deacon <will.deacon@arm.com>
-日期: 2015年11月27日
-
-一个不幸的现实：硬件经常带有一些所谓的“瑕疵（errata）”，导致其在
-某些特定情况下会违背构架定义的行为。就基于 ARM 的硬件而言，这些瑕疵
-大体可分为以下几类：
-
- A 类：无可行补救措施的严重缺陷。
- B 类：有可接受的补救措施的重大或严重缺陷。
- C 类：在正常操作中不会显现的小瑕疵。
-
-更多资讯，请在 infocenter.arm.com （需注册）中查阅“软件开发者勘误
-笔记”（“Software Developers Errata Notice”）文档。
-
-对于 Linux 而言，B 类缺陷可能需要操作系统的某些特别处理。例如，避免
-一个特殊的代码序列，或是以一种特定的方式配置处理器。在某种不太常见的
-情况下，为将 A 类缺陷当作 C 类处理，可能需要用类似的手段。这些手段被
-统称为“软件补救措施”，且仅在少数情况需要（例如，那些需要一个运行在
-非安全异常级的补救措施 *并且* 能被 Linux 触发的情况）。
-
-对于尚在讨论中的可能对未受瑕疵影响的系统产生干扰的软件补救措施，有一个
-相应的内核配置（Kconfig）选项被加在 “内核特性（Kernel Features）”->
-“基于可选方法框架的 ARM 瑕疵补救措施（ARM errata workarounds via
-the alternatives framework）"。这些选项被默认开启，若探测到受影响的CPU，
-补丁将在运行时被使用。至于对系统运行影响较小的补救措施，内核配置选项
-并不存在，且代码以某种规避瑕疵的方式被构造（带注释为宜）。
-
-这种做法对于在任意内核源代码树中准确地判断出哪个瑕疵已被软件方法所补救
-稍微有点麻烦，所以在 Linux 内核中此文件作为软件补救措施的注册表，
-并将在新的软件补救措施被提交和向后移植（backported）到稳定内核时被更新。
-
-| 实现者 | 受影响的组件 | 勘误编号 | 内核配置 |
-+----------------+-----------------+-----------------+-------------------------+
-| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
-| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
-| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
-| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
-| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
-| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
-| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
-| ARM | Cortex-A57 | #852523 | N/A |
-| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
-| | | | |
-| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
-| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
diff --git a/Documentation/translations/zh_CN/arm64/tagged-pointers.txt b/Documentation/translations/zh_CN/arm64/tagged-pointers.txt
deleted file mode 100644
index 77ac354..0000000
--- a/Documentation/translations/zh_CN/arm64/tagged-pointers.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-Chinese translated version of Documentation/arm64/tagged-pointers.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-Maintainer: Will Deacon <will.deacon@arm.com>
-Chinese maintainer: Fu Wei <wefu@redhat.com>
----------------------------------------------------------------------
-Documentation/arm64/tagged-pointers.rst 的中文翻译
-
-如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
-交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
-译存在问题，请联系中文版维护者。
-
-英文版维护者： Will Deacon <will.deacon@arm.com>
-中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
-中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
-
-以下为正文
----------------------------------------------------------------------
- Linux 在 AArch64 中带标记的虚拟地址
- =================================
-
-作者: Will Deacon <will.deacon@arm.com>
-日期: 2013 年 06 月 12 日
-
-本文档简述了在 AArch64 地址转换系统中提供的带标记的虚拟地址及其在
-AArch64 Linux 中的潜在用途。
-
-内核提供的地址转换表配置使通过 TTBR0 完成的虚拟地址转换（即用户空间
-映射），其虚拟地址的最高 8 位（63:56）会被转换硬件所忽略。这种机制
-让这些位可供应用程序自由使用，其注意事项如下：
-
- (1) 内核要求所有传递到 EL1 的用户空间地址带有 0x00 标记。
- 这意味着任何携带用户空间虚拟地址的系统调用（syscall）
- 参数 *必须* 在陷入内核前使它们的最高字节被清零。
-
- (2) 非零标记在传递信号时不被保存。这意味着在应用程序中利用了
- 标记的信号处理函数无法依赖 siginfo_t 的用户空间虚拟
- 地址所携带的包含其内部域信息的标记。此规则的一个例外是
- 当信号是在调试观察点的异常处理程序中产生的，此时标记的
- 信息将被保存。
-
- (3) 当使用带标记的指针时需特别留心，因为仅对两个虚拟地址
- 的高字节，C 编译器很可能无法判断它们是不同的。
-
-此构架会阻止对带标记的 PC 指针的利用，因此在异常返回时，其高字节
-将被设置成一个为 “55” 的扩展符。
diff --git a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst
index 84ce232..aeccff7 100644
--- a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst
+++ b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst
@@ -153,8 +153,7 @@
大多数 GPIO 控制器可以通过内存读/写指令来访问。这些指令不会休眠,可以
安全地在硬(非线程)中断例程和类似的上下文中完成。
-对于那些用 gpio_cansleep()测试总是返回失败的 GPIO(见下文)，使用
-以下的函数访问::
+对于那些 GPIO，使用以下的函数访问::
/* GPIO 输入:返回零或非零 */
int gpio_get_value(unsigned gpio);
@@ -186,11 +185,6 @@
GPIO 值的命令需要等待其信息排到队首才发送命令，再获得其反馈。期间需要
休眠，这不能在 IRQ 例程(中断上下文)中执行。
-支持此类 GPIO 的平台通过以下函数返回非零值来区分出这种 GPIO。(此函数需要
-一个之前通过 gpio_request 分配到的有效 GPIO 编号)::
-
- int gpio_cansleep(unsigned gpio);
-
为了访问这种 GPIO,内核定义了一套不同的函数::
/* GPIO 输入:返回零或非零 ,可能会休眠 */
@@ -199,7 +193,6 @@
/* GPIO 输出,可能会休眠 */
void gpio_set_value_cansleep(unsigned gpio, int value);
-
访问这样的 GPIO 需要一个允许休眠的上下文，例如线程 IRQ 处理例程，并用以上的
访问函数替换那些没有 cansleep()后缀的自旋锁安全访问函数。
@@ -294,11 +287,6 @@
* GPIOF_INIT_LOW - 在作为输出时,初始值为低电平
* GPIOF_INIT_HIGH - 在作为输出时,初始值为高电平
- * GPIOF_OPEN_DRAIN - gpio引脚为开漏信号
- * GPIOF_OPEN_SOURCE - gpio引脚为源极开路信号
-
- * GPIOF_EXPORT_DIR_FIXED - 将 gpio 导出到 sysfs，并保持方向
- * GPIOF_EXPORT_DIR_CHANGEABLE - 同样是导出, 但允许改变方向
因为 GPIOF_INIT_* 仅有在配置为输出的时候才存在,所以有效的组合为:
@@ -306,18 +294,6 @@
* GPIOF_OUT_INIT_LOW - 配置为输出,并初始化为低电平
* GPIOF_OUT_INIT_HIGH - 配置为输出,并初始化为高电平
-当设置 flag 为 GPIOF_OPEN_DRAIN 时，则假设引脚是开漏信号。这样的引脚
-将不会在输出模式下置1。这样的引脚需要连接上拉电阻。通过使能这个标志，gpio库
-将会在被要求输出模式下置1时将引脚变为输入状态来使引脚置高。引脚在输出模式下
-通过置0使其输出低电平。
-
-当设置 flag 为 GPIOF_OPEN_SOURCE 时，则假设引脚为源极开路信号。这样的引脚
-将不会在输出模式下置0。这样的引脚需要连接下拉电阻。通过使能这个标志，gpio库
-将会在被要求输出模式下置0时将引脚变为输入状态来使引脚置低。引脚在输出模式下
-通过置1使其输出高电平。
-
-将来这些标志可能扩展到支持更多的属性。
-
更进一步,为了更简单地声明/释放多个 GPIO,'struct gpio'被引进来封装所有
这三个领域::
@@ -500,8 +476,8 @@
为了支持这个框架，一个平台的 Kconfig 文件将会 "select"(选择)
ARCH_REQUIRE_GPIOLIB 或 ARCH_WANT_OPTIONAL_GPIOLIB，并让它的
-<asm/gpio.h> 包含 <asm-generic/gpio.h>，同时定义三个方法:
-gpio_get_value()、gpio_set_value()和 gpio_cansleep()。
+<asm/gpio.h> 包含 <asm-generic/gpio.h>，同时定义两个方法:
+gpio_get_value()、gpio_set_value()。
它也应提供一个 ARCH_NR_GPIOS 的定义值，这样可以更好地反映该平台 GPIO
的实际数量,节省静态表的空间。(这个定义值应该包含片上系统内建 GPIO 和
@@ -519,7 +495,6 @@
#define gpio_get_value __gpio_get_value
#define gpio_set_value __gpio_set_value
- #define gpio_cansleep __gpio_cansleep
这些定义可以用更理想的实现方法替代，那就是使用经过逻辑优化的内联函数来访问
基于特定片上系统的 GPIO。例如,若引用的 GPIO (寄存器位偏移)是常量“12”，
diff --git a/Documentation/translations/zh_CN/mm/page_migration.rst b/Documentation/translations/zh_CN/mm/page_migration.rst
index 076081d..f950638 100644
--- a/Documentation/translations/zh_CN/mm/page_migration.rst
+++ b/Documentation/translations/zh_CN/mm/page_migration.rst
@@ -55,7 +55,7 @@
消失。它还可以防止交换器或其他扫描器遇到该页。
-2. 我们需要有一个new_page_t类型的函数，可以传递给migrate_pages()。这个函数应该计算
+2. 我们需要有一个new_folio_t类型的函数，可以传递给migrate_pages()。这个函数应该计算
出如何在给定的旧页面中分配正确的新页面。
3. migrate_pages()函数被调用，它试图进行迁移。它将调用该函数为每个被考虑迁移的页面分
diff --git a/Documentation/translations/zh_CN/process/2.Process.rst b/Documentation/translations/zh_CN/process/2.Process.rst
index 4a6ed02..e68c9de 100644
--- a/Documentation/translations/zh_CN/process/2.Process.rst
+++ b/Documentation/translations/zh_CN/process/2.Process.rst
@@ -358,7 +358,7 @@
机器上始终完美运行”。通常的方法是和其他人一起解决问题（这可能需
要坚持！），但就是如此——这是内核开发的一部分。
-(http://lwn.net/articles/283982/)
+(http://lwn.net/Articles/283982/)
在没有明显问题需要解决的情况下，通常建议开发人员查看当前的回归和开放缺陷
列表。从来都不缺少需要解决的问题；通过解决这些问题，开发人员将从该过程获得
diff --git a/Documentation/translations/zh_CN/process/3.Early-stage.rst b/Documentation/translations/zh_CN/process/3.Early-stage.rst
index de53dd1..2caba47 100644
--- a/Documentation/translations/zh_CN/process/3.Early-stage.rst
+++ b/Documentation/translations/zh_CN/process/3.Early-stage.rst
@@ -44,7 +44,7 @@
试图向这些人传达用户需求是浪费时间。他们太“聪明”了，根本听不到少数
人的话。
-（http://lwn.net/articles/131776/）
+（http://lwn.net/Articles/131776/）
实际情况却是不同的；与特定模块相比，内核开发人员更关心系统稳定性、长期维护
以及找到问题的正确解决方案。这个故事的寓意是把重点放在问题上——而不是具体的
diff --git a/Documentation/translations/zh_CN/process/4.Coding.rst b/Documentation/translations/zh_CN/process/4.Coding.rst
index 94f7f86..7cac942 100644
--- a/Documentation/translations/zh_CN/process/4.Coding.rst
+++ b/Documentation/translations/zh_CN/process/4.Coding.rst
@@ -149,7 +149,7 @@
所以我们不会通过引入新问题来修复错误。这种方式是靠不住的，没人知道
是否真的有进展。是前进两步、后退一步，还是前进一步、后退两步？
-（http://lwn.net/articles/243460/）
+（http://lwn.net/Articles/243460/）
特别不受欢迎的一种回归类型是用户空间ABI的任何变化。一旦接口被导出到用户空间，
就必须无限期地支持它。这一事实使得用户空间接口的创建特别具有挑战性：因为它们
diff --git a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
index 6d0dada..57beca0 100644
--- a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
@@ -98,7 +98,7 @@
你可以给我发补丁，但当我从你那里拉取一个Git补丁时，我需要知道你清楚
自己在做什么，我需要能够相信事情而 *无需* 手动检查每个单独的更改。
-（http://lwn.net/articles/224135/）。
+（http://lwn.net/Articles/224135/）。
为了避免这种情况，请确保给定分支中的所有补丁都与相关主题紧密相关；“驱动程序
修复”分支不应更改核心内存管理代码。而且，最重要的是，不要使用Git树来绕过
diff --git a/Documentation/translations/zh_TW/arch/arm64/amu.rst b/Documentation/translations/zh_TW/arch/arm64/amu.rst
new file mode 100644
index 0000000..f947a6c
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/amu.rst
@@ -0,0 +1,104 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: :ref:`Documentation/arch/arm64/amu.rst <amu_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+ Hu Haowen <src.res@email.cn>
+
+==================================
+AArch64 Linux 中擴展的活動監控單元
+==================================
+
+作者: Ionela Voinescu <ionela.voinescu@arm.com>
+
+日期: 2019-09-10
+
+本文檔簡要描述了 AArch64 Linux 支持的活動監控單元的規範。
+
+
+架構總述
+--------
+
+活動監控是 ARMv8.4 CPU 架構引入的一個可選擴展特性。
+
+活動監控單元(在每個 CPU 中實現)爲系統管理提供了性能計數器。既可以通
+過系統寄存器的方式訪問計數器，同時也支持外部內存映射的方式訪問計數器。
+
+AMUv1 架構實現了一個由4個固定的64位事件計數器組成的計數器組。
+
+ - CPU 周期計數器：同 CPU 的頻率增長
+ - 常量計數器：同固定的系統時鐘頻率增長
+ - 淘汰指令計數器: 同每次架構指令執行增長
+ - 內存停頓周期計數器：計算由在時鐘域內的最後一級緩存中未命中而引起
+ 的指令調度停頓周期數
+
+當處於 WFI 或者 WFE 狀態時，計數器不會增長。
+
+AMU 架構提供了一個高達16位的事件計數器空間，未來新的 AMU 版本中可能
+用它來實現新增的事件計數器。
+
+另外，AMUv1 實現了一個多達16個64位輔助事件計數器的計數器組。
+
+冷復位時所有的計數器會清零。
+
+
+基本支持
+--------
+
+內核可以安全地運行在支持 AMU 和不支持 AMU 的 CPU 組合中。
+因此，當配置 CONFIG_ARM64_AMU_EXTN 後我們無條件使能後續
+(secondary or hotplugged) CPU 檢測和使用這個特性。
+
+當在 CPU 上檢測到該特性時，我們會標記爲特性可用但是不能保證計數器的功能，
+僅表明有擴展屬性。
+
+固件(代碼運行在高異常級別，例如 arm-tf )需支持以下功能：
+
+ - 提供低異常級別(EL2 和 EL1)訪問 AMU 寄存器的能力。
+ - 使能計數器。如果未使能，它的值應爲 0。
+ - 在從電源關閉狀態啓動 CPU 前或後保存或者恢復計數器。
+
+當使用使能了該特性的內核啓動但固件損壞時，訪問計數器寄存器可能會遭遇
+panic 或者死鎖。即使未發現這些症狀，計數器寄存器返回的數據結果並不一
+定能反映真實情況。通常，計數器會返回 0，表明他們未被使能。
+
+如果固件沒有提供適當的支持最好關閉 CONFIG_ARM64_AMU_EXTN。
+值得注意的是，出於安全原因，不要繞過 AMUSERRENR_EL0 設置而捕獲從
+EL0(用戶空間) 訪問 EL1(內核空間)。 因此，固件應該確保訪問 AMU寄存器
+不會困在 EL2或EL3。
+
+AMUv1 的固定計數器可以通過如下系統寄存器訪問：
+
+ - SYS_AMEVCNTR0_CORE_EL0
+ - SYS_AMEVCNTR0_CONST_EL0
+ - SYS_AMEVCNTR0_INST_RET_EL0
+ - SYS_AMEVCNTR0_MEM_STALL_EL0
+
+特定輔助計數器可以通過 SYS_AMEVCNTR1_EL0(n) 訪問，其中n介於0到15。
+
+詳細信息定義在目錄：arch/arm64/include/asm/sysreg.h。
+
+
+用戶空間訪問
+------------
+
+由於以下原因，當前禁止從用戶空間訪問 AMU 的寄存器：
+
+ - 安全因數：可能會暴露處於安全模式執行的代碼信息。
+ - 意願：AMU 是用於系統管理的。
+
+同樣，該功能對用戶空間不可見。
+
+
+虛擬化
+------
+
+由於以下原因，當前禁止從 KVM 客戶端的用戶空間(EL0)和內核空間(EL1)
+訪問 AMU 的寄存器：
+
+ - 安全因數：可能會暴露給其他客戶端或主機端執行的代碼信息。
+
+任何試圖訪問 AMU 寄存器的行爲都會觸發一個註冊在客戶端的未定義異常。
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/booting.txt b/Documentation/translations/zh_TW/arch/arm64/booting.txt
new file mode 100644
index 0000000..24817b8
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/booting.txt
@@ -0,0 +1,251 @@
+SPDX-License-Identifier: GPL-2.0
+
+Chinese translated version of Documentation/arch/arm64/booting.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+M: Will Deacon <will.deacon@arm.com>
+zh_CN: Fu Wei <wefu@redhat.com>
+zh_TW: Hu Haowen <src.res@email.cn>
+C: 55f058e7574c3615dea4615573a19bdb258696c6
+---------------------------------------------------------------------
+Documentation/arch/arm64/booting.rst 的中文翻譯
+
+如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
+交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
+譯存在問題，請聯繫中文版維護者。
+
+英文版維護者： Will Deacon <will.deacon@arm.com>
+中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+本文翻譯提交時的 Git 檢出點爲： 55f058e7574c3615dea4615573a19bdb258696c6
+
+以下爲正文
+---------------------------------------------------------------------
+ 啓動 AArch64 Linux
+ ==================
+
+作者: Will Deacon <will.deacon@arm.com>
+日期: 2012 年 09 月 07 日
+
+本文檔基於 Russell King 的 ARM 啓動文檔，且適用於所有公開發布的
+AArch64 Linux 內核代碼。
+
+AArch64 異常模型由多個異常級（EL0 - EL3）組成，對於 EL0 和 EL1 異常級
+有對應的安全和非安全模式。EL2 是系統管理級，且僅存在於非安全模式下。
+EL3 是最高特權級，且僅存在於安全模式下。
+
+基於本文檔的目的，我們將簡單地使用『引導裝載程序』（『boot loader』）
+這個術語來定義在將控制權交給 Linux 內核前 CPU 上執行的所有軟體。
+這可能包含安全監控和系統管理代碼，或者它可能只是一些用於準備最小啓動
+環境的指令。
+
+基本上，引導裝載程序（至少）應實現以下操作：
+
+1、設置和初始化 RAM
+2、設置設備樹數據
+3、解壓內核映像
+4、調用內核映像
+
+
+1、設置和初始化 RAM
+-----------------
+
+必要性: 強制
+
+引導裝載程序應該找到並初始化系統中所有內核用於保持系統變量數據的 RAM。
+這個操作的執行方式因設備而異。（它可能使用內部算法來自動定位和計算所有
+RAM，或可能使用對這個設備已知的 RAM 信息，還可能是引導裝載程序設計者
+想到的任何合適的方法。）
+
+
+2、設置設備樹數據
+---------------
+
+必要性: 強制
+
+設備樹數據塊（dtb）必須 8 字節對齊，且大小不能超過 2MB。由於設備樹
+數據塊將在使能緩存的情況下以 2MB 粒度被映射，故其不能被置於必須以特定
+屬性映射的2M區域內。
+
+註： v4.2 之前的版本同時要求設備樹數據塊被置於從內核映像以下
+text_offset 字節處算起第一個 512MB 內。
+
+3、解壓內核映像
+-------------
+
+必要性: 可選
+
+AArch64 內核當前沒有提供自解壓代碼，因此如果使用了壓縮內核映像文件
+（比如 Image.gz），則需要通過引導裝載程序（使用 gzip 等）來進行解壓。
+若引導裝載程序沒有實現這個功能，就要使用非壓縮內核映像文件。
+
+
+4、調用內核映像
+-------------
+
+必要性: 強制
+
+已解壓的內核映像包含一個 64 字節的頭，內容如下：
+
+ u32 code0; /* 可執行代碼 */
+ u32 code1; /* 可執行代碼 */
+ u64 text_offset; /* 映像裝載偏移，小端模式 */
+ u64 image_size; /* 映像實際大小, 小端模式 */
+ u64 flags; /* 內核旗標, 小端模式 *
+ u64 res2 = 0; /* 保留 */
+ u64 res3 = 0; /* 保留 */
+ u64 res4 = 0; /* 保留 */
+ u32 magic = 0x644d5241; /* 魔數, 小端, "ARM\x64" */
+ u32 res5; /* 保留 （用於 PE COFF 偏移） */
+
+
+映像頭注釋：
+
+- 自 v3.17 起，除非另有說明，所有域都是小端模式。
+
+- code0/code1 負責跳轉到 stext.
+
+- 當通過 EFI 啓動時， 最初 code0/code1 被跳過。
+ res5 是到 PE 文件頭的偏移，而 PE 文件頭含有 EFI 的啓動入口點
+ （efi_stub_entry）。當 stub 代碼完成了它的使命，它會跳轉到 code0
+ 繼續正常的啓動流程。
+
+- v3.17 之前，未明確指定 text_offset 的字節序。此時，image_size 爲零，
+ 且 text_offset 依照內核字節序爲 0x80000。
+ 當 image_size 非零，text_offset 爲小端模式且是有效值，應被引導加載
+ 程序使用。當 image_size 爲零，text_offset 可假定爲 0x80000。
+
+- flags 域 (v3.17 引入) 爲 64 位小端模式，其編碼如下：
+ 位 0: 內核字節序。 1 表示大端模式，0 表示小端模式。
+ 位 1-2: 內核頁大小。
+ 0 - 未指定。
+ 1 - 4K
+ 2 - 16K
+ 3 - 64K
+ 位 3: 內核物理位置
+ 0 - 2MB 對齊基址應儘量靠近內存起始處，因爲
+ 其基址以下的內存無法通過線性映射訪問
+ 1 - 2MB 對齊基址可以在物理內存的任意位置
+ 位 4-63: 保留。
+
+- 當 image_size 爲零時，引導裝載程序應試圖在內核映像末尾之後儘可能
+ 多地保留空閒內存供內核直接使用。對內存空間的需求量因所選定的內核
+ 特性而異, 並無實際限制。
+
+內核映像必須被放置在任意一個可用系統內存 2MB 對齊基址的 text_offset
+字節處，並從該處被調用。2MB 對齊基址和內核映像起始地址之間的區域對於
+內核來說沒有特殊意義，且可能被用於其他目的。
+從映像起始地址算起，最少必須準備 image_size 字節的空閒內存供內核使用。
+註： v4.6 之前的版本無法使用內核映像物理偏移以下的內存，所以當時建議
+將映像儘量放置在靠近系統內存起始的地方。
+
+任何提供給內核的內存（甚至在映像起始地址之前），若未從內核中標記爲保留
+(如在設備樹（dtb）的 memreserve 區域），都將被認爲對內核是可用。
+
+在跳轉入內核前，必須符合以下狀態：
+
+- 停止所有 DMA 設備，這樣內存數據就不會因爲虛假網絡包或磁碟數據而
+ 被破壞。這可能可以節省你許多的調試時間。
+
+- 主 CPU 通用寄存器設置
+ x0 = 系統 RAM 中設備樹數據塊（dtb）的物理地址。
+ x1 = 0 (保留，將來可能使用)
+ x2 = 0 (保留，將來可能使用)
+ x3 = 0 (保留，將來可能使用)
+
+- CPU 模式
+ 所有形式的中斷必須在 PSTATE.DAIF 中被屏蔽（Debug、SError、IRQ
+ 和 FIQ）。
+ CPU 必須處於 EL2（推薦，可訪問虛擬化擴展）或非安全 EL1 模式下。
+
+- 高速緩存、MMU
+ MMU 必須關閉。
+ 指令緩存開啓或關閉皆可。
+ 已載入的內核映像的相應內存區必須被清理，以達到緩存一致性點（PoC）。
+ 當存在系統緩存或其他使能緩存的一致性主控器時，通常需使用虛擬地址
+ 維護其緩存，而非 set/way 操作。
+ 遵從通過虛擬地址操作維護構架緩存的系統緩存必須被配置，並可以被使能。
+ 而不通過虛擬地址操作維護構架緩存的系統緩存（不推薦），必須被配置且
+ 禁用。
+
+ *譯者註：對於 PoC 以及緩存相關內容，請參考 ARMv8 構架參考手冊
+ ARM DDI 0487A
+
+- 架構計時器
+ CNTFRQ 必須設定爲計時器的頻率，且 CNTVOFF 必須設定爲對所有 CPU
+ 都一致的值。如果在 EL1 模式下進入內核，則 CNTHCTL_EL2 中的
+ EL1PCTEN (bit 0) 必須置位。
+
+- 一致性
+ 通過內核啓動的所有 CPU 在內核入口地址上必須處於相同的一致性域中。
+ 這可能要根據具體實現來定義初始化過程，以使能每個CPU上對維護操作的
+ 接收。
+
+- 系統寄存器
+ 在進入內核映像的異常級中，所有構架中可寫的系統寄存器必須通過軟體
+ 在一個更高的異常級別下初始化，以防止在 未知 狀態下運行。
+
+ 對於擁有 GICv3 中斷控制器並以 v3 模式運行的系統：
+ - 如果 EL3 存在：
+ ICC_SRE_EL3.Enable (位 3) 必須初始化爲 0b1。
+ ICC_SRE_EL3.SRE (位 0) 必須初始化爲 0b1。
+ - 若內核運行在 EL1：
+ ICC_SRE_EL2.Enable (位 3) 必須初始化爲 0b1。
+ ICC_SRE_EL2.SRE (位 0) 必須初始化爲 0b1。
+ - 設備樹（DT）或 ACPI 表必須描述一個 GICv3 中斷控制器。
+
+ 對於擁有 GICv3 中斷控制器並以兼容（v2）模式運行的系統：
+ - 如果 EL3 存在：
+ ICC_SRE_EL3.SRE (位 0) 必須初始化爲 0b0。
+ - 若內核運行在 EL1：
+ ICC_SRE_EL2.SRE (位 0) 必須初始化爲 0b0。
+ - 設備樹（DT）或 ACPI 表必須描述一個 GICv2 中斷控制器。
+
+以上對於 CPU 模式、高速緩存、MMU、架構計時器、一致性、系統寄存器的
+必要條件描述適用於所有 CPU。所有 CPU 必須在同一異常級別跳入內核。
+
+引導裝載程序必須在每個 CPU 處於以下狀態時跳入內核入口：
+
+- 主 CPU 必須直接跳入內核映像的第一條指令。通過此 CPU 傳遞的設備樹
+ 數據塊必須在每個 CPU 節點中包含一個 『enable-method』 屬性，所
+ 支持的 enable-method 請見下文。
+
+ 引導裝載程序必須生成這些設備樹屬性，並在跳入內核入口之前將其插入
+ 數據塊。
+
+- enable-method 爲 「spin-table」 的 CPU 必須在它們的 CPU
+ 節點中包含一個 『cpu-release-addr』 屬性。這個屬性標識了一個
+ 64 位自然對齊且初始化爲零的內存位置。
+
+ 這些 CPU 必須在內存保留區（通過設備樹中的 /memreserve/ 域傳遞
+ 給內核）中自旋於內核之外，輪詢它們的 cpu-release-addr 位置（必須
+ 包含在保留區中）。可通過插入 wfe 指令來降低忙循環開銷，而主 CPU 將
+ 發出 sev 指令。當對 cpu-release-addr 所指位置的讀取操作返回非零值
+ 時，CPU 必須跳入此值所指向的地址。此值爲一個單獨的 64 位小端值，
+ 因此 CPU 須在跳轉前將所讀取的值轉換爲其本身的端模式。
+
+- enable-method 爲 「psci」 的 CPU 保持在內核外（比如，在
+ memory 節點中描述爲內核空間的內存區外，或在通過設備樹 /memreserve/
+ 域中描述爲內核保留區的空間中）。內核將會發起在 ARM 文檔（編號
+ ARM DEN 0022A：用於 ARM 上的電源狀態協調接口系統軟體）中描述的
+ CPU_ON 調用來將 CPU 帶入內核。
+
+ *譯者注: ARM DEN 0022A 已更新到 ARM DEN 0022C。
+
+ 設備樹必須包含一個 『psci』 節點，請參考以下文檔：
+ Documentation/devicetree/bindings/arm/psci.yaml
+
+
+- 輔助 CPU 通用寄存器設置
+ x0 = 0 (保留，將來可能使用)
+ x1 = 0 (保留，將來可能使用)
+ x2 = 0 (保留，將來可能使用)
+ x3 = 0 (保留，將來可能使用)
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst b/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst
new file mode 100644
index 0000000..fca3c6f
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst
@@ -0,0 +1,244 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: :ref:`Documentation/arch/arm64/elf_hwcaps.rst <elf_hwcaps_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+ Hu Haowen <src.res@email.cn>
+
+================
+ARM64 ELF hwcaps
+================
+
+這篇文檔描述了 arm64 ELF hwcaps 的用法和語義。
+
+
+1. 簡介
+-------
+
+有些硬體或軟體功能僅在某些 CPU 實現上和/或在具體某個內核配置上可用，但
+對於處於 EL0 的用戶空間代碼沒有可用的架構發現機制。內核通過在輔助向量表
+公開一組稱爲 hwcaps 的標誌而把這些功能暴露給用戶空間。
+
+用戶空間軟體可以通過獲取輔助向量的 AT_HWCAP 或 AT_HWCAP2 條目來測試功能，
+並測試是否設置了相關標誌，例如::
+
+ bool floating_point_is_present(void)
+ {
+ unsigned long hwcaps = getauxval(AT_HWCAP);
+ if (hwcaps & HWCAP_FP)
+ return true;
+
+ return false;
+ }
+
+如果軟體依賴於 hwcap 描述的功能，在嘗試使用該功能前則應檢查相關的 hwcap
+標誌以驗證該功能是否存在。
+
+不能通過其他方式探查這些功能。當一個功能不可用時，嘗試使用它可能導致不可
+預測的行爲，並且無法保證能確切的知道該功能不可用，例如 SIGILL。
+
+
+2. Hwcaps 的說明
+----------------
+
+大多數 hwcaps 旨在說明通過架構 ID 寄存器(處於 EL0 的用戶空間代碼無法訪問)
+描述的功能的存在。這些 hwcap 通過 ID 寄存器欄位定義，並且應根據 ARM 體系
+結構參考手冊（ARM ARM）中定義的欄位來解釋說明。
+
+這些 hwcaps 以下面的形式描述::
+
+ idreg.field == val 表示有某個功能。
+
+當 idreg.field 中有 val 時，hwcaps 表示 ARM ARM 定義的功能是有效的，但是
+並不是說要完全和 val 相等，也不是說 idreg.field 描述的其他功能就是缺失的。
+
+其他 hwcaps 可能表明無法僅由 ID 寄存器描述的功能的存在。這些 hwcaps 可能
+沒有被 ID 寄存器描述，需要參考其他文檔。
+
+
+3. AT_HWCAP 中揭示的 hwcaps
+---------------------------
+
+HWCAP_FP
+ ID_AA64PFR0_EL1.FP == 0b0000 表示有此功能。
+
+HWCAP_ASIMD
+ ID_AA64PFR0_EL1.AdvSIMD == 0b0000 表示有此功能。
+
+HWCAP_EVTSTRM
+ 通用計時器頻率配置爲大約100KHz以生成事件。
+
+HWCAP_AES
+ ID_AA64ISAR0_EL1.AES == 0b0001 表示有此功能。
+
+HWCAP_PMULL
+ ID_AA64ISAR0_EL1.AES == 0b0010 表示有此功能。
+
+HWCAP_SHA1
+ ID_AA64ISAR0_EL1.SHA1 == 0b0001 表示有此功能。
+
+HWCAP_SHA2
+ ID_AA64ISAR0_EL1.SHA2 == 0b0001 表示有此功能。
+
+HWCAP_CRC32
+ ID_AA64ISAR0_EL1.CRC32 == 0b0001 表示有此功能。
+
+HWCAP_ATOMICS
+ ID_AA64ISAR0_EL1.Atomic == 0b0010 表示有此功能。
+
+HWCAP_FPHP
+ ID_AA64PFR0_EL1.FP == 0b0001 表示有此功能。
+
+HWCAP_ASIMDHP
+ ID_AA64PFR0_EL1.AdvSIMD == 0b0001 表示有此功能。
+
+HWCAP_CPUID
+ 根據 Documentation/arch/arm64/cpu-feature-registers.rst 描述，EL0 可以訪問
+ 某些 ID 寄存器。
+
+ 這些 ID 寄存器可能表示功能的可用性。
+
+HWCAP_ASIMDRDM
+ ID_AA64ISAR0_EL1.RDM == 0b0001 表示有此功能。
+
+HWCAP_JSCVT
+ ID_AA64ISAR1_EL1.JSCVT == 0b0001 表示有此功能。
+
+HWCAP_FCMA
+ ID_AA64ISAR1_EL1.FCMA == 0b0001 表示有此功能。
+
+HWCAP_LRCPC
+ ID_AA64ISAR1_EL1.LRCPC == 0b0001 表示有此功能。
+
+HWCAP_DCPOP
+ ID_AA64ISAR1_EL1.DPB == 0b0001 表示有此功能。
+
+HWCAP_SHA3
+ ID_AA64ISAR0_EL1.SHA3 == 0b0001 表示有此功能。
+
+HWCAP_SM3
+ ID_AA64ISAR0_EL1.SM3 == 0b0001 表示有此功能。
+
+HWCAP_SM4
+ ID_AA64ISAR0_EL1.SM4 == 0b0001 表示有此功能。
+
+HWCAP_ASIMDDP
+ ID_AA64ISAR0_EL1.DP == 0b0001 表示有此功能。
+
+HWCAP_SHA512
+ ID_AA64ISAR0_EL1.SHA2 == 0b0010 表示有此功能。
+
+HWCAP_SVE
+ ID_AA64PFR0_EL1.SVE == 0b0001 表示有此功能。
+
+HWCAP_ASIMDFHM
+ ID_AA64ISAR0_EL1.FHM == 0b0001 表示有此功能。
+
+HWCAP_DIT
+ ID_AA64PFR0_EL1.DIT == 0b0001 表示有此功能。
+
+HWCAP_USCAT
+ ID_AA64MMFR2_EL1.AT == 0b0001 表示有此功能。
+
+HWCAP_ILRCPC
+ ID_AA64ISAR1_EL1.LRCPC == 0b0010 表示有此功能。
+
+HWCAP_FLAGM
+ ID_AA64ISAR0_EL1.TS == 0b0001 表示有此功能。
+
+HWCAP_SSBS
+ ID_AA64PFR1_EL1.SSBS == 0b0010 表示有此功能。
+
+HWCAP_SB
+ ID_AA64ISAR1_EL1.SB == 0b0001 表示有此功能。
+
+HWCAP_PACA
+ 如 Documentation/arch/arm64/pointer-authentication.rst 所描述，
+ ID_AA64ISAR1_EL1.APA == 0b0001 或 ID_AA64ISAR1_EL1.API == 0b0001
+ 表示有此功能。
+
+HWCAP_PACG
+ 如 Documentation/arch/arm64/pointer-authentication.rst 所描述，
+ ID_AA64ISAR1_EL1.GPA == 0b0001 或 ID_AA64ISAR1_EL1.GPI == 0b0001
+ 表示有此功能。
+
+HWCAP2_DCPODP
+
+ ID_AA64ISAR1_EL1.DPB == 0b0010 表示有此功能。
+
+HWCAP2_SVE2
+
+ ID_AA64ZFR0_EL1.SVEVer == 0b0001 表示有此功能。
+
+HWCAP2_SVEAES
+
+ ID_AA64ZFR0_EL1.AES == 0b0001 表示有此功能。
+
+HWCAP2_SVEPMULL
+
+ ID_AA64ZFR0_EL1.AES == 0b0010 表示有此功能。
+
+HWCAP2_SVEBITPERM
+
+ ID_AA64ZFR0_EL1.BitPerm == 0b0001 表示有此功能。
+
+HWCAP2_SVESHA3
+
+ ID_AA64ZFR0_EL1.SHA3 == 0b0001 表示有此功能。
+
+HWCAP2_SVESM4
+
+ ID_AA64ZFR0_EL1.SM4 == 0b0001 表示有此功能。
+
+HWCAP2_FLAGM2
+
+ ID_AA64ISAR0_EL1.TS == 0b0010 表示有此功能。
+
+HWCAP2_FRINT
+
+ ID_AA64ISAR1_EL1.FRINTTS == 0b0001 表示有此功能。
+
+HWCAP2_SVEI8MM
+
+ ID_AA64ZFR0_EL1.I8MM == 0b0001 表示有此功能。
+
+HWCAP2_SVEF32MM
+
+ ID_AA64ZFR0_EL1.F32MM == 0b0001 表示有此功能。
+
+HWCAP2_SVEF64MM
+
+ ID_AA64ZFR0_EL1.F64MM == 0b0001 表示有此功能。
+
+HWCAP2_SVEBF16
+
+ ID_AA64ZFR0_EL1.BF16 == 0b0001 表示有此功能。
+
+HWCAP2_I8MM
+
+ ID_AA64ISAR1_EL1.I8MM == 0b0001 表示有此功能。
+
+HWCAP2_BF16
+
+ ID_AA64ISAR1_EL1.BF16 == 0b0001 表示有此功能。
+
+HWCAP2_DGH
+
+ ID_AA64ISAR1_EL1.DGH == 0b0001 表示有此功能。
+
+HWCAP2_RNG
+
+ ID_AA64ISAR0_EL1.RNDR == 0b0001 表示有此功能。
+
+HWCAP2_BTI
+
+ ID_AA64PFR0_EL1.BT == 0b0001 表示有此功能。
+
+
+4. 未使用的 AT_HWCAP 位
+-----------------------
+
+爲了與用戶空間交互，內核保證 AT_HWCAP 的第62、63位將始終返回0。
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst b/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst
new file mode 100644
index 0000000..10feb32
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: :ref:`Documentation/arch/arm64/hugetlbpage.rst <hugetlbpage_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+ Hu Haowen <src.res@email.cn>
+
+=====================
+ARM64中的 HugeTLBpage
+=====================
+
+大頁依靠有效利用 TLBs 來提高地址翻譯的性能。這取決於以下
+兩點 -
+
+ - 大頁的大小
+ - TLBs 支持的條目大小
+
+ARM64 接口支持2種大頁方式。
+
+1) pud/pmd 級別的塊映射
+-----------------------
+
+這是常規大頁，他們的 pmd 或 pud 頁面表條目指向一個內存塊。
+不管 TLB 中支持的條目大小如何，塊映射可以減少翻譯大頁地址
+所需遍歷的頁表深度。
+
+2) 使用連續位
+-------------
+
+架構中轉換頁表條目(D4.5.3, ARM DDI 0487C.a)中提供一個連續
+位告訴 MMU 這個條目是一個連續條目集的一員，它可以被緩存在單
+個 TLB 條目中。
+
+在 Linux 中連續位用來增加 pmd 和 pte(最後一級)級別映射的大
+小。受支持的連續頁表條目數量因頁面大小和頁表級別而異。
+
+
+支持以下大頁尺寸配置 -
+
+ ====== ======== ==== ======== ===
+ - CONT PTE PMD CONT PMD PUD
+ ====== ======== ==== ======== ===
+ 4K: 64K 2M 32M 1G
+ 16K: 2M 32M 1G
+ 64K: 2M 512M 16G
+ ====== ======== ==== ======== ===
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/index.rst b/Documentation/translations/zh_TW/arch/arm64/index.rst
new file mode 100644
index 0000000..68befee
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/index.rst
@@ -0,0 +1,23 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: :ref:`Documentation/arch/arm64/index.rst <arm64_index>`
+:Translator: Bailu Lin <bailu.lin@vivo.com>
+ Hu Haowen <src.res@email.cn>
+
+.. _tw_arm64_index:
+
+
+==========
+ARM64 架構
+==========
+
+.. toctree::
+ :maxdepth: 2
+
+ amu
+ hugetlbpage
+ perf
+ elf_hwcaps
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt b/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt
new file mode 100644
index 0000000..3c915df
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt
@@ -0,0 +1,77 @@
+SPDX-License-Identifier: GPL-2.0
+
+Chinese translated version of Documentation/arch/arm64/legacy_instructions.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Punit Agrawal <punit.agrawal@arm.com>
+ Suzuki K. Poulose <suzuki.poulose@arm.com>
+Chinese maintainer: Fu Wei <wefu@redhat.com>
+Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+---------------------------------------------------------------------
+Documentation/arch/arm64/legacy_instructions.rst 的中文翻譯
+
+如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
+交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
+譯存在問題，請聯繫中文版維護者。
+
+本文翻譯提交時的 Git 檢出點爲： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
+
+英文版維護者： Punit Agrawal <punit.agrawal@arm.com>
+ Suzuki K. Poulose <suzuki.poulose@arm.com>
+中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
+繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn>
+
+以下爲正文
+---------------------------------------------------------------------
+Linux 內核在 arm64 上的移植提供了一個基礎框架，以支持構架中正在被淘汰或已廢棄指令的模擬執行。
+這個基礎框架的代碼使用未定義指令鉤子（hooks）來支持模擬。如果指令存在，它也允許在硬體中啓用該指令。
+
+模擬模式可通過寫 sysctl 節點（/proc/sys/abi）來控制。
+不同的執行方式及 sysctl 節點的相應值，解釋如下：
+
+* Undef（未定義）
+ 值： 0
+ 產生未定義指令終止異常。它是那些構架中已廢棄的指令，如 SWP，的默認處理方式。
+
+* Emulate（模擬）
+ 值： 1
+ 使用軟體模擬方式。爲解決軟體遷移問題，這種模擬指令模式的使用是被跟蹤的，並會發出速率限制警告。
+ 它是那些構架中正在被淘汰的指令，如 CP15 barriers（隔離指令），的默認處理方式。
+
+* Hardware Execution（硬體執行）
+ 值： 2
+ 雖然標記爲正在被淘汰，但一些實現可能提供硬體執行這些指令的使能/禁用操作。
+ 使用硬體執行一般會有更好的性能，但將無法收集運行時對正被淘汰指令的使用統計數據。
+
+默認執行模式依賴於指令在構架中狀態。正在被淘汰的指令應該以模擬（Emulate）作爲默認模式，
+而已廢棄的指令必須默認使用未定義（Undef）模式
+
+注意：指令模擬可能無法應對所有情況。更多詳情請參考單獨的指令注釋。
+
+受支持的遺留指令
+-------------
+* SWP{B}
+節點: /proc/sys/abi/swp
+狀態: 已廢棄
+默認執行方式: Undef (0)
+
+* CP15 Barriers
+節點: /proc/sys/abi/cp15_barrier
+狀態: 正被淘汰，不推薦使用
+默認執行方式: Emulate (1)
+
+* SETEND
+節點: /proc/sys/abi/setend
+狀態: 正被淘汰，不推薦使用
+默認執行方式: Emulate (1)*
+註：爲了使能這個特性，系統中的所有 CPU 必須在 EL0 支持混合字節序。
+如果一個新的 CPU （不支持混合字節序） 在使能這個特性後被熱插入系統，
+在應用中可能會出現不可預期的結果。
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/memory.txt b/Documentation/translations/zh_TW/arch/arm64/memory.txt
new file mode 100644
index 0000000..2437380a
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/memory.txt
@@ -0,0 +1,119 @@
+SPDX-License-Identifier: GPL-2.0
+
+Chinese translated version of Documentation/arch/arm64/memory.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Catalin Marinas <catalin.marinas@arm.com>
+Chinese maintainer: Fu Wei <wefu@redhat.com>
+Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+---------------------------------------------------------------------
+Documentation/arch/arm64/memory.rst 的中文翻譯
+
+如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
+交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
+譯存在問題，請聯繫中文版維護者。
+
+本文翻譯提交時的 Git 檢出點爲： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
+
+英文版維護者： Catalin Marinas <catalin.marinas@arm.com>
+中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+
+以下爲正文
+---------------------------------------------------------------------
+ Linux 在 AArch64 中的內存布局
+ ===========================
+
+作者: Catalin Marinas <catalin.marinas@arm.com>
+
+本文檔描述 AArch64 Linux 內核所使用的虛擬內存布局。此構架可以實現
+頁大小爲 4KB 的 4 級轉換表和頁大小爲 64KB 的 3 級轉換表。
+
+AArch64 Linux 使用 3 級或 4 級轉換表，其頁大小配置爲 4KB，對於用戶和內核
+分別都有 39-bit (512GB) 或 48-bit (256TB) 的虛擬地址空間。
+對於頁大小爲 64KB的配置，僅使用 2 級轉換表，有 42-bit (4TB) 的虛擬地址空間，但內存布局相同。
+
+用戶地址空間的 63:48 位爲 0，而內核地址空間的相應位爲 1。TTBRx 的
+選擇由虛擬地址的 63 位給出。swapper_pg_dir 僅包含內核（全局）映射，
+而用戶 pgd 僅包含用戶（非全局）映射。swapper_pg_dir 地址被寫入
+TTBR1 中，且從不寫入 TTBR0。
+
+
+AArch64 Linux 在頁大小爲 4KB，並使用 3 級轉換表時的內存布局：
+
+起始地址 結束地址 大小 用途
+-----------------------------------------------------------------------
+0000000000000000 0000007fffffffff 512GB 用戶空間
+ffffff8000000000 ffffffffffffffff 512GB 內核空間
+
+
+AArch64 Linux 在頁大小爲 4KB，並使用 4 級轉換表時的內存布局：
+
+起始地址 結束地址 大小 用途
+-----------------------------------------------------------------------
+0000000000000000 0000ffffffffffff 256TB 用戶空間
+ffff000000000000 ffffffffffffffff 256TB 內核空間
+
+
+AArch64 Linux 在頁大小爲 64KB，並使用 2 級轉換表時的內存布局：
+
+起始地址 結束地址 大小 用途
+-----------------------------------------------------------------------
+0000000000000000 000003ffffffffff 4TB 用戶空間
+fffffc0000000000 ffffffffffffffff 4TB 內核空間
+
+
+AArch64 Linux 在頁大小爲 64KB，並使用 3 級轉換表時的內存布局：
+
+起始地址 結束地址 大小 用途
+-----------------------------------------------------------------------
+0000000000000000 0000ffffffffffff 256TB 用戶空間
+ffff000000000000 ffffffffffffffff 256TB 內核空間
+
+
+更詳細的內核虛擬內存布局，請參閱內核啓動信息。
+
+
+4KB 頁大小的轉換表查找：
+
++--------+--------+--------+--------+--------+--------+--------+--------+
+|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
++--------+--------+--------+--------+--------+--------+--------+--------+
+ | | | | | |
+ | | | | | v
+ | | | | | [11:0] 頁內偏移
+ | | | | +-> [20:12] L3 索引
+ | | | +-----------> [29:21] L2 索引
+ | | +---------------------> [38:30] L1 索引
+ | +-------------------------------> [47:39] L0 索引
+ +-------------------------------------------------> [63] TTBR0/1
+
+
+64KB 頁大小的轉換表查找：
+
++--------+--------+--------+--------+--------+--------+--------+--------+
+|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
++--------+--------+--------+--------+--------+--------+--------+--------+
+ | | | | |
+ | | | | v
+ | | | | [15:0] 頁內偏移
+ | | | +----------> [28:16] L3 索引
+ | | +--------------------------> [41:29] L2 索引
+ | +-------------------------------> [47:42] L1 索引
+ +-------------------------------------------------> [63] TTBR0/1
+
+
+當使用 KVM 時, 管理程序（hypervisor）在 EL2 中通過相對內核虛擬地址的
+一個固定偏移來映射內核頁（內核虛擬地址的高 24 位設爲零）:
+
+起始地址 結束地址 大小 用途
+-----------------------------------------------------------------------
+0000004000000000 0000007fffffffff 256GB 在 HYP 中映射的內核對象
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/perf.rst b/Documentation/translations/zh_TW/arch/arm64/perf.rst
new file mode 100644
index 0000000..3b39997
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/perf.rst
@@ -0,0 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_TW.rst
+
+:Original: :ref:`Documentation/arch/arm64/perf.rst <perf_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+ Hu Haowen <src.res@email.cn>
+
+=============
+Perf 事件屬性
+=============
+
+:作者: Andrew Murray <andrew.murray@arm.com>
+:日期: 2019-03-06
+
+exclude_user
+------------
+
+該屬性排除用戶空間。
+
+用戶空間始終運行在 EL0，因此該屬性將排除 EL0。
+
+
+exclude_kernel
+--------------
+
+該屬性排除內核空間。
+
+打開 VHE 時內核運行在 EL2，不打開 VHE 時內核運行在 EL1。客戶機
+內核總是運行在 EL1。
+
+對於宿主機，該屬性排除 EL1 和 VHE 上的 EL2。
+
+對於客戶機，該屬性排除 EL1。請注意客戶機從來不會運行在 EL2。
+
+
+exclude_hv
+----------
+
+該屬性排除虛擬機監控器。
+
+對於 VHE 宿主機該屬性將被忽略，此時我們認爲宿主機內核是虛擬機監
+控器。
+
+對於 non-VHE 宿主機該屬性將排除 EL2，因爲虛擬機監控器運行在 EL2
+的任何代碼主要用於客戶機和宿主機的切換。
+
+對於客戶機該屬性無效。請注意客戶機從來不會運行在 EL2。
+
+
+exclude_host / exclude_guest
+----------------------------
+
+這些屬性分別排除了 KVM 宿主機和客戶機。
+
+KVM 宿主機可能運行在 EL0（用戶空間），EL1（non-VHE 內核）和
+EL2（VHE 內核 或 non-VHE 虛擬機監控器）。
+
+KVM 客戶機可能運行在 EL0（用戶空間）和 EL1（內核）。
+
+由於宿主機和客戶機之間重疊的異常級別，我們不能僅僅依靠 PMU 的硬體異
+常過濾機制-因此我們必須啓用/禁用對於客戶機進入和退出的計數。而這在
+VHE 和 non-VHE 系統上表現不同。
+
+對於 non-VHE 系統的 exclude_host 屬性排除 EL2 - 在進入和退出客戶
+機時，我們會根據 exclude_host 和 exclude_guest 屬性在適當的情況下
+禁用/啓用該事件。
+
+對於 VHE 系統的 exclude_guest 屬性排除 EL1，而對其中的 exclude_host
+屬性同時排除 EL0，EL2。在進入和退出客戶機時，我們會適當地根據
+exclude_host 和 exclude_guest 屬性包括/排除 EL0。
+
+以上聲明也適用於在 not-VHE 客戶機使用這些屬性時，但是請注意客戶機從
+來不會運行在 EL2。
+
+
+準確性
+------
+
+在 non-VHE 宿主機上，我們在 EL2 進入/退出宿主機/客戶機的切換時啓用/
+關閉計數器 -但是在啓用/禁用計數器和進入/退出客戶機之間存在一段延時。
+對於 exclude_host， 我們可以通過過濾 EL2 消除在客戶機進入/退出邊界
+上用於計數客戶機事件的宿主機事件計數器。但是當使用 !exclude_hv 時，
+在客戶機進入/退出有一個小的停電窗口無法捕獲到宿主機的事件。
+
+在 VHE 系統沒有停電窗口。
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
new file mode 100644
index 0000000..66c3a35
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
@@ -0,0 +1,79 @@
+SPDX-License-Identifier: GPL-2.0
+
+Chinese translated version of Documentation/arch/arm64/silicon-errata.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+M: Will Deacon <will.deacon@arm.com>
+zh_CN: Fu Wei <wefu@redhat.com>
+zh_TW: Hu Haowen <src.res@email.cn>
+C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
+---------------------------------------------------------------------
+Documentation/arch/arm64/silicon-errata.rst 的中文翻譯
+
+如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
+交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
+譯存在問題，請聯繫中文版維護者。
+
+英文版維護者： Will Deacon <will.deacon@arm.com>
+中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+本文翻譯提交時的 Git 檢出點爲： 1926e54f115725a9248d0c4c65c22acaf94de4c4
+
+以下爲正文
+---------------------------------------------------------------------
+ 晶片勘誤和軟體補救措施
+ ==================
+
+作者: Will Deacon <will.deacon@arm.com>
+日期: 2015年11月27日
+
+一個不幸的現實：硬體經常帶有一些所謂的「瑕疵（errata）」，導致其在
+某些特定情況下會違背構架定義的行爲。就基於 ARM 的硬體而言，這些瑕疵
+大體可分爲以下幾類：
+
+ A 類：無可行補救措施的嚴重缺陷。
+ B 類：有可接受的補救措施的重大或嚴重缺陷。
+ C 類：在正常操作中不會顯現的小瑕疵。
+
+更多資訊，請在 infocenter.arm.com （需註冊）中查閱「軟體開發者勘誤
+筆記」（「Software Developers Errata Notice」）文檔。
+
+對於 Linux 而言，B 類缺陷可能需要作業系統的某些特別處理。例如，避免
+一個特殊的代碼序列，或是以一種特定的方式配置處理器。在某種不太常見的
+情況下，爲將 A 類缺陷當作 C 類處理，可能需要用類似的手段。這些手段被
+統稱爲「軟體補救措施」，且僅在少數情況需要（例如，那些需要一個運行在
+非安全異常級的補救措施 *並且* 能被 Linux 觸發的情況）。
+
+對於尚在討論中的可能對未受瑕疵影響的系統產生干擾的軟體補救措施，有一個
+相應的內核配置（Kconfig）選項被加在 「內核特性（Kernel Features）」->
+「基於可選方法框架的 ARM 瑕疵補救措施（ARM errata workarounds via
+the alternatives framework）"。這些選項被默認開啓，若探測到受影響的CPU，
+補丁將在運行時被使用。至於對系統運行影響較小的補救措施，內核配置選項
+並不存在，且代碼以某種規避瑕疵的方式被構造（帶注釋爲宜）。
+
+這種做法對於在任意內核原始碼樹中準確地判斷出哪個瑕疵已被軟體方法所補救
+稍微有點麻煩，所以在 Linux 內核中此文件作爲軟體補救措施的註冊表，
+並將在新的軟體補救措施被提交和向後移植（backported）到穩定內核時被更新。
+
+| 實現者 | 受影響的組件 | 勘誤編號 | 內核配置 |
++----------------+-----------------+-----------------+-------------------------+
+| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
+| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
+| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
+| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
+| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
+| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
+| ARM | Cortex-A57 | #852523 | N/A |
+| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
+| | | | |
+| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
+| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
+
diff --git a/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt b/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt
new file mode 100644
index 0000000..b7f683f
--- /dev/null
+++ b/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt
@@ -0,0 +1,57 @@
+SPDX-License-Identifier: GPL-2.0
+
+Chinese translated version of Documentation/arch/arm64/tagged-pointers.rst
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly. However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help. Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Maintainer: Will Deacon <will.deacon@arm.com>
+Chinese maintainer: Fu Wei <wefu@redhat.com>
+Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+---------------------------------------------------------------------
+Documentation/arch/arm64/tagged-pointers.rst 的中文翻譯
+
+如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
+交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
+譯存在問題，請聯繫中文版維護者。
+
+英文版維護者： Will Deacon <will.deacon@arm.com>
+中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
+中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+
+以下爲正文
+---------------------------------------------------------------------
+ Linux 在 AArch64 中帶標記的虛擬地址
+ =================================
+
+作者: Will Deacon <will.deacon@arm.com>
+日期: 2013 年 06 月 12 日
+
+本文檔簡述了在 AArch64 地址轉換系統中提供的帶標記的虛擬地址及其在
+AArch64 Linux 中的潛在用途。
+
+內核提供的地址轉換表配置使通過 TTBR0 完成的虛擬地址轉換（即用戶空間
+映射），其虛擬地址的最高 8 位（63:56）會被轉換硬體所忽略。這種機制
+讓這些位可供應用程式自由使用，其注意事項如下：
+
+ (1) 內核要求所有傳遞到 EL1 的用戶空間地址帶有 0x00 標記。
+ 這意味著任何攜帶用戶空間虛擬地址的系統調用（syscall）
+ 參數 *必須* 在陷入內核前使它們的最高字節被清零。
+
+ (2) 非零標記在傳遞信號時不被保存。這意味著在應用程式中利用了
+ 標記的信號處理函數無法依賴 siginfo_t 的用戶空間虛擬
+ 地址所攜帶的包含其內部域信息的標記。此規則的一個例外是
+ 當信號是在調試觀察點的異常處理程序中產生的，此時標記的
+ 信息將被保存。
+
+ (3) 當使用帶標記的指針時需特別留心，因爲僅對兩個虛擬地址
+ 的高字節，C 編譯器很可能無法判斷它們是不同的。
+
+此構架會阻止對帶標記的 PC 指針的利用，因此在異常返回時，其高字節
+將被設置成一個爲 「55」 的擴展符。
+
diff --git a/Documentation/translations/zh_TW/arm64/amu.rst b/Documentation/translations/zh_TW/arm64/amu.rst
deleted file mode 100644
index ffdc466..0000000
--- a/Documentation/translations/zh_TW/arm64/amu.rst
+++ /dev/null
@@ -1,104 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_TW.rst
-
-:Original: :ref:`Documentation/arm64/amu.rst <amu_index>`
-
-Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
-
-==================================
-AArch64 Linux 中擴展的活動監控單元
-==================================
-
-作者: Ionela Voinescu <ionela.voinescu@arm.com>
-
-日期: 2019-09-10
-
-本文檔簡要描述了 AArch64 Linux 支持的活動監控單元的規範。
-
-
-架構總述
---------
-
-活動監控是 ARMv8.4 CPU 架構引入的一個可選擴展特性。
-
-活動監控單元(在每個 CPU 中實現)爲系統管理提供了性能計數器。既可以通
-過系統寄存器的方式訪問計數器，同時也支持外部內存映射的方式訪問計數器。
-
-AMUv1 架構實現了一個由4個固定的64位事件計數器組成的計數器組。
-
- - CPU 周期計數器：同 CPU 的頻率增長
- - 常量計數器：同固定的系統時鐘頻率增長
- - 淘汰指令計數器: 同每次架構指令執行增長
- - 內存停頓周期計數器：計算由在時鐘域內的最後一級緩存中未命中而引起
- 的指令調度停頓周期數
-
-當處於 WFI 或者 WFE 狀態時，計數器不會增長。
-
-AMU 架構提供了一個高達16位的事件計數器空間，未來新的 AMU 版本中可能
-用它來實現新增的事件計數器。
-
-另外，AMUv1 實現了一個多達16個64位輔助事件計數器的計數器組。
-
-冷復位時所有的計數器會清零。
-
-
-基本支持
---------
-
-內核可以安全地運行在支持 AMU 和不支持 AMU 的 CPU 組合中。
-因此，當配置 CONFIG_ARM64_AMU_EXTN 後我們無條件使能後續
-(secondary or hotplugged) CPU 檢測和使用這個特性。
-
-當在 CPU 上檢測到該特性時，我們會標記爲特性可用但是不能保證計數器的功能，
-僅表明有擴展屬性。
-
-固件(代碼運行在高異常級別，例如 arm-tf )需支持以下功能：
-
- - 提供低異常級別(EL2 和 EL1)訪問 AMU 寄存器的能力。
- - 使能計數器。如果未使能，它的值應爲 0。
- - 在從電源關閉狀態啓動 CPU 前或後保存或者恢復計數器。
-
-當使用使能了該特性的內核啓動但固件損壞時，訪問計數器寄存器可能會遭遇
-panic 或者死鎖。即使未發現這些症狀，計數器寄存器返回的數據結果並不一
-定能反映真實情況。通常，計數器會返回 0，表明他們未被使能。
-
-如果固件沒有提供適當的支持最好關閉 CONFIG_ARM64_AMU_EXTN。
-值得注意的是，出於安全原因，不要繞過 AMUSERRENR_EL0 設置而捕獲從
-EL0(用戶空間) 訪問 EL1(內核空間)。 因此，固件應該確保訪問 AMU寄存器
-不會困在 EL2或EL3。
-
-AMUv1 的固定計數器可以通過如下系統寄存器訪問：
-
- - SYS_AMEVCNTR0_CORE_EL0
- - SYS_AMEVCNTR0_CONST_EL0
- - SYS_AMEVCNTR0_INST_RET_EL0
- - SYS_AMEVCNTR0_MEM_STALL_EL0
-
-特定輔助計數器可以通過 SYS_AMEVCNTR1_EL0(n) 訪問，其中n介於0到15。
-
-詳細信息定義在目錄：arch/arm64/include/asm/sysreg.h。
-
-
-用戶空間訪問
-------------
-
-由於以下原因，當前禁止從用戶空間訪問 AMU 的寄存器：
-
- - 安全因數：可能會暴露處於安全模式執行的代碼信息。
- - 意願：AMU 是用於系統管理的。
-
-同樣，該功能對用戶空間不可見。
-
-
-虛擬化
-------
-
-由於以下原因，當前禁止從 KVM 客戶端的用戶空間(EL0)和內核空間(EL1)
-訪問 AMU 的寄存器：
-
- - 安全因數：可能會暴露給其他客戶端或主機端執行的代碼信息。
-
-任何試圖訪問 AMU 寄存器的行爲都會觸發一個註冊在客戶端的未定義異常。
-
diff --git a/Documentation/translations/zh_TW/arm64/booting.txt b/Documentation/translations/zh_TW/arm64/booting.txt
deleted file mode 100644
index b9439dd..0000000
--- a/Documentation/translations/zh_TW/arm64/booting.txt
+++ /dev/null
@@ -1,251 +0,0 @@
-SPDX-License-Identifier: GPL-2.0
-
-Chinese translated version of Documentation/arm64/booting.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-M: Will Deacon <will.deacon@arm.com>
-zh_CN: Fu Wei <wefu@redhat.com>
-zh_TW: Hu Haowen <src.res@email.cn>
-C: 55f058e7574c3615dea4615573a19bdb258696c6
----------------------------------------------------------------------
-Documentation/arm64/booting.rst 的中文翻譯
-
-如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
-交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
-譯存在問題，請聯繫中文版維護者。
-
-英文版維護者： Will Deacon <will.deacon@arm.com>
-中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
-本文翻譯提交時的 Git 檢出點爲： 55f058e7574c3615dea4615573a19bdb258696c6
-
-以下爲正文
----------------------------------------------------------------------
- 啓動 AArch64 Linux
- ==================
-
-作者: Will Deacon <will.deacon@arm.com>
-日期: 2012 年 09 月 07 日
-
-本文檔基於 Russell King 的 ARM 啓動文檔，且適用於所有公開發布的
-AArch64 Linux 內核代碼。
-
-AArch64 異常模型由多個異常級（EL0 - EL3）組成，對於 EL0 和 EL1 異常級
-有對應的安全和非安全模式。EL2 是系統管理級，且僅存在於非安全模式下。
-EL3 是最高特權級，且僅存在於安全模式下。
-
-基於本文檔的目的，我們將簡單地使用『引導裝載程序』（『boot loader』）
-這個術語來定義在將控制權交給 Linux 內核前 CPU 上執行的所有軟體。
-這可能包含安全監控和系統管理代碼，或者它可能只是一些用於準備最小啓動
-環境的指令。
-
-基本上，引導裝載程序（至少）應實現以下操作：
-
-1、設置和初始化 RAM
-2、設置設備樹數據
-3、解壓內核映像
-4、調用內核映像
-
-
-1、設置和初始化 RAM
------------------
-
-必要性: 強制
-
-引導裝載程序應該找到並初始化系統中所有內核用於保持系統變量數據的 RAM。
-這個操作的執行方式因設備而異。（它可能使用內部算法來自動定位和計算所有
-RAM，或可能使用對這個設備已知的 RAM 信息，還可能是引導裝載程序設計者
-想到的任何合適的方法。）
-
-
-2、設置設備樹數據
----------------
-
-必要性: 強制
-
-設備樹數據塊（dtb）必須 8 字節對齊，且大小不能超過 2MB。由於設備樹
-數據塊將在使能緩存的情況下以 2MB 粒度被映射，故其不能被置於必須以特定
-屬性映射的2M區域內。
-
-註： v4.2 之前的版本同時要求設備樹數據塊被置於從內核映像以下
-text_offset 字節處算起第一個 512MB 內。
-
-3、解壓內核映像
--------------
-
-必要性: 可選
-
-AArch64 內核當前沒有提供自解壓代碼，因此如果使用了壓縮內核映像文件
-（比如 Image.gz），則需要通過引導裝載程序（使用 gzip 等）來進行解壓。
-若引導裝載程序沒有實現這個功能，就要使用非壓縮內核映像文件。
-
-
-4、調用內核映像
--------------
-
-必要性: 強制
-
-已解壓的內核映像包含一個 64 字節的頭，內容如下：
-
- u32 code0; /* 可執行代碼 */
- u32 code1; /* 可執行代碼 */
- u64 text_offset; /* 映像裝載偏移，小端模式 */
- u64 image_size; /* 映像實際大小, 小端模式 */
- u64 flags; /* 內核旗標, 小端模式 *
- u64 res2 = 0; /* 保留 */
- u64 res3 = 0; /* 保留 */
- u64 res4 = 0; /* 保留 */
- u32 magic = 0x644d5241; /* 魔數, 小端, "ARM\x64" */
- u32 res5; /* 保留 （用於 PE COFF 偏移） */
-
-
-映像頭注釋：
-
-- 自 v3.17 起，除非另有說明，所有域都是小端模式。
-
-- code0/code1 負責跳轉到 stext.
-
-- 當通過 EFI 啓動時， 最初 code0/code1 被跳過。
- res5 是到 PE 文件頭的偏移，而 PE 文件頭含有 EFI 的啓動入口點
- （efi_stub_entry）。當 stub 代碼完成了它的使命，它會跳轉到 code0
- 繼續正常的啓動流程。
-
-- v3.17 之前，未明確指定 text_offset 的字節序。此時，image_size 爲零，
- 且 text_offset 依照內核字節序爲 0x80000。
- 當 image_size 非零，text_offset 爲小端模式且是有效值，應被引導加載
- 程序使用。當 image_size 爲零，text_offset 可假定爲 0x80000。
-
-- flags 域 (v3.17 引入) 爲 64 位小端模式，其編碼如下：
- 位 0: 內核字節序。 1 表示大端模式，0 表示小端模式。
- 位 1-2: 內核頁大小。
- 0 - 未指定。
- 1 - 4K
- 2 - 16K
- 3 - 64K
- 位 3: 內核物理位置
- 0 - 2MB 對齊基址應儘量靠近內存起始處，因爲
- 其基址以下的內存無法通過線性映射訪問
- 1 - 2MB 對齊基址可以在物理內存的任意位置
- 位 4-63: 保留。
-
-- 當 image_size 爲零時，引導裝載程序應試圖在內核映像末尾之後儘可能
- 多地保留空閒內存供內核直接使用。對內存空間的需求量因所選定的內核
- 特性而異, 並無實際限制。
-
-內核映像必須被放置在任意一個可用系統內存 2MB 對齊基址的 text_offset
-字節處，並從該處被調用。2MB 對齊基址和內核映像起始地址之間的區域對於
-內核來說沒有特殊意義，且可能被用於其他目的。
-從映像起始地址算起，最少必須準備 image_size 字節的空閒內存供內核使用。
-註： v4.6 之前的版本無法使用內核映像物理偏移以下的內存，所以當時建議
-將映像儘量放置在靠近系統內存起始的地方。
-
-任何提供給內核的內存（甚至在映像起始地址之前），若未從內核中標記爲保留
-(如在設備樹（dtb）的 memreserve 區域），都將被認爲對內核是可用。
-
-在跳轉入內核前，必須符合以下狀態：
-
-- 停止所有 DMA 設備，這樣內存數據就不會因爲虛假網絡包或磁碟數據而
- 被破壞。這可能可以節省你許多的調試時間。
-
-- 主 CPU 通用寄存器設置
- x0 = 系統 RAM 中設備樹數據塊（dtb）的物理地址。
- x1 = 0 (保留，將來可能使用)
- x2 = 0 (保留，將來可能使用)
- x3 = 0 (保留，將來可能使用)
-
-- CPU 模式
- 所有形式的中斷必須在 PSTATE.DAIF 中被屏蔽（Debug、SError、IRQ
- 和 FIQ）。
- CPU 必須處於 EL2（推薦，可訪問虛擬化擴展）或非安全 EL1 模式下。
-
-- 高速緩存、MMU
- MMU 必須關閉。
- 指令緩存開啓或關閉皆可。
- 已載入的內核映像的相應內存區必須被清理，以達到緩存一致性點（PoC）。
- 當存在系統緩存或其他使能緩存的一致性主控器時，通常需使用虛擬地址
- 維護其緩存，而非 set/way 操作。
- 遵從通過虛擬地址操作維護構架緩存的系統緩存必須被配置，並可以被使能。
- 而不通過虛擬地址操作維護構架緩存的系統緩存（不推薦），必須被配置且
- 禁用。
-
- *譯者註：對於 PoC 以及緩存相關內容，請參考 ARMv8 構架參考手冊
- ARM DDI 0487A
-
-- 架構計時器
- CNTFRQ 必須設定爲計時器的頻率，且 CNTVOFF 必須設定爲對所有 CPU
- 都一致的值。如果在 EL1 模式下進入內核，則 CNTHCTL_EL2 中的
- EL1PCTEN (bit 0) 必須置位。
-
-- 一致性
- 通過內核啓動的所有 CPU 在內核入口地址上必須處於相同的一致性域中。
- 這可能要根據具體實現來定義初始化過程，以使能每個CPU上對維護操作的
- 接收。
-
-- 系統寄存器
- 在進入內核映像的異常級中，所有構架中可寫的系統寄存器必須通過軟體
- 在一個更高的異常級別下初始化，以防止在 未知 狀態下運行。
-
- 對於擁有 GICv3 中斷控制器並以 v3 模式運行的系統：
- - 如果 EL3 存在：
- ICC_SRE_EL3.Enable (位 3) 必須初始化爲 0b1。
- ICC_SRE_EL3.SRE (位 0) 必須初始化爲 0b1。
- - 若內核運行在 EL1：
- ICC_SRE_EL2.Enable (位 3) 必須初始化爲 0b1。
- ICC_SRE_EL2.SRE (位 0) 必須初始化爲 0b1。
- - 設備樹（DT）或 ACPI 表必須描述一個 GICv3 中斷控制器。
-
- 對於擁有 GICv3 中斷控制器並以兼容（v2）模式運行的系統：
- - 如果 EL3 存在：
- ICC_SRE_EL3.SRE (位 0) 必須初始化爲 0b0。
- - 若內核運行在 EL1：
- ICC_SRE_EL2.SRE (位 0) 必須初始化爲 0b0。
- - 設備樹（DT）或 ACPI 表必須描述一個 GICv2 中斷控制器。
-
-以上對於 CPU 模式、高速緩存、MMU、架構計時器、一致性、系統寄存器的
-必要條件描述適用於所有 CPU。所有 CPU 必須在同一異常級別跳入內核。
-
-引導裝載程序必須在每個 CPU 處於以下狀態時跳入內核入口：
-
-- 主 CPU 必須直接跳入內核映像的第一條指令。通過此 CPU 傳遞的設備樹
- 數據塊必須在每個 CPU 節點中包含一個 『enable-method』 屬性，所
- 支持的 enable-method 請見下文。
-
- 引導裝載程序必須生成這些設備樹屬性，並在跳入內核入口之前將其插入
- 數據塊。
-
-- enable-method 爲 「spin-table」 的 CPU 必須在它們的 CPU
- 節點中包含一個 『cpu-release-addr』 屬性。這個屬性標識了一個
- 64 位自然對齊且初始化爲零的內存位置。
-
- 這些 CPU 必須在內存保留區（通過設備樹中的 /memreserve/ 域傳遞
- 給內核）中自旋於內核之外，輪詢它們的 cpu-release-addr 位置（必須
- 包含在保留區中）。可通過插入 wfe 指令來降低忙循環開銷，而主 CPU 將
- 發出 sev 指令。當對 cpu-release-addr 所指位置的讀取操作返回非零值
- 時，CPU 必須跳入此值所指向的地址。此值爲一個單獨的 64 位小端值，
- 因此 CPU 須在跳轉前將所讀取的值轉換爲其本身的端模式。
-
-- enable-method 爲 「psci」 的 CPU 保持在內核外（比如，在
- memory 節點中描述爲內核空間的內存區外，或在通過設備樹 /memreserve/
- 域中描述爲內核保留區的空間中）。內核將會發起在 ARM 文檔（編號
- ARM DEN 0022A：用於 ARM 上的電源狀態協調接口系統軟體）中描述的
- CPU_ON 調用來將 CPU 帶入內核。
-
- *譯者注: ARM DEN 0022A 已更新到 ARM DEN 0022C。
-
- 設備樹必須包含一個 『psci』 節點，請參考以下文檔：
- Documentation/devicetree/bindings/arm/psci.yaml
-
-
-- 輔助 CPU 通用寄存器設置
- x0 = 0 (保留，將來可能使用)
- x1 = 0 (保留，將來可能使用)
- x2 = 0 (保留，將來可能使用)
- x3 = 0 (保留，將來可能使用)
-
diff --git a/Documentation/translations/zh_TW/arm64/elf_hwcaps.rst b/Documentation/translations/zh_TW/arm64/elf_hwcaps.rst
deleted file mode 100644
index 3eb1c62..0000000
--- a/Documentation/translations/zh_TW/arm64/elf_hwcaps.rst
+++ /dev/null
@@ -1,244 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_TW.rst
-
-:Original: :ref:`Documentation/arm64/elf_hwcaps.rst <elf_hwcaps_index>`
-
-Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
-
-================
-ARM64 ELF hwcaps
-================
-
-這篇文檔描述了 arm64 ELF hwcaps 的用法和語義。
-
-
-1. 簡介
--------
-
-有些硬體或軟體功能僅在某些 CPU 實現上和/或在具體某個內核配置上可用，但
-對於處於 EL0 的用戶空間代碼沒有可用的架構發現機制。內核通過在輔助向量表
-公開一組稱爲 hwcaps 的標誌而把這些功能暴露給用戶空間。
-
-用戶空間軟體可以通過獲取輔助向量的 AT_HWCAP 或 AT_HWCAP2 條目來測試功能，
-並測試是否設置了相關標誌，例如::
-
- bool floating_point_is_present(void)
- {
- unsigned long hwcaps = getauxval(AT_HWCAP);
- if (hwcaps & HWCAP_FP)
- return true;
-
- return false;
- }
-
-如果軟體依賴於 hwcap 描述的功能，在嘗試使用該功能前則應檢查相關的 hwcap
-標誌以驗證該功能是否存在。
-
-不能通過其他方式探查這些功能。當一個功能不可用時，嘗試使用它可能導致不可
-預測的行爲，並且無法保證能確切的知道該功能不可用，例如 SIGILL。
-
-
-2. Hwcaps 的說明
-----------------
-
-大多數 hwcaps 旨在說明通過架構 ID 寄存器(處於 EL0 的用戶空間代碼無法訪問)
-描述的功能的存在。這些 hwcap 通過 ID 寄存器欄位定義，並且應根據 ARM 體系
-結構參考手冊（ARM ARM）中定義的欄位來解釋說明。
-
-這些 hwcaps 以下面的形式描述::
-
- idreg.field == val 表示有某個功能。
-
-當 idreg.field 中有 val 時，hwcaps 表示 ARM ARM 定義的功能是有效的，但是
-並不是說要完全和 val 相等，也不是說 idreg.field 描述的其他功能就是缺失的。
-
-其他 hwcaps 可能表明無法僅由 ID 寄存器描述的功能的存在。這些 hwcaps 可能
-沒有被 ID 寄存器描述，需要參考其他文檔。
-
-
-3. AT_HWCAP 中揭示的 hwcaps
----------------------------
-
-HWCAP_FP
- ID_AA64PFR0_EL1.FP == 0b0000 表示有此功能。
-
-HWCAP_ASIMD
- ID_AA64PFR0_EL1.AdvSIMD == 0b0000 表示有此功能。
-
-HWCAP_EVTSTRM
- 通用計時器頻率配置爲大約100KHz以生成事件。
-
-HWCAP_AES
- ID_AA64ISAR0_EL1.AES == 0b0001 表示有此功能。
-
-HWCAP_PMULL
- ID_AA64ISAR0_EL1.AES == 0b0010 表示有此功能。
-
-HWCAP_SHA1
- ID_AA64ISAR0_EL1.SHA1 == 0b0001 表示有此功能。
-
-HWCAP_SHA2
- ID_AA64ISAR0_EL1.SHA2 == 0b0001 表示有此功能。
-
-HWCAP_CRC32
- ID_AA64ISAR0_EL1.CRC32 == 0b0001 表示有此功能。
-
-HWCAP_ATOMICS
- ID_AA64ISAR0_EL1.Atomic == 0b0010 表示有此功能。
-
-HWCAP_FPHP
- ID_AA64PFR0_EL1.FP == 0b0001 表示有此功能。
-
-HWCAP_ASIMDHP
- ID_AA64PFR0_EL1.AdvSIMD == 0b0001 表示有此功能。
-
-HWCAP_CPUID
- 根據 Documentation/arm64/cpu-feature-registers.rst 描述，EL0 可以訪問
- 某些 ID 寄存器。
-
- 這些 ID 寄存器可能表示功能的可用性。
-
-HWCAP_ASIMDRDM
- ID_AA64ISAR0_EL1.RDM == 0b0001 表示有此功能。
-
-HWCAP_JSCVT
- ID_AA64ISAR1_EL1.JSCVT == 0b0001 表示有此功能。
-
-HWCAP_FCMA
- ID_AA64ISAR1_EL1.FCMA == 0b0001 表示有此功能。
-
-HWCAP_LRCPC
- ID_AA64ISAR1_EL1.LRCPC == 0b0001 表示有此功能。
-
-HWCAP_DCPOP
- ID_AA64ISAR1_EL1.DPB == 0b0001 表示有此功能。
-
-HWCAP_SHA3
- ID_AA64ISAR0_EL1.SHA3 == 0b0001 表示有此功能。
-
-HWCAP_SM3
- ID_AA64ISAR0_EL1.SM3 == 0b0001 表示有此功能。
-
-HWCAP_SM4
- ID_AA64ISAR0_EL1.SM4 == 0b0001 表示有此功能。
-
-HWCAP_ASIMDDP
- ID_AA64ISAR0_EL1.DP == 0b0001 表示有此功能。
-
-HWCAP_SHA512
- ID_AA64ISAR0_EL1.SHA2 == 0b0010 表示有此功能。
-
-HWCAP_SVE
- ID_AA64PFR0_EL1.SVE == 0b0001 表示有此功能。
-
-HWCAP_ASIMDFHM
- ID_AA64ISAR0_EL1.FHM == 0b0001 表示有此功能。
-
-HWCAP_DIT
- ID_AA64PFR0_EL1.DIT == 0b0001 表示有此功能。
-
-HWCAP_USCAT
- ID_AA64MMFR2_EL1.AT == 0b0001 表示有此功能。
-
-HWCAP_ILRCPC
- ID_AA64ISAR1_EL1.LRCPC == 0b0010 表示有此功能。
-
-HWCAP_FLAGM
- ID_AA64ISAR0_EL1.TS == 0b0001 表示有此功能。
-
-HWCAP_SSBS
- ID_AA64PFR1_EL1.SSBS == 0b0010 表示有此功能。
-
-HWCAP_SB
- ID_AA64ISAR1_EL1.SB == 0b0001 表示有此功能。
-
-HWCAP_PACA
- 如 Documentation/arm64/pointer-authentication.rst 所描述，
- ID_AA64ISAR1_EL1.APA == 0b0001 或 ID_AA64ISAR1_EL1.API == 0b0001
- 表示有此功能。
-
-HWCAP_PACG
- 如 Documentation/arm64/pointer-authentication.rst 所描述，
- ID_AA64ISAR1_EL1.GPA == 0b0001 或 ID_AA64ISAR1_EL1.GPI == 0b0001
- 表示有此功能。
-
-HWCAP2_DCPODP
-
- ID_AA64ISAR1_EL1.DPB == 0b0010 表示有此功能。
-
-HWCAP2_SVE2
-
- ID_AA64ZFR0_EL1.SVEVer == 0b0001 表示有此功能。
-
-HWCAP2_SVEAES
-
- ID_AA64ZFR0_EL1.AES == 0b0001 表示有此功能。
-
-HWCAP2_SVEPMULL
-
- ID_AA64ZFR0_EL1.AES == 0b0010 表示有此功能。
-
-HWCAP2_SVEBITPERM
-
- ID_AA64ZFR0_EL1.BitPerm == 0b0001 表示有此功能。
-
-HWCAP2_SVESHA3
-
- ID_AA64ZFR0_EL1.SHA3 == 0b0001 表示有此功能。
-
-HWCAP2_SVESM4
-
- ID_AA64ZFR0_EL1.SM4 == 0b0001 表示有此功能。
-
-HWCAP2_FLAGM2
-
- ID_AA64ISAR0_EL1.TS == 0b0010 表示有此功能。
-
-HWCAP2_FRINT
-
- ID_AA64ISAR1_EL1.FRINTTS == 0b0001 表示有此功能。
-
-HWCAP2_SVEI8MM
-
- ID_AA64ZFR0_EL1.I8MM == 0b0001 表示有此功能。
-
-HWCAP2_SVEF32MM
-
- ID_AA64ZFR0_EL1.F32MM == 0b0001 表示有此功能。
-
-HWCAP2_SVEF64MM
-
- ID_AA64ZFR0_EL1.F64MM == 0b0001 表示有此功能。
-
-HWCAP2_SVEBF16
-
- ID_AA64ZFR0_EL1.BF16 == 0b0001 表示有此功能。
-
-HWCAP2_I8MM
-
- ID_AA64ISAR1_EL1.I8MM == 0b0001 表示有此功能。
-
-HWCAP2_BF16
-
- ID_AA64ISAR1_EL1.BF16 == 0b0001 表示有此功能。
-
-HWCAP2_DGH
-
- ID_AA64ISAR1_EL1.DGH == 0b0001 表示有此功能。
-
-HWCAP2_RNG
-
- ID_AA64ISAR0_EL1.RNDR == 0b0001 表示有此功能。
-
-HWCAP2_BTI
-
- ID_AA64PFR0_EL1.BT == 0b0001 表示有此功能。
-
-
-4. 未使用的 AT_HWCAP 位
------------------------
-
-爲了與用戶空間交互，內核保證 AT_HWCAP 的第62、63位將始終返回0。
-
diff --git a/Documentation/translations/zh_TW/arm64/hugetlbpage.rst b/Documentation/translations/zh_TW/arm64/hugetlbpage.rst
deleted file mode 100644
index 846b500..0000000
--- a/Documentation/translations/zh_TW/arm64/hugetlbpage.rst
+++ /dev/null
@@ -1,49 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_TW.rst
-
-:Original: :ref:`Documentation/arm64/hugetlbpage.rst <hugetlbpage_index>`
-
-Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
-
-=====================
-ARM64中的 HugeTLBpage
-=====================
-
-大頁依靠有效利用 TLBs 來提高地址翻譯的性能。這取決於以下
-兩點 -
-
- - 大頁的大小
- - TLBs 支持的條目大小
-
-ARM64 接口支持2種大頁方式。
-
-1) pud/pmd 級別的塊映射
------------------------
-
-這是常規大頁，他們的 pmd 或 pud 頁面表條目指向一個內存塊。
-不管 TLB 中支持的條目大小如何，塊映射可以減少翻譯大頁地址
-所需遍歷的頁表深度。
-
-2) 使用連續位
--------------
-
-架構中轉換頁表條目(D4.5.3, ARM DDI 0487C.a)中提供一個連續
-位告訴 MMU 這個條目是一個連續條目集的一員，它可以被緩存在單
-個 TLB 條目中。
-
-在 Linux 中連續位用來增加 pmd 和 pte(最後一級)級別映射的大
-小。受支持的連續頁表條目數量因頁面大小和頁表級別而異。
-
-
-支持以下大頁尺寸配置 -
-
- ====== ======== ==== ======== ===
- - CONT PTE PMD CONT PMD PUD
- ====== ======== ==== ======== ===
- 4K: 64K 2M 32M 1G
- 16K: 2M 32M 1G
- 64K: 2M 512M 16G
- ====== ======== ==== ======== ===
-
diff --git a/Documentation/translations/zh_TW/arm64/index.rst b/Documentation/translations/zh_TW/arm64/index.rst
deleted file mode 100644
index 2322783..0000000
--- a/Documentation/translations/zh_TW/arm64/index.rst
+++ /dev/null
@@ -1,23 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_TW.rst
-
-:Original: :ref:`Documentation/arm64/index.rst <arm64_index>`
-:Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
-
-.. _tw_arm64_index:
-
-
-==========
-ARM64 架構
-==========
-
-.. toctree::
- :maxdepth: 2
-
- amu
- hugetlbpage
- perf
- elf_hwcaps
-
diff --git a/Documentation/translations/zh_TW/arm64/legacy_instructions.txt b/Documentation/translations/zh_TW/arm64/legacy_instructions.txt
deleted file mode 100644
index 6d4454f7..0000000
--- a/Documentation/translations/zh_TW/arm64/legacy_instructions.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-SPDX-License-Identifier: GPL-2.0
-
-Chinese translated version of Documentation/arm64/legacy_instructions.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-Maintainer: Punit Agrawal <punit.agrawal@arm.com>
- Suzuki K. Poulose <suzuki.poulose@arm.com>
-Chinese maintainer: Fu Wei <wefu@redhat.com>
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
----------------------------------------------------------------------
-Documentation/arm64/legacy_instructions.rst 的中文翻譯
-
-如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
-交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
-譯存在問題，請聯繫中文版維護者。
-
-本文翻譯提交時的 Git 檢出點爲： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
-
-英文版維護者： Punit Agrawal <punit.agrawal@arm.com>
- Suzuki K. Poulose <suzuki.poulose@arm.com>
-中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn>
-
-以下爲正文
----------------------------------------------------------------------
-Linux 內核在 arm64 上的移植提供了一個基礎框架，以支持構架中正在被淘汰或已廢棄指令的模擬執行。
-這個基礎框架的代碼使用未定義指令鉤子（hooks）來支持模擬。如果指令存在，它也允許在硬體中啓用該指令。
-
-模擬模式可通過寫 sysctl 節點（/proc/sys/abi）來控制。
-不同的執行方式及 sysctl 節點的相應值，解釋如下：
-
-* Undef（未定義）
- 值： 0
- 產生未定義指令終止異常。它是那些構架中已廢棄的指令，如 SWP，的默認處理方式。
-
-* Emulate（模擬）
- 值： 1
- 使用軟體模擬方式。爲解決軟體遷移問題，這種模擬指令模式的使用是被跟蹤的，並會發出速率限制警告。
- 它是那些構架中正在被淘汰的指令，如 CP15 barriers（隔離指令），的默認處理方式。
-
-* Hardware Execution（硬體執行）
- 值： 2
- 雖然標記爲正在被淘汰，但一些實現可能提供硬體執行這些指令的使能/禁用操作。
- 使用硬體執行一般會有更好的性能，但將無法收集運行時對正被淘汰指令的使用統計數據。
-
-默認執行模式依賴於指令在構架中狀態。正在被淘汰的指令應該以模擬（Emulate）作爲默認模式，
-而已廢棄的指令必須默認使用未定義（Undef）模式
-
-注意：指令模擬可能無法應對所有情況。更多詳情請參考單獨的指令注釋。
-
-受支持的遺留指令
--------------
-* SWP{B}
-節點: /proc/sys/abi/swp
-狀態: 已廢棄
-默認執行方式: Undef (0)
-
-* CP15 Barriers
-節點: /proc/sys/abi/cp15_barrier
-狀態: 正被淘汰，不推薦使用
-默認執行方式: Emulate (1)
-
-* SETEND
-節點: /proc/sys/abi/setend
-狀態: 正被淘汰，不推薦使用
-默認執行方式: Emulate (1)*
-註：爲了使能這個特性，系統中的所有 CPU 必須在 EL0 支持混合字節序。
-如果一個新的 CPU （不支持混合字節序） 在使能這個特性後被熱插入系統，
-在應用中可能會出現不可預期的結果。
-
diff --git a/Documentation/translations/zh_TW/arm64/memory.txt b/Documentation/translations/zh_TW/arm64/memory.txt
deleted file mode 100644
index 99c2b78..0000000
--- a/Documentation/translations/zh_TW/arm64/memory.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-SPDX-License-Identifier: GPL-2.0
-
-Chinese translated version of Documentation/arm64/memory.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-Maintainer: Catalin Marinas <catalin.marinas@arm.com>
-Chinese maintainer: Fu Wei <wefu@redhat.com>
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
----------------------------------------------------------------------
-Documentation/arm64/memory.rst 的中文翻譯
-
-如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
-交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
-譯存在問題，請聯繫中文版維護者。
-
-本文翻譯提交時的 Git 檢出點爲： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
-
-英文版維護者： Catalin Marinas <catalin.marinas@arm.com>
-中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
-
-以下爲正文
----------------------------------------------------------------------
- Linux 在 AArch64 中的內存布局
- ===========================
-
-作者: Catalin Marinas <catalin.marinas@arm.com>
-
-本文檔描述 AArch64 Linux 內核所使用的虛擬內存布局。此構架可以實現
-頁大小爲 4KB 的 4 級轉換表和頁大小爲 64KB 的 3 級轉換表。
-
-AArch64 Linux 使用 3 級或 4 級轉換表，其頁大小配置爲 4KB，對於用戶和內核
-分別都有 39-bit (512GB) 或 48-bit (256TB) 的虛擬地址空間。
-對於頁大小爲 64KB的配置，僅使用 2 級轉換表，有 42-bit (4TB) 的虛擬地址空間，但內存布局相同。
-
-用戶地址空間的 63:48 位爲 0，而內核地址空間的相應位爲 1。TTBRx 的
-選擇由虛擬地址的 63 位給出。swapper_pg_dir 僅包含內核（全局）映射，
-而用戶 pgd 僅包含用戶（非全局）映射。swapper_pg_dir 地址被寫入
-TTBR1 中，且從不寫入 TTBR0。
-
-
-AArch64 Linux 在頁大小爲 4KB，並使用 3 級轉換表時的內存布局：
-
-起始地址 結束地址 大小 用途
------------------------------------------------------------------------
-0000000000000000 0000007fffffffff 512GB 用戶空間
-ffffff8000000000 ffffffffffffffff 512GB 內核空間
-
-
-AArch64 Linux 在頁大小爲 4KB，並使用 4 級轉換表時的內存布局：
-
-起始地址 結束地址 大小 用途
------------------------------------------------------------------------
-0000000000000000 0000ffffffffffff 256TB 用戶空間
-ffff000000000000 ffffffffffffffff 256TB 內核空間
-
-
-AArch64 Linux 在頁大小爲 64KB，並使用 2 級轉換表時的內存布局：
-
-起始地址 結束地址 大小 用途
------------------------------------------------------------------------
-0000000000000000 000003ffffffffff 4TB 用戶空間
-fffffc0000000000 ffffffffffffffff 4TB 內核空間
-
-
-AArch64 Linux 在頁大小爲 64KB，並使用 3 級轉換表時的內存布局：
-
-起始地址 結束地址 大小 用途
------------------------------------------------------------------------
-0000000000000000 0000ffffffffffff 256TB 用戶空間
-ffff000000000000 ffffffffffffffff 256TB 內核空間
-
-
-更詳細的內核虛擬內存布局，請參閱內核啓動信息。
-
-
-4KB 頁大小的轉換表查找：
-
-+--------+--------+--------+--------+--------+--------+--------+--------+
-|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
-+--------+--------+--------+--------+--------+--------+--------+--------+
- | | | | | |
- | | | | | v
- | | | | | [11:0] 頁內偏移
- | | | | +-> [20:12] L3 索引
- | | | +-----------> [29:21] L2 索引
- | | +---------------------> [38:30] L1 索引
- | +-------------------------------> [47:39] L0 索引
- +-------------------------------------------------> [63] TTBR0/1
-
-
-64KB 頁大小的轉換表查找：
-
-+--------+--------+--------+--------+--------+--------+--------+--------+
-|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
-+--------+--------+--------+--------+--------+--------+--------+--------+
- | | | | |
- | | | | v
- | | | | [15:0] 頁內偏移
- | | | +----------> [28:16] L3 索引
- | | +--------------------------> [41:29] L2 索引
- | +-------------------------------> [47:42] L1 索引
- +-------------------------------------------------> [63] TTBR0/1
-
-
-當使用 KVM 時, 管理程序（hypervisor）在 EL2 中通過相對內核虛擬地址的
-一個固定偏移來映射內核頁（內核虛擬地址的高 24 位設爲零）:
-
-起始地址 結束地址 大小 用途
------------------------------------------------------------------------
-0000004000000000 0000007fffffffff 256GB 在 HYP 中映射的內核對象
-
diff --git a/Documentation/translations/zh_TW/arm64/perf.rst b/Documentation/translations/zh_TW/arm64/perf.rst
deleted file mode 100644
index f1ffd55..0000000
--- a/Documentation/translations/zh_TW/arm64/perf.rst
+++ /dev/null
@@ -1,88 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_TW.rst
-
-:Original: :ref:`Documentation/arm64/perf.rst <perf_index>`
-
-Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
-
-=============
-Perf 事件屬性
-=============
-
-:作者: Andrew Murray <andrew.murray@arm.com>
-:日期: 2019-03-06
-
-exclude_user
-------------
-
-該屬性排除用戶空間。
-
-用戶空間始終運行在 EL0，因此該屬性將排除 EL0。
-
-
-exclude_kernel
---------------
-
-該屬性排除內核空間。
-
-打開 VHE 時內核運行在 EL2，不打開 VHE 時內核運行在 EL1。客戶機
-內核總是運行在 EL1。
-
-對於宿主機，該屬性排除 EL1 和 VHE 上的 EL2。
-
-對於客戶機，該屬性排除 EL1。請注意客戶機從來不會運行在 EL2。
-
-
-exclude_hv
-----------
-
-該屬性排除虛擬機監控器。
-
-對於 VHE 宿主機該屬性將被忽略，此時我們認爲宿主機內核是虛擬機監
-控器。
-
-對於 non-VHE 宿主機該屬性將排除 EL2，因爲虛擬機監控器運行在 EL2
-的任何代碼主要用於客戶機和宿主機的切換。
-
-對於客戶機該屬性無效。請注意客戶機從來不會運行在 EL2。
-
-
-exclude_host / exclude_guest
-----------------------------
-
-這些屬性分別排除了 KVM 宿主機和客戶機。
-
-KVM 宿主機可能運行在 EL0（用戶空間），EL1（non-VHE 內核）和
-EL2（VHE 內核 或 non-VHE 虛擬機監控器）。
-
-KVM 客戶機可能運行在 EL0（用戶空間）和 EL1（內核）。
-
-由於宿主機和客戶機之間重疊的異常級別，我們不能僅僅依靠 PMU 的硬體異
-常過濾機制-因此我們必須啓用/禁用對於客戶機進入和退出的計數。而這在
-VHE 和 non-VHE 系統上表現不同。
-
-對於 non-VHE 系統的 exclude_host 屬性排除 EL2 - 在進入和退出客戶
-機時，我們會根據 exclude_host 和 exclude_guest 屬性在適當的情況下
-禁用/啓用該事件。
-
-對於 VHE 系統的 exclude_guest 屬性排除 EL1，而對其中的 exclude_host
-屬性同時排除 EL0，EL2。在進入和退出客戶機時，我們會適當地根據
-exclude_host 和 exclude_guest 屬性包括/排除 EL0。
-
-以上聲明也適用於在 not-VHE 客戶機使用這些屬性時，但是請注意客戶機從
-來不會運行在 EL2。
-
-
-準確性
-------
-
-在 non-VHE 宿主機上，我們在 EL2 進入/退出宿主機/客戶機的切換時啓用/
-關閉計數器 -但是在啓用/禁用計數器和進入/退出客戶機之間存在一段延時。
-對於 exclude_host， 我們可以通過過濾 EL2 消除在客戶機進入/退出邊界
-上用於計數客戶機事件的宿主機事件計數器。但是當使用 !exclude_hv 時，
-在客戶機進入/退出有一個小的停電窗口無法捕獲到宿主機的事件。
-
-在 VHE 系統沒有停電窗口。
-
diff --git a/Documentation/translations/zh_TW/arm64/silicon-errata.txt b/Documentation/translations/zh_TW/arm64/silicon-errata.txt
deleted file mode 100644
index bf20771..0000000
--- a/Documentation/translations/zh_TW/arm64/silicon-errata.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-SPDX-License-Identifier: GPL-2.0
-
-Chinese translated version of Documentation/arm64/silicon-errata.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-M: Will Deacon <will.deacon@arm.com>
-zh_CN: Fu Wei <wefu@redhat.com>
-zh_TW: Hu Haowen <src.res@email.cn>
-C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
----------------------------------------------------------------------
-Documentation/arm64/silicon-errata.rst 的中文翻譯
-
-如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
-交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
-譯存在問題，請聯繫中文版維護者。
-
-英文版維護者： Will Deacon <will.deacon@arm.com>
-中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
-本文翻譯提交時的 Git 檢出點爲： 1926e54f115725a9248d0c4c65c22acaf94de4c4
-
-以下爲正文
----------------------------------------------------------------------
- 晶片勘誤和軟體補救措施
- ==================
-
-作者: Will Deacon <will.deacon@arm.com>
-日期: 2015年11月27日
-
-一個不幸的現實：硬體經常帶有一些所謂的「瑕疵（errata）」，導致其在
-某些特定情況下會違背構架定義的行爲。就基於 ARM 的硬體而言，這些瑕疵
-大體可分爲以下幾類：
-
- A 類：無可行補救措施的嚴重缺陷。
- B 類：有可接受的補救措施的重大或嚴重缺陷。
- C 類：在正常操作中不會顯現的小瑕疵。
-
-更多資訊，請在 infocenter.arm.com （需註冊）中查閱「軟體開發者勘誤
-筆記」（「Software Developers Errata Notice」）文檔。
-
-對於 Linux 而言，B 類缺陷可能需要作業系統的某些特別處理。例如，避免
-一個特殊的代碼序列，或是以一種特定的方式配置處理器。在某種不太常見的
-情況下，爲將 A 類缺陷當作 C 類處理，可能需要用類似的手段。這些手段被
-統稱爲「軟體補救措施」，且僅在少數情況需要（例如，那些需要一個運行在
-非安全異常級的補救措施 *並且* 能被 Linux 觸發的情況）。
-
-對於尚在討論中的可能對未受瑕疵影響的系統產生干擾的軟體補救措施，有一個
-相應的內核配置（Kconfig）選項被加在 「內核特性（Kernel Features）」->
-「基於可選方法框架的 ARM 瑕疵補救措施（ARM errata workarounds via
-the alternatives framework）"。這些選項被默認開啓，若探測到受影響的CPU，
-補丁將在運行時被使用。至於對系統運行影響較小的補救措施，內核配置選項
-並不存在，且代碼以某種規避瑕疵的方式被構造（帶注釋爲宜）。
-
-這種做法對於在任意內核原始碼樹中準確地判斷出哪個瑕疵已被軟體方法所補救
-稍微有點麻煩，所以在 Linux 內核中此文件作爲軟體補救措施的註冊表，
-並將在新的軟體補救措施被提交和向後移植（backported）到穩定內核時被更新。
-
-| 實現者 | 受影響的組件 | 勘誤編號 | 內核配置 |
-+----------------+-----------------+-----------------+-------------------------+
-| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
-| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
-| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
-| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
-| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
-| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
-| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
-| ARM | Cortex-A57 | #852523 | N/A |
-| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
-| | | | |
-| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
-| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
-
diff --git a/Documentation/translations/zh_TW/arm64/tagged-pointers.txt b/Documentation/translations/zh_TW/arm64/tagged-pointers.txt
deleted file mode 100644
index 87f8862..0000000
--- a/Documentation/translations/zh_TW/arm64/tagged-pointers.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-SPDX-License-Identifier: GPL-2.0
-
-Chinese translated version of Documentation/arm64/tagged-pointers.rst
-
-If you have any comment or update to the content, please contact the
-original document maintainer directly. However, if you have a problem
-communicating in English you can also ask the Chinese maintainer for
-help. Contact the Chinese maintainer if this translation is outdated
-or if there is a problem with the translation.
-
-Maintainer: Will Deacon <will.deacon@arm.com>
-Chinese maintainer: Fu Wei <wefu@redhat.com>
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
----------------------------------------------------------------------
-Documentation/arm64/tagged-pointers.rst 的中文翻譯
-
-如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
-交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
-譯存在問題，請聯繫中文版維護者。
-
-英文版維護者： Will Deacon <will.deacon@arm.com>
-中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
-中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
-
-以下爲正文
----------------------------------------------------------------------
- Linux 在 AArch64 中帶標記的虛擬地址
- =================================
-
-作者: Will Deacon <will.deacon@arm.com>
-日期: 2013 年 06 月 12 日
-
-本文檔簡述了在 AArch64 地址轉換系統中提供的帶標記的虛擬地址及其在
-AArch64 Linux 中的潛在用途。
-
-內核提供的地址轉換表配置使通過 TTBR0 完成的虛擬地址轉換（即用戶空間
-映射），其虛擬地址的最高 8 位（63:56）會被轉換硬體所忽略。這種機制
-讓這些位可供應用程式自由使用，其注意事項如下：
-
- (1) 內核要求所有傳遞到 EL1 的用戶空間地址帶有 0x00 標記。
- 這意味著任何攜帶用戶空間虛擬地址的系統調用（syscall）
- 參數 *必須* 在陷入內核前使它們的最高字節被清零。
-
- (2) 非零標記在傳遞信號時不被保存。這意味著在應用程式中利用了
- 標記的信號處理函數無法依賴 siginfo_t 的用戶空間虛擬
- 地址所攜帶的包含其內部域信息的標記。此規則的一個例外是
- 當信號是在調試觀察點的異常處理程序中產生的，此時標記的
- 信息將被保存。
-
- (3) 當使用帶標記的指針時需特別留心，因爲僅對兩個虛擬地址
- 的高字節，C 編譯器很可能無法判斷它們是不同的。
-
-此構架會阻止對帶標記的 PC 指針的利用，因此在異常返回時，其高字節
-將被設置成一個爲 「55」 的擴展符。
-
diff --git a/Documentation/translations/zh_TW/gpio.txt b/Documentation/translations/zh_TW/gpio.txt
index 62e560f..b93788a 100644
--- a/Documentation/translations/zh_TW/gpio.txt
+++ b/Documentation/translations/zh_TW/gpio.txt
@@ -161,8 +161,7 @@
大多數 GPIO 控制器可以通過內存讀/寫指令來訪問。這些指令不會休眠,可以
安全地在硬(非線程)中斷例程和類似的上下文中完成。
-對於那些用 gpio_cansleep()測試總是返回失敗的 GPIO(見下文)，使用
-以下的函數訪問:
+對於那些 GPIO，使用以下的函數訪問:
/* GPIO 輸入:返回零或非零 */
int gpio_get_value(unsigned gpio);
@@ -193,11 +192,6 @@
GPIO 值的命令需要等待其信息排到隊首才發送命令，再獲得其反饋。期間需要
休眠，這不能在 IRQ 例程(中斷上下文)中執行。
-支持此類 GPIO 的平台通過以下函數返回非零值來區分出這種 GPIO。(此函數需要
-一個之前通過 gpio_request 分配到的有效 GPIO 編號):
-
- int gpio_cansleep(unsigned gpio);
-
爲了訪問這種 GPIO,內核定義了一套不同的函數:
/* GPIO 輸入:返回零或非零 ,可能會休眠 */
@@ -206,7 +200,6 @@
/* GPIO 輸出,可能會休眠 */
void gpio_set_value_cansleep(unsigned gpio, int value);
-
訪問這樣的 GPIO 需要一個允許休眠的上下文，例如線程 IRQ 處理例程，並用以上的
訪問函數替換那些沒有 cansleep()後綴的自旋鎖安全訪問函數。
@@ -300,11 +293,6 @@
* GPIOF_INIT_LOW - 在作爲輸出時,初始值爲低電平
* GPIOF_INIT_HIGH - 在作爲輸出時,初始值爲高電平
- * GPIOF_OPEN_DRAIN - gpio引腳爲開漏信號
- * GPIOF_OPEN_SOURCE - gpio引腳爲源極開路信號
-
- * GPIOF_EXPORT_DIR_FIXED - 將 gpio 導出到 sysfs，並保持方向
- * GPIOF_EXPORT_DIR_CHANGEABLE - 同樣是導出, 但允許改變方向
因爲 GPIOF_INIT_* 僅有在配置爲輸出的時候才存在,所以有效的組合爲:
@@ -312,18 +300,6 @@
* GPIOF_OUT_INIT_LOW - 配置爲輸出,並初始化爲低電平
* GPIOF_OUT_INIT_HIGH - 配置爲輸出,並初始化爲高電平
-當設置 flag 爲 GPIOF_OPEN_DRAIN 時，則假設引腳是開漏信號。這樣的引腳
-將不會在輸出模式下置1。這樣的引腳需要連接上拉電阻。通過使能這個標誌，gpio庫
-將會在被要求輸出模式下置1時將引腳變爲輸入狀態來使引腳置高。引腳在輸出模式下
-通過置0使其輸出低電平。
-
-當設置 flag 爲 GPIOF_OPEN_SOURCE 時，則假設引腳爲源極開路信號。這樣的引腳
-將不會在輸出模式下置0。這樣的引腳需要連接下拉電阻。通過使能這個標誌，gpio庫
-將會在被要求輸出模式下置0時將引腳變爲輸入狀態來使引腳置低。引腳在輸出模式下
-通過置1使其輸出高電平。
-
-將來這些標誌可能擴展到支持更多的屬性。
-
更進一步,爲了更簡單地聲明/釋放多個 GPIO,'struct gpio'被引進來封裝所有
這三個領域:
@@ -466,8 +442,8 @@
-------
爲了支持這個框架，一個平台的 Kconfig 文件將會 "select"(選擇)
ARCH_REQUIRE_GPIOLIB 或 ARCH_WANT_OPTIONAL_GPIOLIB，並讓它的
-<asm/gpio.h> 包含 <asm-generic/gpio.h>，同時定義三個方法:
-gpio_get_value()、gpio_set_value()和 gpio_cansleep()。
+<asm/gpio.h> 包含 <asm-generic/gpio.h>，同時定義二個方法:
+gpio_get_value()、gpio_set_value()。
它也應提供一個 ARCH_NR_GPIOS 的定義值，這樣可以更好地反映該平台 GPIO
的實際數量,節省靜態表的空間。(這個定義值應該包含片上系統內建 GPIO 和
@@ -485,7 +461,6 @@
#define gpio_get_value __gpio_get_value
#define gpio_set_value __gpio_set_value
- #define gpio_cansleep __gpio_cansleep
這些定義可以用更理想的實現方法替代，那就是使用經過邏輯優化的內聯函數來訪問
基於特定片上系統的 GPIO。例如,若引用的 GPIO (寄存器位偏移)是常量「12」，
diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst
index e97d7d5..e7c8386 100644
--- a/Documentation/translations/zh_TW/index.rst
+++ b/Documentation/translations/zh_TW/index.rst
@@ -150,7 +150,7 @@
.. toctree::
:maxdepth: 2
- arm64/index
+ arch/arm64/index
TODOList:
diff --git a/Documentation/translations/zh_TW/process/2.Process.rst b/Documentation/translations/zh_TW/process/2.Process.rst
index b01cdd3..9d465df 100644
--- a/Documentation/translations/zh_TW/process/2.Process.rst
+++ b/Documentation/translations/zh_TW/process/2.Process.rst
@@ -361,7 +361,7 @@
機器上始終完美運行」。通常的方法是和其他人一起解決問題（這可能需
要堅持！），但就是如此——這是內核開發的一部分。
-(http://lwn.net/articles/283982/)
+(http://lwn.net/Articles/283982/)
在沒有明顯問題需要解決的情況下，通常建議開發人員查看當前的回歸和開放缺陷
列表。從來都不缺少需要解決的問題；通過解決這些問題，開發人員將從該過程獲得
diff --git a/Documentation/translations/zh_TW/process/3.Early-stage.rst b/Documentation/translations/zh_TW/process/3.Early-stage.rst
index ab2a45f..076873c 100644
--- a/Documentation/translations/zh_TW/process/3.Early-stage.rst
+++ b/Documentation/translations/zh_TW/process/3.Early-stage.rst
@@ -47,7 +47,7 @@
試圖向這些人傳達用戶需求是浪費時間。他們太「聰明」了，根本聽不到少數
人的話。
-（http://lwn.net/articles/131776/）
+（http://lwn.net/Articles/131776/）
實際情況卻是不同的；與特定模塊相比，內核開發人員更關心系統穩定性、長期維護
以及找到問題的正確解決方案。這個故事的寓意是把重點放在問題上——而不是具體的
diff --git a/Documentation/translations/zh_TW/process/4.Coding.rst b/Documentation/translations/zh_TW/process/4.Coding.rst
index ccc3946..7fc0344 100644
--- a/Documentation/translations/zh_TW/process/4.Coding.rst
+++ b/Documentation/translations/zh_TW/process/4.Coding.rst
@@ -152,7 +152,7 @@
所以我們不會通過引入新問題來修復錯誤。這種方式是靠不住的，沒人知道
是否真的有進展。是前進兩步、後退一步，還是前進一步、後退兩步？
-（http://lwn.net/articles/243460/）
+（http://lwn.net/Articles/243460/）
特別不受歡迎的一種回歸類型是用戶空間ABI的任何變化。一旦接口被導出到用戶空間，
就必須無限期地支持它。這一事實使得用戶空間接口的創建特別具有挑戰性：因爲它們
diff --git a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
index 3de093d..4fbc104 100644
--- a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
@@ -101,7 +101,7 @@
你可以給我發補丁，但當我從你那裡拉取一個Git補丁時，我需要知道你清楚
自己在做什麼，我需要能夠相信事情而 *無需* 手動檢查每個單獨的更改。
-（http://lwn.net/articles/224135/）。
+（http://lwn.net/Articles/224135/）。
爲了避免這種情況，請確保給定分支中的所有補丁都與相關主題緊密相關；「驅動程序
修復」分支不應更改核心內存管理代碼。而且，最重要的是，不要使用Git樹來繞過
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 4f7b23f..4ea5b83 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -180,6 +180,7 @@
'P' 00-0F drivers/usb/class/usblp.c conflict!
'P' 01-09 drivers/misc/pci_endpoint_test.c conflict!
'P' 00-0F xen/privcmd.h conflict!
+'P' 00-05 linux/tps6594_pfsm.h conflict!
'Q' all linux/soundcard.h
'R' 00-1F linux/random.h conflict!
'R' 01 linux/rfkill.h conflict!
diff --git a/Documentation/userspace-api/media/frontend.h.rst.exceptions b/Documentation/userspace-api/media/frontend.h.rst.exceptions
index 8b73fee..dcaf574 100644
--- a/Documentation/userspace-api/media/frontend.h.rst.exceptions
+++ b/Documentation/userspace-api/media/frontend.h.rst.exceptions
@@ -142,6 +142,10 @@
ignore symbol FEC_28_45
ignore symbol FEC_32_45
ignore symbol FEC_77_90
+ignore symbol FEC_11_45
+ignore symbol FEC_4_15
+ignore symbol FEC_14_45
+ignore symbol FEC_7_15
ignore symbol TRANSMISSION_MODE_AUTO
ignore symbol TRANSMISSION_MODE_1K
diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 9cd18c1..72aef17 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -427,3 +427,12 @@
:title: VP9 Bitstream & Decoding Process Specification
:author: Adrian Grange (Google), Peter de Rivaz (Argon Design), Jonathan Hunt (Argon Design)
+
+.. _av1:
+
+AV1
+===
+
+:title: AV1 Bitstream & Decoding Process Specification
+
+:author: Peter de Rivaz, Argon Design Ltd, Jack Haughton, Argon Design Ltd
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst
index daa4f40..cdc515c 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst
@@ -506,6 +506,8 @@
value down. A value of zero stops the motion if one is in progress
and has no effect otherwise.
+.. _v4l2-camera-sensor-orientation:
+
``V4L2_CID_CAMERA_ORIENTATION (menu)``
This read-only control describes the camera orientation by reporting its
mounting position on the device where the camera is installed. The control
@@ -536,6 +538,7 @@
- The camera is not directly attached to the device and is freely movable.
+.. _v4l2-camera-sensor-rotation:
``V4L2_CID_CAMERA_SENSOR_ROTATION (integer)``
This read-only control describes the rotation correction in degrees in the
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index 3d8411a..81e60f4 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -1890,11 +1890,11 @@
* - __u8
- ``tree_probs[7]``
- Specifies the probability values to be used when decoding a Segment-ID.
- See '5.15. Segmentation map' section of :ref:`vp9` for more details.
+ See '5.15 Segmentation map' section of :ref:`vp9` for more details.
* - __u8
- ``pred_probs[3]``
- Specifies the probability values to be used when decoding a
- Predicted-Segment-ID. See '6.4.14. Get segment id syntax'
+ Predicted-Segment-ID. See '6.4.14 Get segment id syntax'
section of :ref:`vp9` for more details.
* - __u8
- ``flags``
@@ -2923,6 +2923,13 @@
- ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
- PocLtCurr as described in section 8.3.2 "Decoding process for reference
picture set": provides the index of the long term references in DPB array.
+ * - __u8
+ - ``num_delta_pocs_of_ref_rps_idx``
+ - When the short_term_ref_pic_set_sps_flag in the slice header is equal to 0,
+ it is the same as the derived value NumDeltaPocs[RefRpsIdx]. It can be used to parse
+ the RPS data in slice headers instead of skipping it with @short_term_ref_pic_set_size.
+ When the value of short_term_ref_pic_set_sps_flag in the slice header is
+ equal to 1, num_delta_pocs_of_ref_rps_idx shall be set to 0.
* - struct :c:type:`v4l2_hevc_dpb_entry`
- ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
- The decoded picture buffer, for meta-data about reference frames.
@@ -2950,3 +2957,1208 @@
* - ``V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR``
- 0x00000004
-
+
+.. _v4l2-codec-stateless-av1:
+
+``V4L2_CID_STATELESS_AV1_SEQUENCE (struct)``
+ Represents an AV1 Sequence OBU (Open Bitstream Unit). See section 5.5
+ "Sequence header OBU syntax" in :ref:`av1` for more details.
+
+.. c:type:: v4l2_ctrl_av1_sequence
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}|
+
+.. flat-table:: struct v4l2_ctrl_av1_sequence
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u32
+ - ``flags``
+ - See :ref:`AV1 Sequence Flags <av1_sequence_flags>`.
+ * - __u8
+ - ``seq_profile``
+ - Specifies the features that can be used in the coded video sequence.
+ * - __u8
+ - ``order_hint_bits``
+ - Specifies the number of bits used for the order_hint field at each frame.
+ * - __u8
+ - ``bit_depth``
+ - the bit depth to use for the sequence as described in section 5.5.2
+ "Color config syntax" in :ref:`av1` for more details.
+ * - __u8
+ - ``reserved``
+ - Applications and drivers must set this to zero.
+ * - __u16
+ - ``max_frame_width_minus_1``
+ - specifies the maximum frame width minus 1 for the frames represented by
+ this sequence header.
+
+.. _av1_sequence_flags:
+
+``AV1 Sequence Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_SEQUENCE_FLAG_STILL_PICTURE``
+ - 0x00000001
+ - If set, specifies that the coded video sequence contains only one coded
+ frame. If not set, specifies that the coded video sequence contains one
+ or more coded frames.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_USE_128X128_SUPERBLOCK``
+ - 0x00000002
+ - If set, indicates that superblocks contain 128x128 luma samples.
+ When equal to 0, it indicates that superblocks contain 64x64 luma
+ samples. The number of contained chroma samples depends on
+ subsampling_x and subsampling_y.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_FILTER_INTRA``
+ - 0x00000004
+ - If set, specifies that the use_filter_intra syntax element may be
+ present. If not set, specifies that the use_filter_intra syntax element
+ will not be present.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_INTRA_EDGE_FILTER``
+ - 0x00000008
+ - Specifies whether the intra edge filtering process should be enabled.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_INTERINTRA_COMPOUND``
+ - 0x00000010
+ - If set, specifies that the mode info for inter blocks may contain the
+ syntax element interintra. If not set, specifies that the syntax element
+ interintra will not be present.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_MASKED_COMPOUND``
+ - 0x00000020
+ - If set, specifies that the mode info for inter blocks may contain the
+ syntax element compound_type. If not set, specifies that the syntax
+ element compound_type will not be present.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_WARPED_MOTION``
+ - 0x00000040
+ - If set, indicates that the allow_warped_motion syntax element may be
+ present. If not set, indicates that the allow_warped_motion syntax
+ element will not be present.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_DUAL_FILTER``
+ - 0x00000080
+ - If set, indicates that the inter prediction filter type may be specified
+ independently in the horizontal and vertical directions. If the flag is
+ equal to 0, only one filter type may be specified, which is then used in
+ both directions.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_ORDER_HINT``
+ - 0x00000100
+ - If set, indicates that tools based on the values of order hints may be
+ used. If not set, indicates that tools based on order hints are
+ disabled.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_JNT_COMP``
+ - 0x00000200
+ - If set, indicates that the distance weights process may be used for
+ inter prediction.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_REF_FRAME_MVS``
+ - 0x00000400
+ - If set, indicates that the use_ref_frame_mvs syntax element may be
+ present. If not set, indicates that the use_ref_frame_mvs syntax element
+ will not be present.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_SUPERRES``
+ - 0x00000800
+ - If set, specifies that the use_superres syntax element will be present
+ in the uncompressed header. If not set, specifies that the use_superres
+ syntax element will not be present (instead use_superres will be set to
+ 0 in the uncompressed header without being read).
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_CDEF``
+ - 0x00001000
+ - If set, specifies that cdef filtering may be enabled. If not set,
+ specifies that cdef filtering is disabled.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_ENABLE_RESTORATION``
+ - 0x00002000
+ - If set, specifies that loop restoration filtering may be enabled. If not
+ set, specifies that loop restoration filtering is disabled.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_MONO_CHROME``
+ - 0x00004000
+ - If set, indicates that the video does not contain U and V color planes.
+ If not set, indicates that the video contains Y, U, and V color planes.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_COLOR_RANGE``
+ - 0x00008000
+ - If set, signals full swing representation, i.e. "Full Range
+ Quantization". If not set, signals studio swing representation, i.e.
+ "Limited Range Quantization".
+ * - ``V4L2_AV1_SEQUENCE_FLAG_SUBSAMPLING_X``
+ - 0x00010000
+ - Specify the chroma subsampling format.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_SUBSAMPLING_Y``
+ - 0x00020000
+ - Specify the chroma subsampling format.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_FILM_GRAIN_PARAMS_PRESENT``
+ - 0x00040000
+ - Specifies whether film grain parameters are present in the coded video
+ sequence.
+ * - ``V4L2_AV1_SEQUENCE_FLAG_SEPARATE_UV_DELTA_Q``
+ - 0x00080000
+ - If set, indicates that the U and V planes may have separate delta
+ quantizer values. If not set, indicates that the U and V planes will share
+ the same delta quantizer value.
+
+``V4L2_CID_STATELESS_AV1_TILE_GROUP_ENTRY (struct)``
+ Represents a single AV1 tile inside an AV1 Tile Group. Note that MiRowStart,
+ MiRowEnd, MiColStart and MiColEnd can be retrieved from struct
+ v4l2_av1_tile_info in struct v4l2_ctrl_av1_frame using tile_row and
+ tile_col. See section 6.10.1 "General tile group OBU semantics" in
+ :ref:`av1` for more details.
+
+.. c:type:: v4l2_ctrl_av1_tile_group_entry
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}|
+
+.. flat-table:: struct v4l2_ctrl_av1_tile_group_entry
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u32
+ - ``tile_offset``
+ - Offset from the OBU data, i.e. where the coded tile data actually starts.
+ * - __u32
+ - ``tile_size``
+ - Specifies the size in bytes of the coded tile. Equivalent to "TileSize"
+ in :ref:`av1`.
+ * - __u32
+ - ``tile_row``
+ - Specifies the row of the current tile. Equivalent to "TileRow" in
+ :ref:`av1`.
+ * - __u32
+ - ``tile_col``
+ - Specifies the column of the current tile. Equivalent to "TileColumn" in
+ :ref:`av1`.
+
+.. c:type:: v4l2_av1_warp_model
+
+ AV1 Warp Model as described in section 3 "Symbols and abbreviated terms" of
+ :ref:`av1`.
+
+.. raw:: latex
+
+ \scriptsize
+
+.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}|
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_WARP_MODEL_IDENTITY``
+ - 0
+ - Warp model is just an identity transform.
+ * - ``V4L2_AV1_WARP_MODEL_TRANSLATION``
+ - 1
+ - Warp model is a pure translation.
+ * - ``V4L2_AV1_WARP_MODEL_ROTZOOM``
+ - 2
+ - Warp model is a rotation + symmetric zoom + translation.
+ * - ``V4L2_AV1_WARP_MODEL_AFFINE``
+ - 3
+ - Warp model is a general affine transform.
+
+.. c:type:: v4l2_av1_reference_frame
+
+AV1 Reference Frames as described in section 6.10.24 "Ref frames semantics"
+of :ref:`av1`.
+
+.. raw:: latex
+
+ \scriptsize
+
+.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}|
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_REF_INTRA_FRAME``
+ - 0
+ - Intra Frame Reference.
+ * - ``V4L2_AV1_REF_LAST_FRAME``
+ - 1
+ - Last Frame Reference.
+ * - ``V4L2_AV1_REF_LAST2_FRAME``
+ - 2
+ - Last2 Frame Reference.
+ * - ``V4L2_AV1_REF_LAST3_FRAME``
+ - 3
+ - Last3 Frame Reference.
+ * - ``V4L2_AV1_REF_GOLDEN_FRAME``
+ - 4
+ - Golden Frame Reference.
+ * - ``V4L2_AV1_REF_BWDREF_FRAME``
+ - 5
+ - BWD Frame Reference.
+ * - ``V4L2_AV1_REF_ALTREF2_FRAME``
+ - 6
+ - ALTREF2 Frame Reference.
+ * - ``V4L2_AV1_REF_ALTREF_FRAME``
+ - 7
+ - ALTREF Frame Reference.
+
+.. c:type:: v4l2_av1_global_motion
+
+AV1 Global Motion parameters as described in section 6.8.17
+"Global motion params semantics" of :ref:`av1`.
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
+
+.. flat-table:: struct v4l2_av1_global_motion
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``flags[V4L2_AV1_TOTAL_REFS_PER_FRAME]``
+ - A bitfield containing the flags per reference frame. See
+ :ref:`AV1 Global Motion Flags <av1_global_motion_flags>` for more
+ details.
+ * - enum :c:type:`v4l2_av1_warp_model`
+ - ``type[V4L2_AV1_TOTAL_REFS_PER_FRAME]``
+ - The type of global motion transform used.
+ * - __s32
+ - ``params[V4L2_AV1_TOTAL_REFS_PER_FRAME][6]``
+ - This field has the same meaning as "gm_params" in :ref:`av1`.
+ * - __u8
+ - ``invalid``
+ - Bitfield indicating whether the global motion params are invalid for a
+ given reference frame. See section 7.11.3.6 Setup shear process and the
+ variable "warpValid". Use V4L2_AV1_GLOBAL_MOTION_IS_INVALID(ref) to
+ create a suitable mask.
+ * - __u8
+ - ``reserved[3]``
+ - Applications and drivers must set this to zero.
+
+.. _av1_global_motion_flags:
+
+``AV1 Global Motion Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_GLOBAL_MOTION_FLAG_IS_GLOBAL``
+ - 0x00000001
+ - Specifies whether global motion parameters are present for a particular
+ reference frame.
+ * - ``V4L2_AV1_GLOBAL_MOTION_FLAG_IS_ROT_ZOOM``
+ - 0x00000002
+ - Specifies whether a particular reference frame uses rotation and zoom
+ global motion.
+ * - ``V4L2_AV1_GLOBAL_MOTION_FLAG_IS_TRANSLATION``
+ - 0x00000004
+ - Specifies whether a particular reference frame uses translation global
+ motion
+
+.. c:type:: v4l2_av1_frame_restoration_type
+
+AV1 Frame Restoration Type.
+
+.. raw:: latex
+
+ \scriptsize
+
+.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}|
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_FRAME_RESTORE_NONE``
+ - 0
+ - No filtering is applied.
+ * - ``V4L2_AV1_FRAME_RESTORE_WIENER``
+ - 1
+ - Wiener filter process is invoked.
+ * - ``V4L2_AV1_FRAME_RESTORE_SGRPROJ``
+ - 2
+ - Self guided filter process is invoked.
+ * - ``V4L2_AV1_FRAME_RESTORE_SWITCHABLE``
+ - 3
+ - Restoration filter is swichtable.
+
+.. c:type:: v4l2_av1_loop_restoration
+
+AV1 Loop Restauration as described in section 6.10.15 "Loop restoration params
+semantics" of :ref:`av1`.
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
+
+.. flat-table:: struct v4l2_av1_loop_restoration
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``flags``
+ - See :ref:`AV1 Loop Restoration Flags <av1_loop_restoration_flags>`.
+ * - __u8
+ - ``lr_unit_shift``
+ - Specifies if the luma restoration size should be halved.
+ * - __u8
+ - ``lr_uv_shift``
+ - Specifies if the chroma size should be half the luma size.
+ * - __u8
+ - ``reserved``
+ - Applications and drivers must set this to zero.
+ * - :c:type:`v4l2_av1_frame_restoration_type`
+ - ``frame_restoration_type[V4L2_AV1_NUM_PLANES_MAX]``
+ - Specifies the type of restoration used for each plane.
+ * - __u8
+ - ``loop_restoration_size[V4L2_AV1_MAX_NUM_PLANES]``
+ - Specifies the size of loop restoration units in units of samples in the
+ current plane.
+
+.. _av1_loop_restoration_flags:
+
+``AV1 Loop Restoration Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_LOOP_RESTORATION_FLAG_USES_LR``
+ - 0x00000001
+ - Retains the same meaning as UsesLr in :ref:`av1`.
+ * - ``V4L2_AV1_LOOP_RESTORATION_FLAG_USES_CHROMA_LR``
+ - 0x00000002
+ - Retains the same meaning as UsesChromaLr in :ref:`av1`.
+
+.. c:type:: v4l2_av1_cdef
+
+AV1 CDEF params semantics as described in section 6.10.14 "CDEF params
+semantics" of :ref:`av1`.
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
+
+.. flat-table:: struct v4l2_av1_cdef
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``damping_minus_3``
+ - Controls the amount of damping in the deringing filter.
+ * - __u8
+ - ``bits``
+ - Specifies the number of bits needed to specify which CDEF filter to
+ apply.
+ * - __u8
+ - ``y_pri_strength[V4L2_AV1_CDEF_MAX]``
+ - Specifies the strength of the primary filter.
+ * - __u8
+ - ``y_sec_strength[V4L2_AV1_CDEF_MAX]``
+ - Specifies the strength of the secondary filter.
+ * - __u8
+ - ``uv_pri_strength[V4L2_AV1_CDEF_MAX]``
+ - Specifies the strength of the primary filter.
+ * - __u8
+ - ``uv_secondary_strength[V4L2_AV1_CDEF_MAX]``
+ - Specifies the strength of the secondary filter.
+
+.. c:type:: v4l2_av1_segment_feature
+
+AV1 segment features as described in section 3 "Symbols and abbreviated terms"
+of :ref:`av1`.
+
+.. raw:: latex
+
+ \scriptsize
+
+.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}|
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_SEG_LVL_ALT_Q``
+ - 0
+ - Index for quantizer segment feature.
+ * - ``V4L2_AV1_SEG_LVL_ALT_LF_Y_V``
+ - 1
+ - Index for vertical luma loop filter segment feature.
+ * - ``V4L2_AV1_SEG_LVL_REF_FRAME``
+ - 5
+ - Index for reference frame segment feature.
+ * - ``V4L2_AV1_SEG_LVL_REF_SKIP``
+ - 6
+ - Index for skip segment feature.
+ * - ``V4L2_AV1_SEG_LVL_REF_GLOBALMV``
+ - 7
+ - Index for global mv feature.
+ * - ``V4L2_AV1_SEG_LVL_MAX``
+ - 8
+ - Number of segment features.
+
+.. c:type:: v4l2_av1_segmentation
+
+AV1 Segmentation params as defined in section 6.8.13 "Segmentation params
+semantics" of :ref:`av1`.
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
+
+.. flat-table:: struct v4l2_av1_segmentation
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``flags``
+ - See :ref:`AV1 Segmentation Flags <av1_segmentation_flags>`
+ * - __u8
+ - ``last_active_seg_id``
+ - Indicates the highest numbered segment id that has some
+ enabled feature. This is used when decoding the segment id to only decode
+ choices corresponding to used segments.
+ * - __u8
+ - ``feature_enabled[V4L2_AV1_MAX_SEGMENTS]``
+ - Bitmask defining which features are enabled in each segment. Use
+ V4L2_AV1_SEGMENT_FEATURE_ENABLED to build a suitable mask.
+ * - __u16
+ - `feature_data[V4L2_AV1_MAX_SEGMENTS][V4L2_AV1_SEG_LVL_MAX]``
+ - Data attached to each feature. Data entry is only valid if the feature
+ is enabled.
+
+.. _av1_segmentation_flags:
+
+``AV1 Segmentation Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_SEGMENTATION_FLAG_ENABLED``
+ - 0x00000001
+ - If set, indicates that this frame makes use of the segmentation tool. If
+ not set, indicates that the frame does not use segmentation.
+ * - ``V4L2_AV1_SEGMENTATION_FLAG_UPDATE_MAP``
+ - 0x00000002
+ - If set, indicates that the segmentation map are updated during the
+ decoding of this frame. If not set, indicates that the segmentation map
+ from the previous frame is used.
+ * - ``V4L2_AV1_SEGMENTATION_FLAG_TEMPORAL_UPDATE``
+ - 0x00000004
+ - If set, indicates that the updates to the segmentation map are coded
+ relative to the existing segmentation map. If not set, indicates that
+ the new segmentation map is coded without reference to the existing
+ segmentation map.
+ * - ``V4L2_AV1_SEGMENTATION_FLAG_UPDATE_DATA``
+ - 0x00000008
+ - If set, indicates that the updates to the segmentation map are coded
+ relative to the existing segmentation map. If not set, indicates that
+ the new segmentation map is coded without reference to the existing
+ segmentation map.
+ * - ``V4L2_AV1_SEGMENTATION_FLAG_SEG_ID_PRE_SKIP``
+ - 0x00000010
+ - If set, indicates that the segment id will be read before the skip
+ syntax element. If not set, indicates that the skip syntax element will
+ be read first.
+
+.. c:type:: v4l2_av1_loop_filter
+
+AV1 Loop filter params as defined in section 6.8.10 "Loop filter semantics" of
+:ref:`av1`.
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
+
+.. flat-table:: struct v4l2_av1_global_motion
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``flags``
+ - See
+ :ref:`AV1 Loop Filter flags <av1_loop_filter_flags>` for more details.
+ * - __u8
+ - ``level[4]``
+ - An array containing loop filter strength values. Different loop
+ filter strength values from the array are used depending on the image
+ plane being filtered, and the edge direction (vertical or horizontal)
+ being filtered.
+ * - __u8
+ - ``sharpness``
+ - indicates the sharpness level. The loop_filter_level and
+ loop_filter_sharpness together determine when a block edge is filtered,
+ and by how much the filtering can change the sample values. The loop
+ filter process is described in section 7.14 of :ref:`av1`.
+ * - __u8
+ - ``ref_deltas[V4L2_AV1_TOTAL_REFS_PER_FRAME]``
+ - contains the adjustment needed for the filter level based on the
+ chosen reference frame. If this syntax element is not present, it
+ maintains its previous value.
+ * - __u8
+ - ``mode_deltas[2]``
+ - contains the adjustment needed for the filter level based on
+ the chosen mode. If this syntax element is not present, it maintains its
+ previous value.
+ * - __u8
+ - ``delta_lf_res``
+ - specifies the left shift which should be applied to decoded loop filter
+ delta values.
+
+.. _av1_loop_filter_flags:
+
+``AV1 Loop Filter Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_LOOP_FILTER_FLAG_DELTA_ENABLED``
+ - 0x00000001
+ - If set, means that the filter level depends on the mode and reference
+ frame used to predict a block. If not set, means that the filter level
+ does not depend on the mode and reference frame.
+ * - ``V4L2_AV1_LOOP_FILTER_FLAG_DELTA_UPDATE``
+ - 0x00000002
+ - If set, means that additional syntax elements are present that specify
+ which mode and reference frame deltas are to be updated. If not set,
+ means that these syntax elements are not present.
+ * - ``V4L2_AV1_LOOP_FILTER_FLAG_DELTA_LF_PRESENT``
+ - 0x00000004
+ - Specifies whether loop filter delta values are present
+ * - ``V4L2_AV1_LOOP_FILTER_FLAG_DELTA_LF_MULTI``
+ - 0x00000008
+ - A value equal to 1 specifies that separate loop filter
+ deltas are sent for horizontal luma edges, vertical luma edges,
+ the U edges, and the V edges. A value of delta_lf_multi equal to 0
+ specifies that the same loop filter delta is used for all edges.
+
+.. c:type:: v4l2_av1_quantization
+
+AV1 Quantization params as defined in section 6.8.11 "Quantization params
+semantics" of :ref:`av1`.
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
+
+.. flat-table:: struct v4l2_av1_quantization
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``flags``
+ - See
+ :ref:`AV1 Loop Filter flags <av1_quantization_flags>` for more details.
+ * - __u8
+ - ``base_q_idx``
+ - Indicates the base frame qindex. This is used for Y AC coefficients and
+ as the base value for the other quantizers.
+ * - __u8
+ - ``delta_q_y_dc``
+ - Indicates the Y DC quantizer relative to base_q_idx.
+ * - __u8
+ - ``delta_q_u_dc``
+ - Indicates the U DC quantizer relative to base_q_idx.
+ * - __u8
+ - ``delta_q_u_ac``
+ - Indicates the U AC quantizer relative to base_q_idx.
+ * - __u8
+ - ``delta_q_v_dc``
+ - Indicates the V DC quantizer relative to base_q_idx.
+ * - __u8
+ - ``delta_q_v_ac``
+ - Indicates the V AC quantizer relative to base_q_idx.
+ * - __u8
+ - ``qm_y``
+ - Specifies the level in the quantizer matrix that should be used for
+ luma plane decoding.
+ * - __u8
+ - ``qm_u``
+ - Specifies the level in the quantizer matrix that should be used for
+ chroma U plane decoding.
+ * - __u8
+ - ``qm_v``
+ - Specifies the level in the quantizer matrix that should be used for
+ chroma V plane decoding.
+ * - __u8
+ - ``delta_q_res``
+ - Specifies the left shift which should be applied to decoded quantizer
+ index delta values.
+
+.. _av1_quantization_flags:
+
+``AV1 Quantization Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_QUANTIZATION_FLAG_DIFF_UV_DELTA``
+ - 0x00000001
+ - If set, indicates that the U and V delta quantizer values are coded
+ separately. If not set, indicates that the U and V delta quantizer
+ values share a common value.
+ * - ``V4L2_AV1_QUANTIZATION_FLAG_USING_QMATRIX``
+ - 0x00000002
+ - If set, specifies that the quantizer matrix will be used to compute
+ quantizers.
+ * - ``V4L2_AV1_QUANTIZATION_FLAG_DELTA_Q_PRESENT``
+ - 0x00000004
+ - Specifies whether quantizer index delta values are present.
+
+.. c:type:: v4l2_av1_tile_info
+
+AV1 Tile info as defined in section 6.8.14 "Tile info semantics" of ref:`av1`.
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
+
+.. flat-table:: struct v4l2_av1_tile_info
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``flags``
+ - See
+ :ref:`AV1 Tile Info flags <av1_tile_info_flags>` for more details.
+ * - __u8
+ - ``context_update_tile_id``
+ - Specifies which tile to use for the CDF update.
+ * - __u8
+ - ``tile_cols``
+ - Specifies the number of tiles across the frame.
+ * - __u8
+ - ``tile_rows``
+ - Specifies the number of tiles down the frame.
+ * - __u32
+ - ``mi_col_starts[V4L2_AV1_MAX_TILE_COLS + 1]``
+ - An array specifying the start column (in units of 4x4 luma
+ samples) for each tile across the image.
+ * - __u32
+ - ``mi_row_starts[V4L2_AV1_MAX_TILE_ROWS + 1]``
+ - An array specifying the start row (in units of 4x4 luma
+ samples) for each tile across the image.
+ * - __u32
+ - ``width_in_sbs_minus_1[V4L2_AV1_MAX_TILE_COLS]``
+ - Specifies the width of a tile minus 1 in units of superblocks.
+ * - __u32
+ - ``height_in_sbs_minus_1[V4L2_AV1_MAX_TILE_ROWS]``
+ - Specifies the height of a tile minus 1 in units of superblocks.
+ * - __u8
+ - ``tile_size_bytes``
+ - Specifies the number of bytes needed to code each tile size.
+ * - __u8
+ - ``reserved[3]``
+ - Applications and drivers must set this to zero.
+
+.. _av1_tile_info_flags:
+
+``AV1 Tile Info Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_TILE_INFO_FLAG_UNIFORM_TILE_SPACING``
+ - 0x00000001
+ - If set, means that the tiles are uniformly spaced across the frame. (In
+ other words, all tiles are the same size except for the ones at the
+ right and bottom edge which can be smaller). If not set means that the
+ tile sizes are coded.
+
+.. c:type:: v4l2_av1_frame_type
+
+AV1 Frame Type
+
+.. raw:: latex
+
+ \scriptsize
+
+.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}|
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_KEY_FRAME``
+ - 0
+ - Key frame.
+ * - ``V4L2_AV1_INTER_FRAME``
+ - 1
+ - Inter frame.
+ * - ``V4L2_AV1_INTRA_ONLY_FRAME``
+ - 2
+ - Intra-only frame.
+ * - ``V4L2_AV1_SWITCH_FRAME``
+ - 3
+ - Switch frame.
+
+.. c:type:: v4l2_av1_interpolation_filter
+
+AV1 Interpolation Filter
+
+.. raw:: latex
+
+ \scriptsize
+
+.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}|
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_INTERPOLATION_FILTER_EIGHTTAP``
+ - 0
+ - Eight tap filter.
+ * - ``V4L2_AV1_INTERPOLATION_FILTER_EIGHTTAP_SMOOTH``
+ - 1
+ - Eight tap smooth filter.
+ * - ``V4L2_AV1_INTERPOLATION_FILTER_EIGHTTAP_SHARP``
+ - 2
+ - Eight tap sharp filter.
+ * - ``V4L2_AV1_INTERPOLATION_FILTER_BILINEAR``
+ - 3
+ - Bilinear filter.
+ * - ``V4L2_AV1_INTERPOLATION_FILTER_SWITCHABLE``
+ - 4
+ - Filter selection is signaled at the block level.
+
+.. c:type:: v4l2_av1_tx_mode
+
+AV1 Tx mode as described in section 6.8.21 "TX mode semantics" of :ref:`av1`.
+
+.. raw:: latex
+
+ \scriptsize
+
+.. tabularcolumns:: |p{7.4cm}|p{0.3cm}|p{9.6cm}|
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_TX_MODE_ONLY_4X4``
+ - 0
+ - The inverse transform will use only 4x4 transforms.
+ * - ``V4L2_AV1_TX_MODE_LARGEST``
+ - 1
+ - The inverse transform will use the largest transform size that fits
+ inside the block.
+ * - ``V4L2_AV1_TX_MODE_SELECT``
+ - 2
+ - The choice of transform size is specified explicitly for each block.
+
+``V4L2_CID_STATELESS_AV1_FRAME (struct)``
+ Represents a Frame Header OBU. See 6.8 "Frame Header OBU semantics" of
+ :ref:`av1` for more details.
+
+.. c:type:: v4l2_ctrl_av1_frame
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{5.8cm}|p{4.8cm}|p{6.6cm}|
+
+.. flat-table:: struct v4l2_ctrl_av1_frame
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - struct :c:type:`v4l2_av1_tile_info`
+ - ``tile_info``
+ - Tile info
+ * - struct :c:type:`v4l2_av1_quantization`
+ - ``quantization``
+ - Quantization parameters.
+ * - struct :c:type:`v4l2_av1_segmentation`
+ - ``segmentation``
+ - Segmentation parameters.
+ * - __u8
+ - ``superres_denom``
+ - The denominator for the upscaling ratio.
+ * - struct :c:type:`v4l2_av1_loop_filter`
+ - ``loop_filter``
+ - Loop filter params
+ * - struct :c:type:`v4l2_av1_cdef`
+ - ``cdef``
+ - CDEF params
+ * - __u8
+ - ``skip_mode_frame[2]``
+ - Specifies the frames to use for compound prediction when skip_mode is
+ equal to 1.
+ * - __u8
+ - ``primary_ref_frame``
+ - Specifies which reference frame contains the CDF values and other state
+ that should be loaded at the start of the frame.
+ * - struct :c:type:`v4l2_av1_loop_restoration`
+ - ``loop_restoration``
+ - Loop restoration parameters.
+ * - struct :c:type:`v4l2_av1_loop_global_motion`
+ - ``global_motion``
+ - Global motion parameters.
+ * - __u32
+ - ``flags``
+ - See
+ :ref:`AV1 Frame flags <av1_frame_flags>` for more details.
+ * - enum :c:type:`v4l2_av1_frame_type`
+ - ``frame_type``
+ - Specifies the AV1 frame type
+ * - __u32
+ - ``order_hint``
+ - Specifies OrderHintBits least significant bits of the expected output
+ order for this frame.
+ * - __u32
+ - ``upscaled_width``
+ - The upscaled width.
+ * - enum :c:type:`v4l2_av1_interpolation_filter`
+ - ``interpolation_filter``
+ - Specifies the filter selection used for performing inter prediction.
+ * - enum :c:type:`v4l2_av1_tx_mode`
+ - ``tx_mode``
+ - Specifies how the transform size is determined.
+ * - __u32
+ - ``frame_width_minus_1``
+ - Add 1 to get the frame's width.
+ * - __u32
+ - ``frame_height_minus_1``
+ - Add 1 to get the frame's height.
+ * - __u16
+ - ``render_width_minus_1``
+ - Add 1 to get the render width of the frame in luma samples.
+ * - __u16
+ - ``render_height_minus_1``
+ - Add 1 to get the render height of the frame in luma samples.
+ * - __u32
+ - ``current_frame_id``
+ - Specifies the frame id number for the current frame. Frame
+ id numbers are additional information that do not affect the decoding
+ process, but provide decoders with a way of detecting missing reference
+ frames so that appropriate action can be taken.
+ * - __u8
+ - ``buffer_removal_time[V4L2_AV1_MAX_OPERATING_POINTS]``
+ - Specifies the frame removal time in units of DecCT clock ticks counted
+ from the removal time of the last random access point for operating point
+ opNum.
+ * - __u8
+ - ``reserved[4]``
+ - Applications and drivers must set this to zero.
+ * - __u32
+ - ``order_hints[V4L2_AV1_TOTAL_REFS_PER_FRAME]``
+ - Specifies the expected output order hint for each reference frame.
+ This field corresponds to the OrderHints variable from the specification
+ (section 5.9.2 "Uncompressed header syntax"). As such, this is only
+ used for non-intra frames and ignored otherwise. order_hints[0] is
+ always ignored.
+ * - __u64
+ - ``reference_frame_ts[V4L2_AV1_TOTAL_REFS_PER_FRAME]``
+ - The V4L2 timestamp for each of the reference frames enumerated in
+ enum :c:type:`v4l2_av1_reference_frame` starting at
+ ``V4L2_AV1_REF_LAST_FRAME``. This represents the state of reference
+ slot as described in the spec and updated by userland through the
+ "Reference frame update process" in section 7.20 The timestamp refers
+ to the ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
+ :c:func:`v4l2_timeval_to_ns()` function to convert the struct
+ :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
+ * - __s8
+ - ``ref_frame_idx[V4L2_AV1_REFS_PER_FRAME]``
+ - An index into ``reference_frame_ts`` representing the ordered list of
+ references used by inter-frame. Matches the bitstream syntax
+ element of the same name.
+ * - __u8
+ - ``refresh_frame_flags``
+ - Contains a bitmask that specifies which reference frame slots will be
+ updated with the current frame after it is decoded.
+
+.. _av1_frame_flags:
+
+``AV1 Frame Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_FRAME_FLAG_SHOW_FRAME``
+ - 0x00000001
+ - If set, specifies that this frame should be immediately output once
+ decoded. If not set, specifies that this frame should not be immediately
+ output; it may be output later if a later uncompressed header uses
+ show_existing_frame equal to 1.
+ * - ``V4L2_AV1_FRAME_FLAG_SHOWABLE_FRAME``
+ - 0x00000002
+ - If set, specifies that the frame may be output using the
+ show_existing_frame mechanism. If not set, specifies that this frame
+ will not be output using the show_existing_frame mechanism.
+ * - ``V4L2_AV1_FRAME_FLAG_ERROR_RESILIENT_MODE``
+ - 0x00000004
+ - Specifies whether error resilient mode is enabled.
+ * - ``V4L2_AV1_FRAME_FLAG_DISABLE_CDF_UPDATE``
+ - 0x00000008
+ - Specifies whether the CDF update in the symbol decoding process should
+ be disabled.
+ * - ``V4L2_AV1_FRAME_FLAG_ALLOW_SCREEN_CONTENT_TOOLS``
+ - 0x00000010
+ - If set, indicates that intra blocks may use palette encoding. If not
+ set, indicates that palette encoding is never used.
+ * - ``V4L2_AV1_FRAME_FLAG_FORCE_INTEGER_MV``
+ - 0x00000020
+ - If set, specifies that motion vectors will always be integers. If not
+ set, specifies that motion vectors can contain fractional bits.
+ * - ``V4L2_AV1_FRAME_FLAG_ALLOW_INTRABC``
+ - 0x00000040
+ - If set, indicates that intra block copy may be used in this frame. If
+ not set, indicates that intra block copy is not allowed in this frame.
+ * - ``V4L2_AV1_FRAME_FLAG_USE_SUPERRES``
+ - 0x00000080
+ - If set, indicates that upscaling is needed.
+ * - ``V4L2_AV1_FRAME_FLAG_ALLOW_HIGH_PRECISION_MV``
+ - 0x00000100
+ - If set, specifies that motion vectors are specified to eighth pel
+ precision. If not set, specifies that motion vectors are specified to
+ quarter pel precision;
+ * - ``V4L2_AV1_FRAME_FLAG_IS_MOTION_MODE_SWITCHABLE``
+ - 0x00000200
+ - If not set, specifies that only the SIMPLE motion mode will be used.
+ * - ``V4L2_AV1_FRAME_FLAG_USE_REF_FRAME_MVS``
+ - 0x00000400
+ - If set specifies that motion vector information from a previous frame
+ can be used when decoding the current frame. If not set, specifies that
+ this information will not be used.
+ * - ``V4L2_AV1_FRAME_FLAG_DISABLE_FRAME_END_UPDATE_CDF``
+ - 0x00000800
+ - If set indicates that the end of frame CDF update is disabled. If not
+ set, indicates that the end of frame CDF update is enabled
+ * - ``V4L2_AV1_FRAME_FLAG_ALLOW_WARPED_MOTION``
+ - 0x00001000
+ - If set, indicates that the syntax element motion_mode may be present, if
+ not set, indicates that the syntax element motion_mode will not be
+ present.
+ * - ``V4L2_AV1_FRAME_FLAG_REFERENCE_SELECT``
+ - 0x00002000
+ - If set, specifies that the mode info for inter blocks contains the
+ syntax element comp_mode that indicates whether to use single or
+ compound reference prediction. If not set, specifies that all inter
+ blocks will use single prediction.
+ * - ``V4L2_AV1_FRAME_FLAG_REDUCED_TX_SET``
+ - 0x00004000
+ - If set, specifies that the frame is restricted to a reduced subset of
+ the full set of transform types.
+ * - ``V4L2_AV1_FRAME_FLAG_SKIP_MODE_ALLOWED``
+ - 0x00008000
+ - This flag retains the same meaning as SkipModeAllowed in :ref:`av1`.
+ * - ``V4L2_AV1_FRAME_FLAG_SKIP_MODE_PRESENT``
+ - 0x00010000
+ - If set, specifies that the syntax element skip_mode will be present, if
+ not set, specifies that skip_mode will not be used for this frame.
+ * - ``V4L2_AV1_FRAME_FLAG_FRAME_SIZE_OVERRIDE``
+ - 0x00020000
+ - If set, specifies that the frame size will either be specified as the
+ size of one of the reference frames, or computed from the
+ frame_width_minus_1 and frame_height_minus_1 syntax elements. If not
+ set, specifies that the frame size is equal to the size in the sequence
+ header.
+ * - ``V4L2_AV1_FRAME_FLAG_BUFFER_REMOVAL_TIME_PRESENT``
+ - 0x00040000
+ - If set, specifies that buffer_removal_time is present. If not set,
+ specifies that buffer_removal_time is not present.
+ * - ``V4L2_AV1_FRAME_FLAG_FRAME_REFS_SHORT_SIGNALING``
+ - 0x00080000
+ - If set, indicates that only two reference frames are explicitly
+ signaled. If not set, indicates that all reference frames are explicitly
+ signaled.
+
+``V4L2_CID_STATELESS_AV1_FILM_GRAIN (struct)``
+ Represents the optional film grain parameters. See section
+ 6.8.20 "Film grain params semantics" of :ref:`av1` for more details.
+
+.. c:type:: v4l2_ctrl_av1_film_grain
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.5cm}|p{5.8cm}|p{10.0cm}|
+
+.. flat-table:: struct v4l2_ctrl_av1_film_grain
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``flags``
+ - See :ref:`AV1 Film Grain Flags <av1_film_grain_flags>`.
+ * - __u8
+ - ``cr_mult``
+ - Represents a multiplier for the cr component used in derivation of the
+ input index to the cr component scaling function.
+ * - __u16
+ - ``grain_seed``
+ - Specifies the starting value for the pseudo-random numbers used during
+ film grain synthesis.
+ * - __u8
+ - ``film_grain_params_ref_idx``
+ - Indicates which reference frame contains the film grain parameters to be
+ used for this frame.
+ * - __u8
+ - ``num_y_points``
+ - Specifies the number of points for the piece-wise linear scaling
+ function of the luma component.
+ * - __u8
+ - ``point_y_value[V4L2_AV1_MAX_NUM_Y_POINTS]``
+ - Represents the x (luma value) coordinate for the i-th point
+ of the piecewise linear scaling function for luma component. The values
+ are signaled on the scale of 0..255. In case of 10 bit video, these
+ values correspond to luma values divided by 4. In case of 12 bit video,
+ these values correspond to luma values divided by 16.
+ * - __u8
+ - ``point_y_scaling[V4L2_AV1_MAX_NUM_Y_POINTS]``
+ - Represents the scaling (output) value for the i-th point
+ of the piecewise linear scaling function for luma component.
+ * - __u8
+ - ``num_cb_points``
+ - Specifies the number of points for the piece-wise linear scaling
+ function of the cb component.
+ * - __u8
+ - ``point_cb_value[V4L2_AV1_MAX_NUM_CB_POINTS]``
+ - Represents the x coordinate for the i-th point of the
+ piece-wise linear scaling function for cb component. The values are
+ signaled on the scale of 0..255.
+ * - __u8
+ - ``point_cb_scaling[V4L2_AV1_MAX_NUM_CB_POINTS]``
+ - Represents the scaling (output) value for the i-th point of the
+ piecewise linear scaling function for cb component.
+ * - __u8
+ - ``num_cr_points``
+ - Represents the number of points for the piece-wise
+ linear scaling function of the cr component.
+ * - __u8
+ - ``point_cr_value[V4L2_AV1_MAX_NUM_CR_POINTS]``
+ - Represents the x coordinate for the i-th point of the
+ piece-wise linear scaling function for cr component. The values are
+ signaled on the scale of 0..255.
+ * - __u8
+ - ``point_cr_scaling[V4L2_AV1_MAX_NUM_CR_POINTS]``
+ - Represents the scaling (output) value for the i-th point of the
+ piecewise linear scaling function for cr component.
+ * - __u8
+ - ``grain_scaling_minus_8``
+ - Represents the shift - 8 applied to the values of the chroma component.
+ The grain_scaling_minus_8 can take values of 0..3 and determines the
+ range and quantization step of the standard deviation of film grain.
+ * - __u8
+ - ``ar_coeff_lag``
+ - Specifies the number of auto-regressive coefficients for luma and
+ chroma.
+ * - __u8
+ - ``ar_coeffs_y_plus_128[V4L2_AV1_AR_COEFFS_SIZE]``
+ - Specifies auto-regressive coefficients used for the Y plane.
+ * - __u8
+ - ``ar_coeffs_cb_plus_128[V4L2_AV1_AR_COEFFS_SIZE]``
+ - Specifies auto-regressive coefficients used for the U plane.
+ * - __u8
+ - ``ar_coeffs_cr_plus_128[V4L2_AV1_AR_COEFFS_SIZE]``
+ - Specifies auto-regressive coefficients used for the V plane.
+ * - __u8
+ - ``ar_coeff_shift_minus_6``
+ - Specifies the range of the auto-regressive coefficients. Values of 0,
+ 1, 2, and 3 correspond to the ranges for auto-regressive coefficients of
+ [-2, 2), [-1, 1), [-0.5, 0.5) and [-0.25, 0.25) respectively.
+ * - __u8
+ - ``grain_scale_shift``
+ - Specifies how much the Gaussian random numbers should be scaled down
+ during the grain synthesis process.
+ * - __u8
+ - ``cb_mult``
+ - Represents a multiplier for the cb component used in derivation of the
+ input index to the cb component scaling function.
+ * - __u8
+ - ``cb_luma_mult``
+ - Represents a multiplier for the average luma component used in
+ derivation of the input index to the cb component scaling function..
+ * - __u8
+ - ``cr_luma_mult``
+ - Represents a multiplier for the average luma component used in
+ derivation of the input index to the cr component scaling function.
+ * - __u16
+ - ``cb_offset``
+ - Represents an offset used in derivation of the input index to the
+ cb component scaling function.
+ * - __u16
+ - ``cr_offset``
+ - Represents an offset used in derivation of the input index to the
+ cr component scaling function.
+ * - __u8
+ - ``reserved[4]``
+ - Applications and drivers must set this to zero.
+
+.. _av1_film_grain_flags:
+
+``AV1 Film Grain Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_AV1_FILM_GRAIN_FLAG_APPLY_GRAIN``
+ - 0x00000001
+ - If set, specifies that film grain should be added to this frame. If not
+ set, specifies that film grain should not be added.
+ * - ``V4L2_AV1_FILM_GRAIN_FLAG_UPDATE_GRAIN``
+ - 0x00000002
+ - If set, means that a new set of parameters should be sent. If not set,
+ specifies that the previous set of parameters should be used.
+ * - ``V4L2_AV1_FILM_GRAIN_FLAG_CHROMA_SCALING_FROM_LUMA``
+ - 0x00000004
+ - If set, specifies that the chroma scaling is inferred from the luma
+ scaling.
+ * - ``V4L2_AV1_FILM_GRAIN_FLAG_OVERLAP``
+ - 0x00000008
+ - If set, indicates that the overlap between film grain blocks shall be
+ applied. If not set, indicates that the overlap between film grain blocks
+ shall not be applied.
+ * - ``V4L2_AV1_FILM_GRAIN_FLAG_CLIP_TO_RESTRICTED_RANGE``
+ - 0x00000010
+ - If set, indicates that clipping to the restricted (studio, i.e. limited)
+ range shall be applied to the sample values after adding the film grain
+ (see the semantics for color_range for an explanation of studio swing).
+ If not set, indicates that clipping to the full range shall be applied
+ to the sample values after adding the film grain.
diff --git a/Documentation/userspace-api/media/v4l/meta-formats.rst b/Documentation/userspace-api/media/v4l/meta-formats.rst
index fff2535..0bb61fc 100644
--- a/Documentation/userspace-api/media/v4l/meta-formats.rst
+++ b/Documentation/userspace-api/media/v4l/meta-formats.rst
@@ -12,10 +12,10 @@
.. toctree::
:maxdepth: 1
- pixfmt-meta-d4xx
- pixfmt-meta-intel-ipu3
- pixfmt-meta-rkisp1
- pixfmt-meta-uvc
- pixfmt-meta-vsp1-hgo
- pixfmt-meta-vsp1-hgt
- pixfmt-meta-vivid
+ metafmt-d4xx
+ metafmt-intel-ipu3
+ metafmt-rkisp1
+ metafmt-uvc
+ metafmt-vsp1-hgo
+ metafmt-vsp1-hgt
+ metafmt-vivid
diff --git a/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
new file mode 100644
index 0000000..5418360
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
@@ -0,0 +1,252 @@
+.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+
+.. _v4l2-meta-fmt-d4xx:
+
+*******************************
+V4L2_META_FMT_D4XX ('D4XX')
+*******************************
+
+Intel D4xx UVC Cameras Metadata
+
+
+Description
+===========
+
+Intel D4xx (D435, D455 and others) cameras include per-frame metadata in their UVC
+payload headers, following the Microsoft(R) UVC extension proposal [1_]. That
+means, that the private D4XX metadata, following the standard UVC header, is
+organised in blocks. D4XX cameras implement several standard block types,
+proposed by Microsoft, and several proprietary ones. Supported standard metadata
+types are MetadataId_CaptureStats (ID 3), MetadataId_CameraExtrinsics (ID 4),
+and MetadataId_CameraIntrinsics (ID 5). For their description see [1_]. This
+document describes proprietary metadata types, used by D4xx cameras.
+
+V4L2_META_FMT_D4XX buffers follow the metadata buffer layout of
+V4L2_META_FMT_UVC with the only difference, that it also includes proprietary
+payload header data. D4xx cameras use bulk transfers and only send one payload
+per frame, therefore their headers cannot be larger than 255 bytes.
+
+This document implements Intel Configuration version 3 [9_].
+
+Below are proprietary Microsoft style metadata types, used by D4xx cameras,
+where all fields are in little endian order:
+
+.. tabularcolumns:: |p{5.0cm}|p{12.5cm}|
+
+
+.. flat-table:: D4xx metadata
+ :widths: 1 2
+ :header-rows: 1
+ :stub-columns: 0
+
+ * - **Field**
+ - **Description**
+ * - :cspan:`1` *Depth Control*
+ * - __u32 ID
+ - 0x80000000
+ * - __u32 Size
+ - Size in bytes, include ID (all protocol versions: 60)
+ * - __u32 Version
+ - Version of this structure. The documentation herein covers versions 1,
+ 2 and 3. The version number will be incremented when new fields are
+ added.
+ * - __u32 Flags
+ - A bitmask of flags: see [2_] below
+ * - __u32 Gain
+ - Gain value in internal units, same as the V4L2_CID_GAIN control, used to
+ capture the frame
+ * - __u32 Exposure
+ - Exposure time (in microseconds) used to capture the frame
+ * - __u32 Laser power
+ - Power of the laser LED 0-360, used for depth measurement
+ * - __u32 AE mode
+ - 0: manual; 1: automatic exposure
+ * - __u32 Exposure priority
+ - Exposure priority value: 0 - constant frame rate
+ * - __u32 AE ROI left
+ - Left border of the AE Region of Interest (all ROI values are in pixels
+ and lie between 0 and maximum width or height respectively)
+ * - __u32 AE ROI right
+ - Right border of the AE Region of Interest
+ * - __u32 AE ROI top
+ - Top border of the AE Region of Interest
+ * - __u32 AE ROI bottom
+ - Bottom border of the AE Region of Interest
+ * - __u32 Preset
+ - Preset selector value, default: 0, unless changed by the user
+ * - __u8 Emitter mode (v3 only) (__u32 Laser mode for v1) [8_]
+ - 0: off, 1: on, same as __u32 Laser mode for v1
+ * - __u8 RFU byte (v3 only)
+ - Spare byte for future use
+ * - __u16 LED Power (v3 only)
+ - Led power value 0-360 (F416 SKU)
+ * - :cspan:`1` *Capture Timing*
+ * - __u32 ID
+ - 0x80000001
+ * - __u32 Size
+ - Size in bytes, include ID (all protocol versions: 40)
+ * - __u32 Version
+ - Version of this structure. The documentation herein corresponds to
+ version xxx. The version number will be incremented when new fields are
+ added.
+ * - __u32 Flags
+ - A bitmask of flags: see [3_] below
+ * - __u32 Frame counter
+ - Monotonically increasing counter
+ * - __u32 Optical time
+ - Time in microseconds from the beginning of a frame till its middle
+ * - __u32 Readout time
+ - Time, used to read out a frame in microseconds
+ * - __u32 Exposure time
+ - Frame exposure time in microseconds
+ * - __u32 Frame interval
+ - In microseconds = 1000000 / framerate
+ * - __u32 Pipe latency
+ - Time in microseconds from start of frame to data in USB buffer
+ * - :cspan:`1` *Configuration*
+ * - __u32 ID
+ - 0x80000002
+ * - __u32 Size
+ - Size in bytes, include ID (v1:36, v3:40)
+ * - __u32 Version
+ - Version of this structure. The documentation herein corresponds to
+ version xxx. The version number will be incremented when new fields are
+ added.
+ * - __u32 Flags
+ - A bitmask of flags: see [4_] below
+ * - __u8 Hardware type
+ - Camera hardware version [5_]
+ * - __u8 SKU ID
+ - Camera hardware configuration [6_]
+ * - __u32 Cookie
+ - Internal synchronisation
+ * - __u16 Format
+ - Image format code [7_]
+ * - __u16 Width
+ - Width in pixels
+ * - __u16 Height
+ - Height in pixels
+ * - __u16 Framerate
+ - Requested frame rate per second
+ * - __u16 Trigger
+ - Byte 0: bit 0: depth and RGB are synchronised, bit 1: external trigger
+ * - __u16 Calibration count (v3 only)
+ - Calibration counter, see [4_] below
+ * - __u8 GPIO input data (v3 only)
+ - GPIO readout, see [4_] below (Supported from FW 5.12.7.0)
+ * - __u32 Sub-preset info (v3 only)
+ - Sub-preset choice information, see [4_] below
+ * - __u8 reserved (v3 only)
+ - RFU byte.
+
+.. _1:
+
+[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5
+
+.. _2:
+
+[2] Depth Control flags specify which fields are valid: ::
+
+ 0x00000001 Gain
+ 0x00000002 Exposure
+ 0x00000004 Laser power
+ 0x00000008 AE mode
+ 0x00000010 Exposure priority
+ 0x00000020 AE ROI
+ 0x00000040 Preset
+ 0x00000080 Emitter mode
+ 0x00000100 LED Power
+
+.. _3:
+
+[3] Capture Timing flags specify which fields are valid: ::
+
+ 0x00000001 Frame counter
+ 0x00000002 Optical time
+ 0x00000004 Readout time
+ 0x00000008 Exposure time
+ 0x00000010 Frame interval
+ 0x00000020 Pipe latency
+
+.. _4:
+
+[4] Configuration flags specify which fields are valid: ::
+
+ 0x00000001 Hardware type
+ 0x00000002 SKU ID
+ 0x00000004 Cookie
+ 0x00000008 Format
+ 0x00000010 Width
+ 0x00000020 Height
+ 0x00000040 Framerate
+ 0x00000080 Trigger
+ 0x00000100 Cal count
+ 0x00000200 GPIO Input Data
+ 0x00000400 Sub-preset Info
+
+.. _5:
+
+[5] Camera model: ::
+
+ 0 DS5
+ 1 IVCAM2
+
+.. _6:
+
+[6] 8-bit camera hardware configuration bitfield: ::
+
+ [1:0] depthCamera
+ 00: no depth
+ 01: standard depth
+ 10: wide depth
+ 11: reserved
+ [2] depthIsActive - has a laser projector
+ [3] RGB presence
+ [4] Inertial Measurement Unit (IMU) presence
+ [5] projectorType
+ 0: HPTG
+ 1: Princeton
+ [6] 0: a projector, 1: an LED
+ [7] reserved
+
+.. _7:
+
+[7] Image format codes per video streaming interface:
+
+Depth: ::
+
+ 1 Z16
+ 2 Z
+
+Left sensor: ::
+
+ 1 Y8
+ 2 UYVY
+ 3 R8L8
+ 4 Calibration
+ 5 W10
+
+Fish Eye sensor: ::
+
+ 1 RAW8
+
+.. _8:
+
+[8] The "Laser mode" has been replaced in version 3 by three different fields.
+"Laser" has been renamed to "Emitter" as there are multiple technologies for
+camera projectors. As we have another field for "Laser Power" we introduced
+"LED Power" for extra emitter.
+
+The "Laser mode" __u32 fiels has been split into: ::
+ 1 __u8 Emitter mode
+ 2 __u8 RFU byte
+ 3 __u16 LED Power
+
+This is a change between versions 1 and 3. All versions 1, 2 and 3 are backward
+compatible with the same data format and they are supported. See [2_] for which
+attributes are valid.
+
+.. _9:
+
+[9] LibRealSense SDK metadata source:
+https://github.com/IntelRealSense/librealsense/blob/master/src/metadata.h
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst b/Documentation/userspace-api/media/v4l/metafmt-intel-ipu3.rst
similarity index 100%
rename from Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst
rename to Documentation/userspace-api/media/v4l/metafmt-intel-ipu3.rst
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst b/Documentation/userspace-api/media/v4l/metafmt-rkisp1.rst
similarity index 100%
rename from Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
rename to Documentation/userspace-api/media/v4l/metafmt-rkisp1.rst
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-uvc.rst b/Documentation/userspace-api/media/v4l/metafmt-uvc.rst
similarity index 100%
rename from Documentation/userspace-api/media/v4l/pixfmt-meta-uvc.rst
rename to Documentation/userspace-api/media/v4l/metafmt-uvc.rst
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-vivid.rst b/Documentation/userspace-api/media/v4l/metafmt-vivid.rst
similarity index 100%
rename from Documentation/userspace-api/media/v4l/pixfmt-meta-vivid.rst
rename to Documentation/userspace-api/media/v4l/metafmt-vivid.rst
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgo.rst b/Documentation/userspace-api/media/v4l/metafmt-vsp1-hgo.rst
similarity index 100%
rename from Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgo.rst
rename to Documentation/userspace-api/media/v4l/metafmt-vsp1-hgo.rst
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgt.rst b/Documentation/userspace-api/media/v4l/metafmt-vsp1-hgt.rst
similarity index 100%
rename from Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgt.rst
rename to Documentation/userspace-api/media/v4l/metafmt-vsp1-hgt.rst
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
index 06b78e55..806ed73 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
@@ -258,6 +258,22 @@
RV9 players - the format and decoder did not change, only
the encoder did. As a result, it uses the same FourCC.
+ * .. _V4L2-PIX-FMT-AV1-FRAME:
+
+ - ``V4L2_PIX_FMT_AV1_FRAME``
+ - 'AV1F'
+ - AV1 parsed frame, including the frame header, as extracted from the container.
+ This format is adapted for stateless video decoders that implement a AV1
+ pipeline with the :ref:`stateless_decoder`. Metadata associated with the
+ frame to decode is required to be passed through the
+ ``V4L2_CID_STATELESS_AV1_SEQUENCE``, ``V4L2_CID_STATELESS_AV1_FRAME``,
+ and ``V4L2_CID_STATELESS_AV1_TILE_GROUP_ENTRY`` controls.
+ See the :ref:`associated Codec Control IDs <v4l2-codec-stateless-av1>`.
+ Exactly one output and one capture buffer must be provided for use with
+ this pixel format. The output buffer must contain the appropriate number
+ of macroblocks to decode a full corresponding frame to the matching
+ capture buffer.
+
.. raw:: latex
\normalsize
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-d4xx.rst b/Documentation/userspace-api/media/v4l/pixfmt-meta-d4xx.rst
deleted file mode 100644
index 4e437ba..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-meta-d4xx.rst
+++ /dev/null
@@ -1,213 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _v4l2-meta-fmt-d4xx:
-
-*******************************
-V4L2_META_FMT_D4XX ('D4XX')
-*******************************
-
-Intel D4xx UVC Cameras Metadata
-
-
-Description
-===========
-
-Intel D4xx (D435 and other) cameras include per-frame metadata in their UVC
-payload headers, following the Microsoft(R) UVC extension proposal [1_]. That
-means, that the private D4XX metadata, following the standard UVC header, is
-organised in blocks. D4XX cameras implement several standard block types,
-proposed by Microsoft, and several proprietary ones. Supported standard metadata
-types are MetadataId_CaptureStats (ID 3), MetadataId_CameraExtrinsics (ID 4),
-and MetadataId_CameraIntrinsics (ID 5). For their description see [1_]. This
-document describes proprietary metadata types, used by D4xx cameras.
-
-V4L2_META_FMT_D4XX buffers follow the metadata buffer layout of
-V4L2_META_FMT_UVC with the only difference, that it also includes proprietary
-payload header data. D4xx cameras use bulk transfers and only send one payload
-per frame, therefore their headers cannot be larger than 255 bytes.
-
-Below are proprietary Microsoft style metadata types, used by D4xx cameras,
-where all fields are in little endian order:
-
-.. tabularcolumns:: |p{5.0cm}|p{12.5cm}|
-
-
-.. flat-table:: D4xx metadata
- :widths: 1 2
- :header-rows: 1
- :stub-columns: 0
-
- * - **Field**
- - **Description**
- * - :cspan:`1` *Depth Control*
- * - __u32 ID
- - 0x80000000
- * - __u32 Size
- - Size in bytes (currently 56)
- * - __u32 Version
- - Version of this structure. The documentation herein corresponds to
- version xxx. The version number will be incremented when new fields are
- added.
- * - __u32 Flags
- - A bitmask of flags: see [2_] below
- * - __u32 Gain
- - Gain value in internal units, same as the V4L2_CID_GAIN control, used to
- capture the frame
- * - __u32 Exposure
- - Exposure time (in microseconds) used to capture the frame
- * - __u32 Laser power
- - Power of the laser LED 0-360, used for depth measurement
- * - __u32 AE mode
- - 0: manual; 1: automatic exposure
- * - __u32 Exposure priority
- - Exposure priority value: 0 - constant frame rate
- * - __u32 AE ROI left
- - Left border of the AE Region of Interest (all ROI values are in pixels
- and lie between 0 and maximum width or height respectively)
- * - __u32 AE ROI right
- - Right border of the AE Region of Interest
- * - __u32 AE ROI top
- - Top border of the AE Region of Interest
- * - __u32 AE ROI bottom
- - Bottom border of the AE Region of Interest
- * - __u32 Preset
- - Preset selector value, default: 0, unless changed by the user
- * - __u32 Laser mode
- - 0: off, 1: on
- * - :cspan:`1` *Capture Timing*
- * - __u32 ID
- - 0x80000001
- * - __u32 Size
- - Size in bytes (currently 40)
- * - __u32 Version
- - Version of this structure. The documentation herein corresponds to
- version xxx. The version number will be incremented when new fields are
- added.
- * - __u32 Flags
- - A bitmask of flags: see [3_] below
- * - __u32 Frame counter
- - Monotonically increasing counter
- * - __u32 Optical time
- - Time in microseconds from the beginning of a frame till its middle
- * - __u32 Readout time
- - Time, used to read out a frame in microseconds
- * - __u32 Exposure time
- - Frame exposure time in microseconds
- * - __u32 Frame interval
- - In microseconds = 1000000 / framerate
- * - __u32 Pipe latency
- - Time in microseconds from start of frame to data in USB buffer
- * - :cspan:`1` *Configuration*
- * - __u32 ID
- - 0x80000002
- * - __u32 Size
- - Size in bytes (currently 40)
- * - __u32 Version
- - Version of this structure. The documentation herein corresponds to
- version xxx. The version number will be incremented when new fields are
- added.
- * - __u32 Flags
- - A bitmask of flags: see [4_] below
- * - __u8 Hardware type
- - Camera hardware version [5_]
- * - __u8 SKU ID
- - Camera hardware configuration [6_]
- * - __u32 Cookie
- - Internal synchronisation
- * - __u16 Format
- - Image format code [7_]
- * - __u16 Width
- - Width in pixels
- * - __u16 Height
- - Height in pixels
- * - __u16 Framerate
- - Requested frame rate per second
- * - __u16 Trigger
- - Byte 0: bit 0: depth and RGB are synchronised, bit 1: external trigger
-
-.. _1:
-
-[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5
-
-.. _2:
-
-[2] Depth Control flags specify which fields are valid: ::
-
- 0x00000001 Gain
- 0x00000002 Exposure
- 0x00000004 Laser power
- 0x00000008 AE mode
- 0x00000010 Exposure priority
- 0x00000020 AE ROI
- 0x00000040 Preset
-
-.. _3:
-
-[3] Capture Timing flags specify which fields are valid: ::
-
- 0x00000001 Frame counter
- 0x00000002 Optical time
- 0x00000004 Readout time
- 0x00000008 Exposure time
- 0x00000010 Frame interval
- 0x00000020 Pipe latency
-
-.. _4:
-
-[4] Configuration flags specify which fields are valid: ::
-
- 0x00000001 Hardware type
- 0x00000002 SKU ID
- 0x00000004 Cookie
- 0x00000008 Format
- 0x00000010 Width
- 0x00000020 Height
- 0x00000040 Framerate
- 0x00000080 Trigger
- 0x00000100 Cal count
-
-.. _5:
-
-[5] Camera model: ::
-
- 0 DS5
- 1 IVCAM2
-
-.. _6:
-
-[6] 8-bit camera hardware configuration bitfield: ::
-
- [1:0] depthCamera
- 00: no depth
- 01: standard depth
- 10: wide depth
- 11: reserved
- [2] depthIsActive - has a laser projector
- [3] RGB presence
- [4] Inertial Measurement Unit (IMU) presence
- [5] projectorType
- 0: HPTG
- 1: Princeton
- [6] 0: a projector, 1: an LED
- [7] reserved
-
-.. _7:
-
-[7] Image format codes per video streaming interface:
-
-Depth: ::
-
- 1 Z16
- 2 Z
-
-Left sensor: ::
-
- 1 Y8
- 2 UYVY
- 3 R8L8
- 4 Calibration
- 5 W10
-
-Fish Eye sensor: ::
-
- 1 RAW8
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
index 7232427..1840224 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
@@ -137,6 +137,13 @@
- Cb, Cr
- No
- Linear
+ * - V4L2_PIX_FMT_NV15_4L4
+ - 'VT15'
+ - 15
+ - 4:2:0
+ - Cb, Cr
+ - Yes
+ - 4x4 tiles
* - V4L2_PIX_FMT_NV16
- 'NV16'
- 8
@@ -378,6 +385,15 @@
Example V4L2_PIX_FMT_NV12MT memory layout of tiles
+.. _V4L2-PIX-FMT-NV15-4L4:
+
+Tiled NV15
+----------
+
+Semi-planar 10-bit YUV 4:2:0 formats, using 4x4 tiling.
+All components are packed without any padding between each other.
+As a side-effect, each group of 4 components are stored over 5 bytes
+(YYYY or UVUV = 4 * 10 bits = 40 bits = 5 bytes).
.. _V4L2-PIX-FMT-NV16:
.. _V4L2-PIX-FMT-NV61:
diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
index 5292d5e..f9f7353 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
@@ -185,12 +185,12 @@
- ``p_u32``
- A pointer to a matrix control of unsigned 32-bit values. Valid if
this control is of type ``V4L2_CTRL_TYPE_U32``.
- * - __u32 *
+ * - __s32 *
- ``p_s32``
- A pointer to a matrix control of signed 32-bit values. Valid if
this control is of type ``V4L2_CTRL_TYPE_INTEGER`` and
``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set.
- * - __u32 *
+ * - __s64 *
- ``p_s64``
- A pointer to a matrix control of signed 64-bit values. Valid if
this control is of type ``V4L2_CTRL_TYPE_INTEGER64`` and
@@ -279,6 +279,22 @@
- ``p_hevc_decode_params``
- A pointer to a struct :c:type:`v4l2_ctrl_hevc_decode_params`. Valid if this
control is of type ``V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS``.
+ * - struct :c:type:`v4l2_ctrl_av1_sequence` *
+ - ``p_av1_sequence``
+ - A pointer to a struct :c:type:`v4l2_ctrl_av1_sequence`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_AV1_SEQUENCE``.
+ * - struct :c:type:`v4l2_ctrl_av1_tile_group_entry` *
+ - ``p_av1_tile_group_entry``
+ - A pointer to a struct :c:type:`v4l2_ctrl_av1_tile_group_entry`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY``.
+ * - struct :c:type:`v4l2_ctrl_av1_frame` *
+ - ``p_av1_frame``
+ - A pointer to a struct :c:type:`v4l2_ctrl_av1_frame`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_AV1_FRAME``.
+ * - struct :c:type:`v4l2_ctrl_av1_film_grain` *
+ - ``p_av1_film_grain``
+ - A pointer to a struct :c:type:`v4l2_ctrl_av1_film_grain`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_AV1_FILM_GRAIN``.
* - void *
- ``ptr``
- A pointer to a compound type which can be an N-dimensional array
diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
index a20dfa2..4d38aca 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
@@ -525,6 +525,30 @@
- n/a
- A struct :c:type:`v4l2_ctrl_vp9_frame`, containing VP9
frame decode parameters for stateless video decoders.
+ * - ``V4L2_CTRL_TYPE_AV1_SEQUENCE``
+ - n/a
+ - n/a
+ - n/a
+ - A struct :c:type:`v4l2_ctrl_av1_sequence`, containing AV1 Sequence OBU
+ decoding parameters for stateless video decoders.
+ * - ``V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY``
+ - n/a
+ - n/a
+ - n/a
+ - A struct :c:type:`v4l2_ctrl_av1_tile_group_entry`, containing AV1 Tile Group
+ OBU decoding parameters for stateless video decoders.
+ * - ``V4L2_CTRL_TYPE_AV1_FRAME``
+ - n/a
+ - n/a
+ - n/a
+ - A struct :c:type:`v4l2_ctrl_av1_frame`, containing AV1 Frame/Frame
+ Header OBU decoding parameters for stateless video decoders.
+ * - ``V4L2_CTRL_TYPE_AV1_FILM_GRAIN``
+ - n/a
+ - n/a
+ - n/a
+ - A struct :c:type:`v4l2_ctrl_av1_film_grain`, containing AV1 Film Grain
+ parameters for stateless video decoders.
.. raw:: latex
diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
index 68ca343..2d6e3bb 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
@@ -122,7 +122,7 @@
:widths: 3 1 4
* - V4L2_SUBDEV_ROUTE_FL_ACTIVE
- - 0
+ - 0x0001
- The route is enabled. Set by applications.
Return Value
diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
index 2a589d3..3e58aac 100644
--- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
+++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
@@ -161,6 +161,10 @@
replace symbol V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_HEVC_SCALING_MATRIX :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS :c:type:`v4l2_ctrl_type`
+replace symbol V4L2_CTRL_TYPE_AV1_SEQUENCE :c:type:`v4l2_ctrl_type`
+replace symbol V4L2_CTRL_TYPE_AV1_TILE_GROUP_ENTRY :c:type:`v4l2_ctrl_type`
+replace symbol V4L2_CTRL_TYPE_AV1_FRAME :c:type:`v4l2_ctrl_type`
+replace symbol V4L2_CTRL_TYPE_AV1_FILM_GRAIN :c:type:`v4l2_ctrl_type`
# V4L2 capability defines
replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
diff --git a/Documentation/userspace-api/netlink/intro-specs.rst b/Documentation/userspace-api/netlink/intro-specs.rst
index a3b847e..bada896 100644
--- a/Documentation/userspace-api/netlink/intro-specs.rst
+++ b/Documentation/userspace-api/netlink/intro-specs.rst
@@ -78,3 +78,82 @@
The code generation itself is performed by ``tools/net/ynl/ynl-gen-c.py``
but it takes a few arguments so calling it directly for each file
quickly becomes tedious.
+
+YNL lib
+=======
+
+``tools/net/ynl/lib/`` contains an implementation of a C library
+(based on libmnl) which integrates with code generated by
+``tools/net/ynl/ynl-gen-c.py`` to create easy to use netlink wrappers.
+
+YNL basics
+----------
+
+The YNL library consists of two parts - the generic code (functions
+prefix by ``ynl_``) and per-family auto-generated code (prefixed
+with the name of the family).
+
+To create a YNL socket call ynl_sock_create() passing the family
+struct (family structs are exported by the auto-generated code).
+ynl_sock_destroy() closes the socket.
+
+YNL requests
+------------
+
+Steps for issuing YNL requests are best explained on an example.
+All the functions and types in this example come from the auto-generated
+code (for the netdev family in this case):
+
+.. code-block:: c
+
+ // 0. Request and response pointers
+ struct netdev_dev_get_req *req;
+ struct netdev_dev_get_rsp *d;
+
+ // 1. Allocate a request
+ req = netdev_dev_get_req_alloc();
+ // 2. Set request parameters (as needed)
+ netdev_dev_get_req_set_ifindex(req, ifindex);
+
+ // 3. Issues the request
+ d = netdev_dev_get(ys, req);
+ // 4. Free the request arguments
+ netdev_dev_get_req_free(req);
+ // 5. Error check (the return value from step 3)
+ if (!d) {
+ // 6. Print the YNL-generated error
+ fprintf(stderr, "YNL: %s\n", ys->err.msg);
+ return -1;
+ }
+
+ // ... do stuff with the response @d
+
+ // 7. Free response
+ netdev_dev_get_rsp_free(d);
+
+YNL dumps
+---------
+
+Performing dumps follows similar pattern as requests.
+Dumps return a list of objects terminated by a special marker,
+or NULL on error. Use ``ynl_dump_foreach()`` to iterate over
+the result.
+
+YNL notifications
+-----------------
+
+YNL lib supports using the same socket for notifications and
+requests. In case notifications arrive during processing of a request
+they are queued internally and can be retrieved at a later time.
+
+To subscribed to notifications use ``ynl_subscribe()``.
+The notifications have to be read out from the socket,
+``ynl_socket_get_fd()`` returns the underlying socket fd which can
+be plugged into appropriate asynchronous IO API like ``poll``,
+or ``select``.
+
+Notifications can be retrieved using ``ynl_ntf_dequeue()`` and have
+to be freed using ``ynl_ntf_free()``. Since we don't know the notification
+type upfront the notifications are returned as ``struct ynl_ntf_base_type *``
+and user is expected to cast them to the appropriate full type based
+on the ``cmd`` member.
diff --git a/Documentation/virt/guest-halt-polling.rst b/Documentation/virt/guest-halt-polling.rst
index b4e7479..922291d 100644
--- a/Documentation/virt/guest-halt-polling.rst
+++ b/Documentation/virt/guest-halt-polling.rst
@@ -72,7 +72,7 @@
Default: Y
-The module parameters can be set from the debugfs files in::
+The module parameters can be set from the sysfs files in::
/sys/module/haltpoll/parameters/
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index add0677..c0ddd30 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -2613,7 +2613,7 @@
this vcpu, and determines which register slices are visible through
this ioctl interface.
-(See Documentation/arm64/sve.rst for an explanation of the "vq"
+(See Documentation/arch/arm64/sve.rst for an explanation of the "vq"
nomenclature.)
KVM_REG_ARM64_SVE_VLS is only accessible after KVM_ARM_VCPU_INIT.
@@ -8445,6 +8445,33 @@
When getting the Modified Change Topology Report value, the attr->addr
must point to a byte where the value will be stored or retrieved from.
+8.40 KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE
+---------------------------------------
+
+:Capability: KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE
+:Architectures: arm64
+:Type: vm
+:Parameters: arg[0] is the new split chunk size.
+:Returns: 0 on success, -EINVAL if any memslot was already created.
+
+This capability sets the chunk size used in Eager Page Splitting.
+
+Eager Page Splitting improves the performance of dirty-logging (used
+in live migrations) when guest memory is backed by huge-pages. It
+avoids splitting huge-pages (into PAGE_SIZE pages) on fault, by doing
+it eagerly when enabling dirty logging (with the
+KVM_MEM_LOG_DIRTY_PAGES flag for a memory region), or when using
+KVM_CLEAR_DIRTY_LOG.
+
+The chunk size specifies how many pages to break at a time, using a
+single allocation for each chunk. Bigger the chunk size, more pages
+need to be allocated ahead of time.
+
+The chunk size needs to be a valid block size. The list of acceptable
+block sizes is exposed in KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES as a
+64-bit bitmap (each bit describing a block size). The default value is
+0, to disable the eager page splitting.
+
9. Known KVM API problems
=========================
diff --git a/Documentation/virt/kvm/halt-polling.rst b/Documentation/virt/kvm/halt-polling.rst
index 3fae39b..4f1a1b2 100644
--- a/Documentation/virt/kvm/halt-polling.rst
+++ b/Documentation/virt/kvm/halt-polling.rst
@@ -112,11 +112,11 @@
| | function. | |
+-----------------------+---------------------------+-------------------------+
-These module parameters can be set from the debugfs files in:
+These module parameters can be set from the sysfs files in:
/sys/module/kvm/parameters/
-Note: that these module parameters are system wide values and are not able to
+Note: these module parameters are system-wide values and are not able to
be tuned on a per vm basis.
Any changes to these parameters will be picked up by new and existing vCPUs the
@@ -142,12 +142,12 @@
global max polling interval (halt_poll_ns) then the host will always poll for the
entire block time and thus cpu utilisation will go to 100%.
-- Halt polling essentially presents a trade off between power usage and latency and
+- Halt polling essentially presents a trade-off between power usage and latency and
the module parameters should be used to tune the affinity for this. Idle cpu time is
essentially converted to host kernel time with the aim of decreasing latency when
entering the guest.
- Halt polling will only be conducted by the host when no other tasks are runnable on
that cpu, otherwise the polling will cease immediately and schedule will be invoked to
- allow that other task to run. Thus this doesn't allow a guest to denial of service the
- cpu.
+ allow that other task to run. Thus this doesn't allow a guest to cause denial of service
+ of the cpu.
diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
index 8c77554..3a034db 100644
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@@ -67,7 +67,7 @@
2. Write-Protection: The SPTE is present and the fault is caused by
write-protect. That means we just need to change the W bit of the spte.
-What we use to avoid all the race is the Host-writable bit and MMU-writable bit
+What we use to avoid all the races is the Host-writable bit and MMU-writable bit
on the spte:
- Host-writable means the gfn is writable in the host kernel page tables and in
@@ -130,7 +130,7 @@
A solution for indirect sp could be to pin the gfn, for example via
kvm_vcpu_gfn_to_pfn_atomic, before the cmpxchg. After the pinning:
-- We have held the refcount of pfn that means the pfn can not be freed and
+- We have held the refcount of pfn; that means the pfn can not be freed and
be reused for another gfn.
- The pfn is writable and therefore it cannot be shared between different gfns
by KSM.
@@ -186,22 +186,22 @@
The Dirty bit is lost in this case.
In order to avoid this kind of issue, we always treat the spte as "volatile"
-if it can be updated out of mmu-lock, see spte_has_volatile_bits(), it means,
+if it can be updated out of mmu-lock [see spte_has_volatile_bits()]; it means
the spte is always atomically updated in this case.
3) flush tlbs due to spte updated
-If the spte is updated from writable to readonly, we should flush all TLBs,
+If the spte is updated from writable to read-only, we should flush all TLBs,
otherwise rmap_write_protect will find a read-only spte, even though the
writable spte might be cached on a CPU's TLB.
As mentioned before, the spte can be updated to writable out of mmu-lock on
-fast page fault path, in order to easily audit the path, we see if TLBs need
-be flushed caused by this reason in mmu_spte_update() since this is a common
+fast page fault path. In order to easily audit the path, we see if TLBs needing
+to be flushed caused this reason in mmu_spte_update() since this is a common
function to update spte (present -> present).
Since the spte is "volatile" if it can be updated out of mmu-lock, we always
-atomically update the spte, the race caused by fast page fault can be avoided,
+atomically update the spte and the race caused by fast page fault can be avoided.
See the comments in spte_has_volatile_bits() and mmu_spte_update().
Lockless Access Tracking:
@@ -283,9 +283,9 @@
:Arch: x86
:Protects: wakeup_vcpus_on_cpu
:Comment: This is a per-CPU lock and it is used for VT-d posted-interrupts.
- When VT-d posted-interrupts is supported and the VM has assigned
+ When VT-d posted-interrupts are supported and the VM has assigned
devices, we put the blocked vCPU on the list blocked_vcpu_on_cpu
- protected by blocked_vcpu_on_cpu_lock, when VT-d hardware issues
+ protected by blocked_vcpu_on_cpu_lock. When VT-d hardware issues
wakeup notification event since external interrupts from the
assigned devices happens, we will find the vCPU on the list to
wakeup.
diff --git a/Documentation/virt/kvm/ppc-pv.rst b/Documentation/virt/kvm/ppc-pv.rst
index 5fdb907..740d03d 100644
--- a/Documentation/virt/kvm/ppc-pv.rst
+++ b/Documentation/virt/kvm/ppc-pv.rst
@@ -89,7 +89,7 @@
registers. Only if the host supports the additional features, make use of them.
The magic page layout is described by struct kvm_vcpu_arch_shared
-in arch/powerpc/include/asm/kvm_para.h.
+in arch/powerpc/include/uapi/asm/kvm_para.h.
Magic page features
===================
@@ -112,7 +112,7 @@
================
In addition to features that indicate whether a host is capable of a particular
-feature we also have a channel for a guest to tell the guest whether it's capable
+feature we also have a channel for a guest to tell the host whether it's capable
of something. This is what we call "flags".
Flags are passed to the host in the low 12 bits of the Effective Address.
@@ -139,7 +139,7 @@
====================
The "ld" and "std" instructions are transformed to "lwz" and "stw" instructions
-respectively on 32 bit systems with an added offset of 4 to accommodate for big
+respectively on 32-bit systems with an added offset of 4 to accommodate for big
endianness.
The following is a list of mapping the Linux kernel performs when running as
@@ -210,7 +210,7 @@
2) PAPR hypercalls
PAPR hypercalls are needed to run server PowerPC PAPR guests (-M pseries in QEMU).
-These are the same hypercalls that pHyp, the POWER hypervisor implements. Some of
+These are the same hypercalls that pHyp, the POWER hypervisor, implements. Some of
them are handled in the kernel, some are handled in user space. This is only
available on book3s_64.
diff --git a/Documentation/virt/kvm/vcpu-requests.rst b/Documentation/virt/kvm/vcpu-requests.rst
index 87f04c1..06718b9 100644
--- a/Documentation/virt/kvm/vcpu-requests.rst
+++ b/Documentation/virt/kvm/vcpu-requests.rst
@@ -101,7 +101,7 @@
However, VCPU request users should refrain from doing so, as it would
break the abstraction. The first 8 bits are reserved for architecture
-independent requests, all additional bits are available for architecture
+independent requests; all additional bits are available for architecture
dependent requests.
Architecture Independent Requests
@@ -151,8 +151,8 @@
This flag is applied to requests that only need immediate attention
from VCPUs running in guest mode. That is, sleeping VCPUs do not need
- to be awaken for these requests. Sleeping VCPUs will handle the
- requests when they are awaken later for some other reason.
+ to be awakened for these requests. Sleeping VCPUs will handle the
+ requests when they are awakened later for some other reason.
KVM_REQUEST_WAIT
diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
index 487b632..9957800 100644
--- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
@@ -57,7 +57,7 @@
The main ioctl to access SEV is KVM_MEMORY_ENCRYPT_OP. If the argument
to KVM_MEMORY_ENCRYPT_OP is NULL, the ioctl returns 0 if SEV is enabled
-and ``ENOTTY` if it is disabled (on some older versions of Linux,
+and ``ENOTTY`` if it is disabled (on some older versions of Linux,
the ioctl runs normally even with a NULL argument, and therefore will
likely return ``EFAULT``). If non-NULL, the argument to KVM_MEMORY_ENCRYPT_OP
must be a struct kvm_sev_cmd::
diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst
index 8364afa..26f6203 100644
--- a/Documentation/virt/kvm/x86/mmu.rst
+++ b/Documentation/virt/kvm/x86/mmu.rst
@@ -205,7 +205,7 @@
role.passthrough:
The page is not backed by a guest page table, but its first entry
points to one. This is set if NPT uses 5-level page tables (host
- CR4.LA57=1) and is shadowing L1's 4-level NPT (L1 CR4.LA57=1).
+ CR4.LA57=1) and is shadowing L1's 4-level NPT (L1 CR4.LA57=0).
gfn:
Either the guest page table containing the translations shadowed by this
page, or the base page frame for linear translations. See role.direct.
diff --git a/Documentation/virt/paravirt_ops.rst b/Documentation/virt/paravirt_ops.rst
index 6b789d2..62d867e 100644
--- a/Documentation/virt/paravirt_ops.rst
+++ b/Documentation/virt/paravirt_ops.rst
@@ -5,31 +5,31 @@
============
Linux provides support for different hypervisor virtualization technologies.
-Historically different binary kernels would be required in order to support
-different hypervisors, this restriction was removed with pv_ops.
+Historically, different binary kernels would be required in order to support
+different hypervisors; this restriction was removed with pv_ops.
Linux pv_ops is a virtualization API which enables support for different
hypervisors. It allows each hypervisor to override critical operations and
allows a single kernel binary to run on all supported execution environments
including native machine -- without any hypervisors.
pv_ops provides a set of function pointers which represent operations
-corresponding to low level critical instructions and high level
-functionalities in various areas. pv-ops allows for optimizations at run
-time by enabling binary patching of the low-ops critical operations
+corresponding to low-level critical instructions and high-level
+functionalities in various areas. pv_ops allows for optimizations at run
+time by enabling binary patching of the low-level critical operations
at boot time.
pv_ops operations are classified into three categories:
- simple indirect call
- These operations correspond to high level functionality where it is
+ These operations correspond to high-level functionality where it is
known that the overhead of indirect call isn't very important.
- indirect call which allows optimization with binary patch
- Usually these operations correspond to low level critical instructions. They
+ Usually these operations correspond to low-level critical instructions. They
are called frequently and are performance critical. The overhead is
very important.
- a set of macros for hand written assembly code
Hand written assembly codes (.S files) also need paravirtualization
- because they include sensitive instructions or some of code paths in
+ because they include sensitive instructions or some code paths in
them are very performance critical.
diff --git a/Documentation/wmi/acpi-interface.rst b/Documentation/wmi/acpi-interface.rst
new file mode 100644
index 0000000..d31af0e
--- /dev/null
+++ b/Documentation/wmi/acpi-interface.rst
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==================
+ACPI WMI interface
+==================
+
+The ACPI WMI interface is a proprietary extension of the ACPI specification made
+by Microsoft to allow hardware vendors to embed WMI (Windows Management Instrumentation)
+objects inside their ACPI firmware. Typical functions implemented over ACPI WMI
+are hotkey events on modern notebooks and configuration of BIOS options.
+
+PNP0C14 ACPI device
+-------------------
+
+Discovery of WMI objects is handled by defining ACPI devices with a PNP ID
+of ``PNP0C14``. These devices will contain a set of ACPI buffers and methods
+used for mapping and execution of WMI methods and/or queries. If there exist
+multiple of such devices, then each device is required to have a
+unique ACPI UID.
+
+_WDG buffer
+-----------
+
+The ``_WDG`` buffer is used to discover WMI objects and is required to be
+static. Its internal structure consists of data blocks with a size of 20 bytes,
+containing the following data:
+
+======= =============== =====================================================
+Offset Size (in bytes) Content
+======= =============== =====================================================
+0x00 16 128 bit Variant 2 object GUID.
+0x10 2 2 character method ID or single byte notification ID.
+0x12 1 Object instance count.
+0x13 1 Object flags.
+======= =============== =====================================================
+
+The WMI object flags control whether the method or notification ID is used:
+
+- 0x1: Data block usage is expensive and must be explicitly enabled/disabled.
+- 0x2: Data block contains WMI methods.
+- 0x4: Data block contains ASCIZ string.
+- 0x8: Data block describes a WMI event, use notification ID instead
+ of method ID.
+
+Each WMI object GUID can appear multiple times inside a system.
+The method/notification ID is used to construct the ACPI method names used for
+interacting with the WMI object.
+
+WQxx ACPI methods
+-----------------
+
+If a data block does not contain WMI methods, then its content can be retrieved
+by this required ACPI method. The last two characters of the ACPI method name
+are the method ID of the data block to query. Their single parameter is an
+integer describing the instance which should be queried. This parameter can be
+omitted if the data block contains only a single instance.
+
+WSxx ACPI methods
+-----------------
+
+Similar to the ``WQxx`` ACPI methods, except that it is optional and takes an
+additional buffer as its second argument. The instance argument also cannot
+be omitted.
+
+WMxx ACPI methods
+-----------------
+
+Used for executing WMI methods associated with a data block. The last two
+characters of the ACPI method name are the method ID of the data block
+containing the WMI methods. Their first parameter is a integer describing the
+instance which methods should be executed. The second parameter is an integer
+describing the WMI method ID to execute, and the third parameter is a buffer
+containing the WMI method parameters. If the data block is marked as containing
+an ASCIZ string, then this buffer should contain an ASCIZ string. The ACPI
+method will return the result of the executed WMI method.
+
+WExx ACPI methods
+-----------------
+
+Used for optionally enabling/disabling WMI events, the last two characters of
+the ACPI method are the notification ID of the data block describing the WMI
+event as hexadecimal value. Their first parameter is an integer with a value
+of 0 if the WMI event should be disabled, other values will enable
+the WMI event.
+
+WCxx ACPI methods
+-----------------
+Similar to the ``WExx`` ACPI methods, except that it controls data collection
+instead of events and thus the last two characters of the ACPI method name are
+the method ID of the data block to enable/disable.
+
+_WED ACPI method
+----------------
+
+Used to retrieve additional WMI event data, its single parameter is a integer
+holding the notification ID of the event.
diff --git a/Documentation/wmi/devices/dell-wmi-ddv.rst b/Documentation/wmi/devices/dell-wmi-ddv.rst
new file mode 100644
index 0000000..bf963d9
--- /dev/null
+++ b/Documentation/wmi/devices/dell-wmi-ddv.rst
@@ -0,0 +1,297 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+============================================
+Dell DDV WMI interface driver (dell-wmi-ddv)
+============================================
+
+Introduction
+============
+
+Many Dell notebooks made after ~2020 support a WMI-based interface for
+retrieving various system data like battery temperature, ePPID, diagostic data
+and fan/thermal sensor data.
+
+This interface is likely used by the `Dell Data Vault` software on Windows,
+so it was called `DDV`. Currently the ``dell-wmi-ddv`` driver supports
+version 2 and 3 of the interface, with support for new interface versions
+easily added.
+
+.. warning:: The interface is regarded as internal by Dell, so no vendor
+ documentation is available. All knowledge was thus obtained by
+ trial-and-error, please keep that in mind.
+
+Dell ePPID (electronic Piece Part Identification)
+=================================================
+
+The Dell ePPID is used to uniquely identify components in Dell machines,
+including batteries. It has a form similar to `CC-PPPPPP-MMMMM-YMD-SSSS-FFF`
+and contains the following information:
+
+* Country code of origin (CC).
+* Part number with the first character being a filling number (PPPPPP).
+* Manufacture Identification (MMMMM).
+* Manufacturing Year/Month/Date (YMD) in base 36, with Y being the last digit
+ of the year.
+* Manufacture Sequence Number (SSSS).
+* Optional Firmware Version/Revision (FFF).
+
+The `eppidtool <https://pypi.org/project/eppidtool>`_ python utility can be used
+to decode and display this information.
+
+All information regarding the Dell ePPID was gathered using Dell support
+documentation and `this website <https://telcontar.net/KBK/Dell/date_codes>`_.
+
+WMI interface description
+=========================
+
+The WMI interface description can be decoded from the embedded binary MOF (bmof)
+data using the `bmfdec <https://github.com/pali/bmfdec>`_ utility:
+
+::
+
+ [WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x409"), Description("WMI Function"), guid("{8A42EA14-4F2A-FD45-6422-0087F7A7E608}")]
+ class DDVWmiMethodFunction {
+ [key, read] string InstanceName;
+ [read] boolean Active;
+
+ [WmiMethodId(1), Implemented, read, write, Description("Return Battery Design Capacity.")] void BatteryDesignCapacity([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(2), Implemented, read, write, Description("Return Battery Full Charge Capacity.")] void BatteryFullChargeCapacity([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(3), Implemented, read, write, Description("Return Battery Manufacture Name.")] void BatteryManufactureName([in] uint32 arg2, [out] string argr);
+ [WmiMethodId(4), Implemented, read, write, Description("Return Battery Manufacture Date.")] void BatteryManufactureDate([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(5), Implemented, read, write, Description("Return Battery Serial Number.")] void BatterySerialNumber([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(6), Implemented, read, write, Description("Return Battery Chemistry Value.")] void BatteryChemistryValue([in] uint32 arg2, [out] string argr);
+ [WmiMethodId(7), Implemented, read, write, Description("Return Battery Temperature.")] void BatteryTemperature([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(8), Implemented, read, write, Description("Return Battery Current.")] void BatteryCurrent([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(9), Implemented, read, write, Description("Return Battery Voltage.")] void BatteryVoltage([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(10), Implemented, read, write, Description("Return Battery Manufacture Access(MA code).")] void BatteryManufactureAceess([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(11), Implemented, read, write, Description("Return Battery Relative State-Of-Charge.")] void BatteryRelativeStateOfCharge([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(12), Implemented, read, write, Description("Return Battery Cycle Count")] void BatteryCycleCount([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(13), Implemented, read, write, Description("Return Battery ePPID")] void BatteryePPID([in] uint32 arg2, [out] string argr);
+ [WmiMethodId(14), Implemented, read, write, Description("Return Battery Raw Analytics Start")] void BatteryeRawAnalyticsStart([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(15), Implemented, read, write, Description("Return Battery Raw Analytics")] void BatteryeRawAnalytics([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]);
+ [WmiMethodId(16), Implemented, read, write, Description("Return Battery Design Voltage.")] void BatteryDesignVoltage([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(17), Implemented, read, write, Description("Return Battery Raw Analytics A Block")] void BatteryeRawAnalyticsABlock([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]);
+ [WmiMethodId(18), Implemented, read, write, Description("Return Version.")] void ReturnVersion([in] uint32 arg2, [out] uint32 argr);
+ [WmiMethodId(32), Implemented, read, write, Description("Return Fan Sensor Information")] void FanSensorInformation([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]);
+ [WmiMethodId(34), Implemented, read, write, Description("Return Thermal Sensor Information")] void ThermalSensorInformation([in] uint32 arg2, [out] uint32 RawSize, [out, WmiSizeIs("RawSize") : ToInstance] uint8 RawData[]);
+ };
+
+Each WMI method takes an ACPI buffer containing a 32-bit index as input argument,
+with the first 8 bit being used to specify the battery when using battery-related
+WMI methods. Other WMI methods may ignore this argument or interpret it
+differently. The WMI method output format varies:
+
+* if the function has only a single output, then an ACPI object
+ of the corresponding type is returned
+* if the function has multiple outputs, when an ACPI package
+ containing the outputs in the same order is returned
+
+The format of the output should be thoroughly checked, since many methods can
+return malformed data in case of an error.
+
+The data format of many battery-related methods seems to be based on the
+`Smart Battery Data Specification`, so unknown battery-related methods are
+likely to follow this standard in some way.
+
+WMI method GetBatteryDesignCapacity()
+-------------------------------------
+
+Returns the design capacity of the battery in mAh as an u16.
+
+WMI method BatteryFullCharge()
+------------------------------
+
+Returns the full charge capacity of the battery in mAh as an u16.
+
+WMI method BatteryManufactureName()
+-----------------------------------
+
+Returns the manufacture name of the battery as an ASCII string.
+
+WMI method BatteryManufactureDate()
+-----------------------------------
+
+Returns the manufacture date of the battery as an u16.
+The date is encoded in the following manner:
+
+- bits 0 to 4 contain the manufacture day.
+- bits 5 to 8 contain the manufacture month.
+- bits 9 to 15 contain the manufacture year biased by 1980.
+
+.. note::
+ The data format needs to be verified on more machines.
+
+WMI method BatterySerialNumber()
+--------------------------------
+
+Returns the serial number of the battery as an u16.
+
+WMI method BatteryChemistryValue()
+----------------------------------
+
+Returns the chemistry of the battery as an ASCII string.
+Known values are:
+
+- "Li-I" for Li-Ion
+
+WMI method BatteryTemperature()
+-------------------------------
+
+Returns the temperature of the battery in tenth degree kelvin as an u16.
+
+WMI method BatteryCurrent()
+---------------------------
+
+Returns the current flow of the battery in mA as an s16.
+Negative values indicate discharging.
+
+WMI method BatteryVoltage()
+---------------------------
+
+Returns the voltage flow of the battery in mV as an u16.
+
+WMI method BatteryManufactureAccess()
+-------------------------------------
+
+Returns a manufacture-defined value as an u16.
+
+WMI method BatteryRelativeStateOfCharge()
+-----------------------------------------
+
+Returns the capacity of the battery in percent as an u16.
+
+WMI method BatteryCycleCount()
+------------------------------
+
+Returns the cycle count of the battery as an u16.
+
+WMI method BatteryePPID()
+-------------------------
+
+Returns the ePPID of the battery as an ASCII string.
+
+WMI method BatteryeRawAnalyticsStart()
+--------------------------------------
+
+Performs an analysis of the battery and returns a status code:
+
+- ``0x0``: Success
+- ``0x1``: Interface not supported
+- ``0xfffffffe``: Error/Timeout
+
+.. note::
+ The meaning of this method is still largely unknown.
+
+WMI method BatteryeRawAnalytics()
+---------------------------------
+
+Returns a buffer usually containg 12 blocks of analytics data.
+Those blocks contain:
+
+- a block number starting with 0 (u8)
+- 31 bytes of unknown data
+
+.. note::
+ The meaning of this method is still largely unknown.
+
+WMI method BatteryDesignVoltage()
+---------------------------------
+
+Returns the design voltage of the battery in mV as an u16.
+
+WMI method BatteryeRawAnalyticsABlock()
+---------------------------------------
+
+Returns a single block of analytics data, with the second byte
+of the index being used for selecting the block number.
+
+*Supported since WMI interface version 3!*
+
+.. note::
+ The meaning of this method is still largely unknown.
+
+WMI method ReturnVersion()
+--------------------------
+
+Returns the WMI interface version as an u32.
+
+WMI method FanSensorInformation()
+---------------------------------
+
+Returns a buffer containg fan sensor entries, terminated
+with a single ``0xff``.
+Those entries contain:
+
+- fan type (u8)
+- fan speed in RPM (little endian u16)
+
+WMI method ThermalSensorInformation()
+-------------------------------------
+
+Returns a buffer containing thermal sensor entries, terminated
+with a single ``0xff``.
+Those entries contain:
+
+- thermal type (u8)
+- current temperature (s8)
+- min. temperature (s8)
+- max. temperature (s8)
+- unknown field (u8)
+
+.. note::
+ TODO: Find out what the meaning of the last byte is.
+
+ACPI battery matching algorithm
+===============================
+
+The algorithm used to match ACPI batteries to indices is based on information
+which was found inside the logging messages of the OEM software.
+
+Basically for each new ACPI battery, the serial numbers of the batteries behind
+indices 1 till 3 are compared with the serial number of the ACPI battery.
+Since the serial number of the ACPI battery can either be encoded as a normal
+integer or as a hexadecimal value, both cases need to be checked. The first
+index with a matching serial number is then selected.
+
+A serial number of 0 indicates that the corresponding index is not associated
+with an actual battery, or that the associated battery is not present.
+
+Some machines like the Dell Inspiron 3505 only support a single battery and thus
+ignore the battery index. Because of this the driver depends on the ACPI battery
+hook mechanism to discover batteries.
+
+.. note::
+ The ACPI battery matching algorithm currently used inside the driver is
+ outdated and does not match the algorithm described above. The reasons for
+ this are differences in the handling of the ToHexString() ACPI opcode between
+ Linux and Windows, which distorts the serial number of ACPI batteries on many
+ machines. Until this issue is resolved, the driver cannot use the above
+ algorithm.
+
+Reverse-Engineering the DDV WMI interface
+=========================================
+
+1. Find a supported Dell notebook, usually made after ~2020.
+2. Dump the ACPI tables and search for the WMI device (usually called "ADDV").
+3. Decode the corresponding bmof data and look at the ASL code.
+4. Try to deduce the meaning of a certain WMI method by comparing the control
+ flow with other ACPI methods (_BIX or _BIF for battery related methods
+ for example).
+5. Use the built-in UEFI diagostics to view sensor types/values for fan/thermal
+ related methods (sometimes overwriting static ACPI data fields can be used
+ to test different sensor type values, since on some machines this data is
+ not reinitialized upon a warm reset).
+
+Alternatively:
+
+1. Load the ``dell-wmi-ddv`` driver, use the ``force`` module param
+ if necessary.
+2. Use the debugfs interface to access the raw fan/thermal sensor buffer data.
+3. Compare the data with the built-in UEFI diagnostics.
+
+In case the DDV WMI interface version available on your Dell notebook is not
+supported or you are seeing unknown fan/thermal sensors, please submit a
+bugreport on `bugzilla <https://bugzilla.kernel.org>`_ so they can be added
+to the ``dell-wmi-ddv`` driver.
+
+See Documentation/admin-guide/reporting-issues.rst for further information.
diff --git a/Documentation/wmi/devices/index.rst b/Documentation/wmi/devices/index.rst
new file mode 100644
index 0000000..c08735a
--- /dev/null
+++ b/Documentation/wmi/devices/index.rst
@@ -0,0 +1,22 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+=============================
+Driver-specific Documentation
+=============================
+
+This section provides information about various devices supported by
+the Linux kernel, their protocols and driver details.
+
+.. toctree::
+ :maxdepth: 1
+ :numbered:
+ :glob:
+
+ *
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/wmi/devices/wmi-bmof.rst b/Documentation/wmi/devices/wmi-bmof.rst
new file mode 100644
index 0000000..ca1ee9a
--- /dev/null
+++ b/Documentation/wmi/devices/wmi-bmof.rst
@@ -0,0 +1,25 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+==============================
+WMI embedded Binary MOF driver
+==============================
+
+Introduction
+============
+
+Many machines embed WMI Binary MOF (Managed Object Format) metadata used to
+describe the details of their ACPI WMI interfaces. The data can be decoded
+with tools like `bmfdec <https://github.com/pali/bmfdec>`_ to obtain a
+human readable WMI interface description, which is useful for developing
+new WMI drivers.
+
+The Binary MOF data can be retrieved from the ``bmof`` sysfs attribute of the
+associated WMI device. Please note that multiple WMI devices containing Binary
+MOF data can exist on a given system.
+
+WMI interface
+=============
+
+The Binary MOF WMI device is identified by the WMI GUID ``05901221-D566-11D1-B2F0-00A0C9062910``.
+The Binary MOF can be obtained by doing a WMI data block query. The result is
+then returned as an ACPI buffer with a variable size.
diff --git a/Documentation/wmi/index.rst b/Documentation/wmi/index.rst
new file mode 100644
index 0000000..537cff1
--- /dev/null
+++ b/Documentation/wmi/index.rst
@@ -0,0 +1,19 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+=============
+WMI Subsystem
+=============
+
+.. toctree::
+ :maxdepth: 1
+
+ acpi-interface
+ devices/index
+
+.. only:: subproject and html
+
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/MAINTAINERS b/MAINTAINERS
index 6992b7c..0903d87 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,81 +1,5 @@
-List of maintainers and how to submit kernel changes
-====================================================
-
-Please try to follow the guidelines below. This will make things
-easier on the maintainers. Not all of these guidelines matter for every
-trivial patch so apply some common sense.
-
-Tips for patch submitters
--------------------------
-
-1. Always *test* your changes, however small, on at least 4 or
- 5 people, preferably many more.
-
-2. Try to release a few ALPHA test versions to the net. Announce
- them onto the kernel channel and await results. This is especially
- important for device drivers, because often that's the only way
- you will find things like the fact version 3 firmware needs
- a magic fix you didn't know about, or some clown changed the
- chips on a board and not its name. (Don't laugh! Look at the
- SMC etherpower for that.)
-
-3. Make sure your changes compile correctly in multiple
- configurations. In particular check that changes work both as a
- module and built into the kernel.
-
-4. When you are happy with a change make it generally available for
- testing and await feedback.
-
-5. Make a patch available to the relevant maintainer in the list. Use
- ``diff -u`` to make the patch easy to merge. Be prepared to get your
- changes sent back with seemingly silly requests about formatting
- and variable names. These aren't as silly as they seem. One
- job the maintainers (and especially Linus) do is to keep things
- looking the same. Sometimes this means that the clever hack in
- your driver to get around a problem actually needs to become a
- generalized kernel feature ready for next time.
-
- PLEASE check your patch with the automated style checker
- (scripts/checkpatch.pl) to catch trivial style violations.
- See Documentation/process/coding-style.rst for guidance here.
-
- PLEASE CC: the maintainers and mailing lists that are generated
- by ``scripts/get_maintainer.pl.`` The results returned by the
- script will be best if you have git installed and are making
- your changes in a branch derived from Linus' latest git tree.
- See Documentation/process/submitting-patches.rst for details.
-
- PLEASE try to include any credit lines you want added with the
- patch. It avoids people being missed off by mistake and makes
- it easier to know who wants adding and who doesn't.
-
- PLEASE document known bugs. If it doesn't work for everything
- or does something very odd once a month document it.
-
- PLEASE remember that submissions must be made under the terms
- of the Linux Foundation certificate of contribution and should
- include a Signed-off-by: line. The current version of this
- "Developer's Certificate of Origin" (DCO) is listed in the file
- Documentation/process/submitting-patches.rst.
-
-6. Make sure you have the right to send any changes you make. If you
- do changes at work you may find your employer owns the patch
- not you.
-
-7. When sending security related changes or reports to a maintainer
- please Cc: security@kernel.org, especially if the maintainer
- does not respond. Please keep in mind that the security team is
- a small set of people who can be efficient only when working on
- verified bugs. Please only Cc: this list when you have identified
- that the bug would present a short-term risk to other users if it
- were publicly disclosed. For example, reports of address leaks do
- not represent an immediate threat and are better handled publicly,
- and ideally, should come with a patch proposal. Please do not send
- automated reports to this list either. Such bugs will be handled
- better and faster in the usual public places. See
- Documentation/process/security-bugs.rst for details.
-
-8. Happy hacking.
+List of maintainers
+===================
Descriptions of section entries and preferred order
---------------------------------------------------
@@ -406,6 +330,13 @@
S: Maintained
F: drivers/acpi/arm64
+ACPI FOR RISC-V (ACPI/riscv)
+M: Sunil V L <sunilvl@ventanamicro.com>
+L: linux-acpi@vger.kernel.org
+L: linux-riscv@lists.infradead.org
+S: Maintained
+F: drivers/acpi/riscv/
+
ACPI PCC(Platform Communication Channel) MAILBOX DRIVER
M: Sudeep Holla <sudeep.holla@arm.com>
L: linux-acpi@vger.kernel.org
@@ -449,6 +380,8 @@
ACPI WMI DRIVER
L: platform-driver-x86@vger.kernel.org
S: Orphan
+F: Documentation/driver-api/wmi.rst
+F: Documentation/wmi/
F: drivers/platform/x86/wmi.c
F: include/uapi/linux/wmi.h
@@ -909,13 +842,6 @@
S: Maintained
F: drivers/net/ethernet/altera/
-ALTERA TSE PCS
-M: Maxime Chevallier <maxime.chevallier@bootlin.com>
-L: netdev@vger.kernel.org
-S: Supported
-F: drivers/net/pcs/pcs-altera-tse.c
-F: include/linux/pcs-altera-tse.h
-
ALTERA UART/JTAG UART SERIAL DRIVERS
M: Tobias Klauser <tklauser@distanz.ch>
L: linux-serial@vger.kernel.org
@@ -1634,6 +1560,7 @@
S: Maintained
C: irc://irc.libera.chat/armlinux
T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
+F: Documentation/process/maintainer-soc.rst
F: arch/arm/boot/dts/Makefile
F: arch/arm64/boot/dts/Makefile
@@ -1665,9 +1592,9 @@
F: Documentation/devicetree/bindings/i2c/arm,i2c-versatile.yaml
F: Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt
F: Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
-F: arch/arm/boot/dts/arm-realview-*
-F: arch/arm/boot/dts/integrator*
-F: arch/arm/boot/dts/versatile*
+F: arch/arm/boot/dts/arm/arm-realview-*
+F: arch/arm/boot/dts/arm/integrator*
+F: arch/arm/boot/dts/arm/versatile*
F: arch/arm/mach-versatile/
F: drivers/bus/arm-integrator-lm.c
F: drivers/clk/versatile/
@@ -1838,7 +1765,7 @@
F: Documentation/devicetree/bindings/pinctrl/actions,*
F: Documentation/devicetree/bindings/power/actions,owl-sps.txt
F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt
-F: arch/arm/boot/dts/owl-*
+F: arch/arm/boot/dts/actions/
F: arch/arm/mach-actions/
F: arch/arm64/boot/dts/actions/
F: drivers/clk/actions/
@@ -1884,6 +1811,7 @@
S: Maintained
F: Documentation/devicetree/bindings/clock/amlogic*
F: drivers/clk/meson/
+F: include/dt-bindings/clock/amlogic,a1*
F: include/dt-bindings/clock/gxbb*
F: include/dt-bindings/clock/meson*
@@ -1911,10 +1839,12 @@
L: linux-amlogic@lists.infradead.org
S: Maintained
W: http://linux-meson.com/
-F: arch/arm/boot/dts/meson*
+F: Documentation/devicetree/bindings/phy/amlogic*
+F: arch/arm/boot/dts/amlogic/
F: arch/arm/mach-meson/
F: arch/arm64/boot/dts/amlogic/
F: drivers/mmc/host/meson*
+F: drivers/phy/amlogic/
F: drivers/pinctrl/meson/
F: drivers/rtc/rtc-meson*
F: drivers/soc/amlogic/
@@ -1925,7 +1855,7 @@
M: Antoine Tenart <atenart@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/boot/dts/alpine*
+F: arch/arm/boot/dts/amazon/
F: arch/arm/mach-alpine/
F: arch/arm64/boot/dts/amazon/
F: drivers/*/*alpine*
@@ -1935,9 +1865,11 @@
L: asahi@lists.linux.dev
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
+F: Documentation/devicetree/bindings/sound/adi,ssm3515.yaml
F: Documentation/devicetree/bindings/sound/apple,*
F: sound/soc/apple/*
F: sound/soc/codecs/cs42l83-i2c.c
+F: sound/soc/codecs/ssm3515.c
ARM/APPLE MACHINE SUPPORT
M: Hector Martin <marcan@marcan.st>
@@ -1996,7 +1928,7 @@
L: linux-arm-kernel@axis.com
S: Maintained
F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
-F: arch/arm/boot/dts/artpec6*
+F: arch/arm/boot/dts/axis/
F: arch/arm/mach-artpec
F: drivers/clk/axis
F: drivers/crypto/axis
@@ -2024,7 +1956,7 @@
Q: https://patchwork.ozlabs.org/project/linux-aspeed/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
F: Documentation/devicetree/bindings/arm/aspeed/
-F: arch/arm/boot/dts/aspeed-*
+F: arch/arm/boot/dts/aspeed/
F: arch/arm/mach-aspeed/
N: aspeed
@@ -2043,8 +1975,7 @@
M: Andre Przywara <andre.przywara@arm.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/boot/dts/ecx-*.dts*
-F: arch/arm/boot/dts/highbank.dts
+F: arch/arm/boot/dts/calxeda/
F: arch/arm/mach-highbank/
ARM/CAVIUM THUNDER NETWORK DRIVER
@@ -2092,12 +2023,13 @@
M: Baruch Siach <baruch@tkos.co.il>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/boot/dts/cx92755*
+F: arch/arm/boot/dts/cnxt/
N: digicolor
ARM/CORESIGHT FRAMEWORK AND DRIVERS
M: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Mike Leach <mike.leach@linaro.org>
+R: James Clark <james.clark@arm.com>
R: Leo Yan <leo.yan@linaro.org>
L: coresight@lists.linaro.org (moderated for non-subscribers)
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -2131,7 +2063,7 @@
F: Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml
F: Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt
F: Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml
-F: arch/arm/boot/dts/gemini*
+F: arch/arm/boot/dts/gemini/
F: arch/arm/mach-gemini/
F: drivers/crypto/gemini/
F: drivers/net/ethernet/cortina/
@@ -2184,7 +2116,8 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
-F: arch/arm64/boot/dts/freescale/
+F: arch/arm/boot/dts/nxp/imx/
+F: arch/arm/boot/dts/nxp/mxs/
X: arch/arm64/boot/dts/freescale/fsl-*
X: arch/arm64/boot/dts/freescale/qoriq-*
X: drivers/media/i2c/
@@ -2197,7 +2130,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
-F: arch/arm/boot/dts/ls1021a*
+F: arch/arm/boot/dts/nxp/ls/
F: arch/arm64/boot/dts/freescale/fsl-*
F: arch/arm64/boot/dts/freescale/qoriq-*
@@ -2209,7 +2142,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
-F: arch/arm/boot/dts/vf*
+F: arch/arm/boot/dts/nxp/vf/
F: arch/arm/mach-imx/*vf610*
ARM/GUMSTIX MACHINE SUPPORT
@@ -2223,9 +2156,7 @@
S: Supported
W: http://www.hisilicon.com
T: git https://github.com/hisilicon/linux-hisi.git
-F: arch/arm/boot/dts/hi3*
-F: arch/arm/boot/dts/hip*
-F: arch/arm/boot/dts/hisi*
+F: arch/arm/boot/dts/hisilicon/
F: arch/arm/mach-hisi/
F: arch/arm64/boot/dts/hisilicon/
@@ -2247,8 +2178,7 @@
F: Documentation/devicetree/bindings/spi/hpe,gxp-spifi.yaml
F: Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
F: Documentation/hwmon/gxp-fan-ctrl.rst
-F: arch/arm/boot/dts/hpe-bmc*
-F: arch/arm/boot/dts/hpe-gxp*
+F: arch/arm/boot/dts/hpe/
F: arch/arm/mach-hpe/
F: drivers/clocksource/timer-gxp.c
F: drivers/hwmon/gxp-fan-ctrl.c
@@ -2262,7 +2192,7 @@
L: linux-omap@vger.kernel.org
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/boot/dts/omap3-igep*
+F: arch/arm/boot/dts/ti/omap/omap3-igep*
ARM/INTEL IXP4XX ARM ARCHITECTURE
M: Linus Walleij <linusw@kernel.org>
@@ -2275,7 +2205,7 @@
F: Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml
F: Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion*
F: Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml
-F: arch/arm/boot/dts/intel-ixp*
+F: arch/arm/boot/dts/intel/ixp/
F: arch/arm/mach-ixp4xx/
F: drivers/bus/intel-ixp4xx-eb.c
F: drivers/clocksource/timer-ixp4xx.c
@@ -2307,7 +2237,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt
-F: arch/arm/boot/dts/lpc43*
+F: arch/arm/boot/dts/nxp/lpc/lpc43*
F: drivers/i2c/busses/i2c-lpc2k.c
F: drivers/memory/pl172.c
F: drivers/mtd/spi-nor/controllers/nxp-spifi.c
@@ -2320,7 +2250,7 @@
S: Maintained
T: git git://github.com/vzapolskiy/linux-lpc32xx.git
F: Documentation/devicetree/bindings/i2c/i2c-pnx.txt
-F: arch/arm/boot/dts/lpc32*
+F: arch/arm/boot/dts/nxp/lpc/lpc32*
F: arch/arm/mach-lpc32xx/
F: drivers/i2c/busses/i2c-pnx.c
F: drivers/net/ethernet/nxp/lpc_eth.c
@@ -2338,8 +2268,8 @@
F: Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
F: Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
F: Documentation/devicetree/bindings/soc/dove/
-F: arch/arm/boot/dts/dove*
-F: arch/arm/boot/dts/orion5x*
+F: arch/arm/boot/dts/marvell/dove*
+F: arch/arm/boot/dts/marvell/orion5x*
F: arch/arm/mach-dove/
F: arch/arm/mach-mv78xx0/
F: arch/arm/mach-orion5x/
@@ -2354,12 +2284,13 @@
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git
F: Documentation/devicetree/bindings/arm/marvell/
-F: arch/arm/boot/dts/armada*
-F: arch/arm/boot/dts/kirkwood*
+F: arch/arm/boot/dts/marvell/armada*
+F: arch/arm/boot/dts/marvell/kirkwood*
F: arch/arm/configs/mvebu_*_defconfig
F: arch/arm/mach-mvebu/
F: arch/arm64/boot/dts/marvell/armada*
F: arch/arm64/boot/dts/marvell/cn913*
+F: drivers/clk/mvebu/
F: drivers/cpufreq/armada-37xx-cpufreq.c
F: drivers/cpufreq/armada-8k-cpufreq.c
F: drivers/cpufreq/mvebu-cpufreq.c
@@ -2389,10 +2320,7 @@
S: Maintained
W: https://mtk.wiki.kernel.org/
C: irc://irc.libera.chat/linux-mediatek
-F: arch/arm/boot/dts/mt2*
-F: arch/arm/boot/dts/mt6*
-F: arch/arm/boot/dts/mt7*
-F: arch/arm/boot/dts/mt8*
+F: arch/arm/boot/dts/mediatek/
F: arch/arm/mach-mediatek/
F: arch/arm64/boot/dts/mediatek/
F: drivers/soc/mediatek/
@@ -2408,18 +2336,25 @@
F: Documentation/devicetree/bindings/phy/mediatek,*
F: drivers/phy/mediatek/
+ARM/MICROCHIP (ARM64) SoC support
+M: Conor Dooley <conor@kernel.org>
+M: Nicolas Ferre <nicolas.ferre@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Supported
+T: git https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git
+F: arch/arm64/boot/dts/microchip/
+
ARM/Microchip (AT91) SoC support
M: Nicolas Ferre <nicolas.ferre@microchip.com>
M: Alexandre Belloni <alexandre.belloni@bootlin.com>
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
W: http://www.linux4sam.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git
-F: arch/arm/boot/dts/at91*.dts
-F: arch/arm/boot/dts/at91*.dtsi
-F: arch/arm/boot/dts/sama*.dts
-F: arch/arm/boot/dts/sama*.dtsi
+F: arch/arm/boot/dts/microchip/at91*
+F: arch/arm/boot/dts/microchip/sama*
F: arch/arm/include/debug/at91.S
F: arch/arm/mach-at91/
F: drivers/memory/atmel*
@@ -2430,15 +2365,6 @@
N: at91
N: atmel
-ARM/MICROCHIP (ARM64) SoC support
-M: Conor Dooley <conor@kernel.org>
-M: Nicolas Ferre <nicolas.ferre@microchip.com>
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Supported
-T: git https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git
-F: arch/arm64/boot/dts/microchip/
-
ARM/Microchip Sparx5 SoC support
M: Lars Povlsen <lars.povlsen@microchip.com>
M: Steen Hegelund <Steen.Hegelund@microchip.com>
@@ -2456,7 +2382,7 @@
M: Takao Orito <orito.takao@socionext.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/boot/dts/milbeaut*
+F: arch/arm/boot/dts/socionext/milbeaut*
F: arch/arm/mach-milbeaut/
N: milbeaut
@@ -2470,7 +2396,7 @@
F: Documentation/devicetree/bindings/arm/mstar/*
F: Documentation/devicetree/bindings/clock/mstar,msc313-mpll.yaml
F: Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
-F: arch/arm/boot/dts/mstar-*
+F: arch/arm/boot/dts/sigmastar/
F: arch/arm/mach-mstar/
F: drivers/clk/mstar/
F: drivers/clocksource/timer-msc313e.c
@@ -2489,7 +2415,7 @@
F: Documentation/devicetree/bindings/arm/ux500.yaml
F: Documentation/devicetree/bindings/arm/ux500/
F: Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml
-F: arch/arm/boot/dts/ste-*
+F: arch/arm/boot/dts/st/ste-*
F: arch/arm/mach-nomadik/
F: arch/arm/mach-ux500/
F: drivers/clk/clk-nomadik.c
@@ -2506,6 +2432,18 @@
F: drivers/rtc/rtc-pl031.c
F: drivers/soc/ux500/
+ARM/NUVOTON MA35 ARCHITECTURE
+M: Jacky Huang <ychuang3@nuvoton.com>
+M: Shan-Chun Hung <schung@nuvoton.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Supported
+F: Documentation/devicetree/bindings/*/*/*ma35*
+F: Documentation/devicetree/bindings/*/*ma35*
+F: arch/arm64/boot/dts/nuvoton/*ma35*
+F: drivers/*/*/*ma35*
+F: drivers/*/*ma35*
+K: ma35d1
+
ARM/NUVOTON NPCM ARCHITECTURE
M: Avi Fishman <avifishman70@gmail.com>
M: Tomer Maimon <tmaimon77@gmail.com>
@@ -2517,9 +2455,8 @@
S: Supported
F: Documentation/devicetree/bindings/*/*/*npcm*
F: Documentation/devicetree/bindings/*/*npcm*
-F: Documentation/devicetree/bindings/arm/npcm/*
F: Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
-F: arch/arm/boot/dts/nuvoton-npcm*
+F: arch/arm/boot/dts/nuvoton/nuvoton-npcm*
F: arch/arm/mach-npcm/
F: arch/arm64/boot/dts/nuvoton/
F: drivers/*/*/*npcm*
@@ -2534,7 +2471,7 @@
S: Maintained
W: https://github.com/neuschaefer/wpcm450/wiki
F: Documentation/devicetree/bindings/*/*wpcm*
-F: arch/arm/boot/dts/nuvoton-wpcm450*
+F: arch/arm/boot/dts/nuvoton/nuvoton-wpcm450*
F: arch/arm/configs/wpcm450_defconfig
F: arch/arm/mach-npcm/wpcm450.c
F: drivers/*/*/*wpcm*
@@ -2575,20 +2512,19 @@
ARM/QUALCOMM SUPPORT
M: Andy Gross <agross@kernel.org>
M: Bjorn Andersson <andersson@kernel.org>
-R: Konrad Dybcio <konrad.dybcio@linaro.org>
+M: Konrad Dybcio <konrad.dybcio@linaro.org>
L: linux-arm-msm@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git
F: Documentation/devicetree/bindings/*/qcom*
F: Documentation/devicetree/bindings/soc/qcom/
-F: arch/arm/boot/dts/qcom-*.dts
-F: arch/arm/boot/dts/qcom-*.dtsi
+F: arch/arm/boot/dts/qcom/
F: arch/arm/configs/qcom_defconfig
F: arch/arm/mach-qcom/
F: arch/arm64/boot/dts/qcom/
+F: drivers/*/*/pm8???-*
F: drivers/*/*/qcom*
F: drivers/*/*/qcom/
-F: drivers/*/pm8???-*
F: drivers/*/qcom*
F: drivers/*/qcom/
F: drivers/bluetooth/btqcomsmd.c
@@ -2625,7 +2561,7 @@
F: Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.yaml
F: Documentation/devicetree/bindings/serial/rda,8810pl-uart.yaml
F: Documentation/devicetree/bindings/timer/rda,8810pl-timer.yaml
-F: arch/arm/boot/dts/rda8810pl-*
+F: arch/arm/boot/dts/unisoc/
F: drivers/clocksource/timer-rda.c
F: drivers/gpio/gpio-rda.c
F: drivers/irqchip/irq-rda-intc.c
@@ -2637,7 +2573,7 @@
L: linux-realtek-soc@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/arm/realtek.yaml
-F: arch/arm/boot/dts/rtd*
+F: arch/arm/boot/dts/realtek/
F: arch/arm/mach-realtek/
F: arch/arm64/boot/dts/realtek/
@@ -2651,13 +2587,7 @@
T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git next
F: Documentation/devicetree/bindings/hwinfo/renesas,prr.yaml
F: Documentation/devicetree/bindings/soc/renesas/
-F: arch/arm/boot/dts/emev2*
-F: arch/arm/boot/dts/gr-peach*
-F: arch/arm/boot/dts/iwg20d-q7*
-F: arch/arm/boot/dts/r7s*
-F: arch/arm/boot/dts/r8a*
-F: arch/arm/boot/dts/r9a*
-F: arch/arm/boot/dts/sh*
+F: arch/arm/boot/dts/renesas/
F: arch/arm/configs/shmobile_defconfig
F: arch/arm/include/debug/renesas-scif.S
F: arch/arm/mach-shmobile/
@@ -2690,8 +2620,7 @@
F: Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
F: Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
F: Documentation/devicetree/bindings/spi/spi-rockchip.yaml
-F: arch/arm/boot/dts/rk3*
-F: arch/arm/boot/dts/rv11*
+F: arch/arm/boot/dts/rockchip/
F: arch/arm/mach-rockchip/
F: drivers/*/*/*rockchip*
F: drivers/*/*rockchip*
@@ -2710,14 +2639,12 @@
B: mailto:linux-samsung-soc@vger.kernel.org
C: irc://irc.libera.chat/linux-exynos
T: git git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
-F: Documentation/arm/samsung/
+F: Documentation/arch/arm/samsung/
F: Documentation/devicetree/bindings/arm/samsung/
F: Documentation/devicetree/bindings/hwinfo/samsung,*
F: Documentation/devicetree/bindings/power/pd-samsung.yaml
F: Documentation/devicetree/bindings/soc/samsung/
-F: arch/arm/boot/dts/exynos*
-F: arch/arm/boot/dts/s3c*
-F: arch/arm/boot/dts/s5p*
+F: arch/arm/boot/dts/samsung/
F: arch/arm/mach-exynos*/
F: arch/arm/mach-s3c/
F: arch/arm/mach-s5p*/
@@ -2777,7 +2704,7 @@
S: Maintained
W: http://www.rocketboards.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git
-F: arch/arm/boot/dts/socfpga*
+F: arch/arm/boot/dts/intel/socfpga/
F: arch/arm/configs/socfpga_defconfig
F: arch/arm/mach-socfpga/
F: arch/arm64/boot/dts/altera/
@@ -2810,7 +2737,7 @@
W: http://www.stlinux.com
F: Documentation/devicetree/bindings/i2c/st,sti-i2c.yaml
F: Documentation/devicetree/bindings/spi/st,ssc-spi.yaml
-F: arch/arm/boot/dts/sti*
+F: arch/arm/boot/dts/st/sti*
F: arch/arm/mach-sti/
F: drivers/ata/ahci_st.c
F: drivers/char/hw_random/st-rng.c
@@ -2843,8 +2770,9 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
-F: arch/arm/boot/dts/stm32*
+F: arch/arm/boot/dts/st/stm32*
F: arch/arm/mach-stm32/
+F: arch/arm64/boot/dts/st/
F: drivers/clocksource/armv7m_systick.c
N: stm32
N: stm
@@ -2858,7 +2786,7 @@
F: Documentation/devicetree/bindings/clock/sunplus,sp7021-clkc.yaml
F: Documentation/devicetree/bindings/interrupt-controller/sunplus,sp7021-intc.yaml
F: Documentation/devicetree/bindings/reset/sunplus,reset.yaml
-F: arch/arm/boot/dts/sunplus-sp7021*.dts*
+F: arch/arm/boot/dts/sunplus/
F: arch/arm/configs/sp7021_*defconfig
F: arch/arm/mach-sunplus/
F: drivers/clk/clk-sp7021.c
@@ -2872,7 +2800,7 @@
M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/boot/dts/berlin*
+F: arch/arm/boot/dts/synaptics/
F: arch/arm/mach-berlin/
F: arch/arm64/boot/dts/synaptics/
@@ -2914,7 +2842,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
-F: arch/arm/boot/dts/keystone-*
+F: arch/arm/boot/dts/ti/keystone/
F: arch/arm/mach-keystone/
ARM/TEXAS INSTRUMENT KEYSTONE CLOCK FRAMEWORK
@@ -2946,7 +2874,6 @@
F: Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
F: arch/arm64/boot/dts/ti/Makefile
F: arch/arm64/boot/dts/ti/k3-*
-F: include/dt-bindings/pinctrl/k3.h
ARM/TOSHIBA VISCONTI ARCHITECTURE
M: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
@@ -2979,7 +2906,7 @@
F: Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml
F: Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
F: Documentation/devicetree/bindings/soc/socionext/socionext,uniphier*.yaml
-F: arch/arm/boot/dts/uniphier*
+F: arch/arm/boot/dts/socionext/uniphier*
F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
F: arch/arm/mm/cache-uniphier.c
@@ -3004,7 +2931,7 @@
S: Maintained
F: */*/*/vexpress*
F: */*/vexpress*
-F: arch/arm/boot/dts/vexpress*
+F: arch/arm/boot/dts/arm/vexpress*
F: arch/arm/mach-versatile/
F: arch/arm64/boot/dts/arm/
F: drivers/clk/versatile/clk-vexpress-osc.c
@@ -3062,7 +2989,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
-F: Documentation/arm64/
+F: Documentation/arch/arm64/
F: arch/arm64/
F: tools/testing/selftests/arm64/
X: arch/arm64/boot/dts/
@@ -3323,7 +3250,7 @@
ATMEL MACB ETHERNET DRIVER
M: Nicolas Ferre <nicolas.ferre@microchip.com>
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
S: Supported
F: drivers/net/ethernet/cadence/
@@ -3335,9 +3262,8 @@
F: drivers/input/touchscreen/atmel_mxt_ts.c
ATMEL WIRELESS DRIVER
-M: Simon Kelley <simon@thekelleys.org.uk>
L: linux-wireless@vger.kernel.org
-S: Maintained
+S: Orphan
W: http://www.thekelleys.org.uk/atmel
W: http://atmelwlandriver.sourceforge.net/
F: drivers/net/wireless/atmel/atmel*
@@ -3384,6 +3310,16 @@
F: kernel/audit*
F: lib/*audit.c
+AUXILIARY BUS DRIVER
+M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+R: Dave Ertman <david.m.ertman@intel.com>
+R: Ira Weiny <ira.weiny@intel.com>
+S: Supported
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
+F: Documentation/driver-api/auxiliary_bus.rst
+F: drivers/base/auxiliary.c
+F: include/linux/auxiliary_bus.h
+
AUXILIARY DISPLAY DRIVERS
M: Miguel Ojeda <ojeda@kernel.org>
S: Maintained
@@ -3411,10 +3347,10 @@
M: Peter Rosin <peda@axentia.se>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/boot/dts/at91-linea.dtsi
-F: arch/arm/boot/dts/at91-natte.dtsi
-F: arch/arm/boot/dts/at91-nattis-2-natte-2.dts
-F: arch/arm/boot/dts/at91-tse850-3.dts
+F: arch/arm/boot/dts/microchip/at91-linea.dtsi
+F: arch/arm/boot/dts/microchip/at91-natte.dtsi
+F: arch/arm/boot/dts/microchip/at91-nattis-2-natte-2.dts
+F: arch/arm/boot/dts/microchip/at91-tse850-3.dts
AXENTIA ASOC DRIVERS
M: Peter Rosin <peda@axentia.se>
@@ -3457,7 +3393,7 @@
B43 WIRELESS DRIVER
L: linux-wireless@vger.kernel.org
L: b43-dev@lists.infradead.org
-S: Odd Fixes
+S: Orphan
W: https://wireless.wiki.kernel.org/en/users/Drivers/b43
F: drivers/net/wireless/broadcom/b43/
@@ -3564,18 +3500,24 @@
R: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
R: Rasmus Villemoes <linux@rasmusvillemoes.dk>
S: Maintained
+F: include/linux/bitfield.h
F: include/linux/bitmap.h
+F: include/linux/bits.h
F: include/linux/cpumask.h
F: include/linux/find.h
F: include/linux/nodemask.h
+F: include/vdso/bits.h
F: lib/bitmap.c
F: lib/cpumask.c
F: lib/cpumask_kunit.c
F: lib/find_bit.c
F: lib/find_bit_benchmark.c
F: lib/test_bitmap.c
+F: tools/include/linux/bitfield.h
F: tools/include/linux/bitmap.h
+F: tools/include/linux/bits.h
F: tools/include/linux/find.h
+F: tools/include/vdso/bits.h
F: tools/lib/bitmap.c
F: tools/lib/find_bit.c
@@ -3613,6 +3555,7 @@
W: http://www.bluez.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
+F: Documentation/devicetree/bindings/net/bluetooth/
F: drivers/bluetooth/
BLUETOOTH SUBSYSTEM
@@ -3900,7 +3843,7 @@
F: drivers/net/ethernet/broadcom/b44.*
BROADCOM B53/SF2 ETHERNET SWITCH DRIVER
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
L: netdev@vger.kernel.org
L: openwrt-devel@lists.openwrt.org (subscribers-only)
S: Supported
@@ -3911,7 +3854,7 @@
F: include/linux/platform_data/b53.h
BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-rpi-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -3925,7 +3868,7 @@
N: raspberrypi
BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
M: Ray Jui <rjui@broadcom.com>
M: Scott Branden <sbranden@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
@@ -3964,25 +3907,26 @@
F: drivers/pinctrl/bcm/pinctrl-bcm4908.c
BROADCOM BCM5301X ARM ARCHITECTURE
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
M: Hauke Mehrtens <hauke@hauke-m.de>
M: Rafał Miłecki <zajec5@gmail.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/boot/dts/bcm470*
-F: arch/arm/boot/dts/bcm5301*
-F: arch/arm/boot/dts/bcm953012*
+F: arch/arm/boot/dts/broadcom/bcm-ns.dtsi
+F: arch/arm/boot/dts/broadcom/bcm470*
+F: arch/arm/boot/dts/broadcom/bcm5301*
+F: arch/arm/boot/dts/broadcom/bcm953012*
F: arch/arm/mach-bcm/bcm_5301x.c
BROADCOM BCM53573 ARM ARCHITECTURE
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
M: Rafał Miłecki <rafal@milecki.pl>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/boot/dts/bcm47189*
-F: arch/arm/boot/dts/bcm53573*
+F: arch/arm/boot/dts/broadcom/bcm47189*
+F: arch/arm/boot/dts/broadcom/bcm53573*
BROADCOM BCM63XX/BCM33XX UDC DRIVER
M: Kevin Cernekee <cernekee@gmail.com>
@@ -3991,13 +3935,13 @@
F: drivers/usb/gadget/udc/bcm63xx_udc.*
BROADCOM BCM7XXX ARM ARCHITECTURE
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git https://github.com/broadcom/stblinux.git
F: Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
-F: arch/arm/boot/dts/bcm7*.dts*
+F: arch/arm/boot/dts/broadcom/bcm7*.dts*
F: arch/arm/include/asm/hardware/cache-b15-rac.h
F: arch/arm/mach-bcm/*brcmstb*
F: arch/arm/mm/cache-b15-rac.c
@@ -4011,7 +3955,7 @@
M: William Zhang <william.zhang@broadcom.com>
M: Anand Gore <anand.gore@broadcom.com>
M: Kursad Oney <kursad.oney@broadcom.com>
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
M: Rafał Miłecki <rafal@milecki.pl>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -4036,7 +3980,7 @@
N: bcm[9]?6878
BROADCOM BDC DRIVER
-M: Justin Chen <justinpopo6@gmail.com>
+M: Justin Chen <justin.chen@broadcom.com>
M: Al Cooper <alcooperx@gmail.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-usb@vger.kernel.org
@@ -4052,7 +3996,7 @@
F: drivers/cpufreq/bmips-cpufreq.c
BROADCOM BMIPS MIPS ARCHITECTURE
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-mips@vger.kernel.org
S: Maintained
@@ -4120,14 +4064,14 @@
BROADCOM BRCMSTB GPIO DRIVER
M: Doug Berger <opendmb@gmail.com>
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
S: Supported
F: Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml
F: drivers/gpio/gpio-brcmstb.c
BROADCOM BRCMSTB I2C DRIVER
-M: Kamal Dasu <kdasu.kdev@gmail.com>
+M: Kamal Dasu <kamal.dasu@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-i2c@vger.kernel.org
S: Supported
@@ -4143,7 +4087,7 @@
F: drivers/tty/serial/8250/8250_bcm7271.c
BROADCOM BRCMSTB USB EHCI DRIVER
-M: Justin Chen <justinpopo6@gmail.com>
+M: Justin Chen <justin.chen@broadcom.com>
M: Al Cooper <alcooperx@gmail.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-usb@vger.kernel.org
@@ -4160,7 +4104,7 @@
F: drivers/usb/misc/brcmstb-usb-pinmap.c
BROADCOM BRCMSTB USB2 and USB3 PHY DRIVER
-M: Justin Chen <justinpopo6@gmail.com>
+M: Justin Chen <justin.chen@broadcom.com>
M: Al Cooper <alcooperx@gmail.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-kernel@vger.kernel.org
@@ -4178,8 +4122,15 @@
F: drivers/spi/spi-bcm63xx-hsspi.c
F: drivers/spi/spi-bcmbca-hsspi.c
+BROADCOM BCM6348/BCM6358 SPI controller DRIVER
+M: Jonas Gorski <jonas.gorski@gmail.com>
+L: linux-spi@vger.kernel.org
+S: Odd Fixes
+F: Documentation/devicetree/bindings/spi/spi-bcm63xx.txt
+F: drivers/spi/spi-bcm63xx.c
+
BROADCOM ETHERNET PHY DRIVERS
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
@@ -4190,7 +4141,7 @@
BROADCOM GENET ETHERNET DRIVER
M: Doug Berger <opendmb@gmail.com>
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
@@ -4274,7 +4225,7 @@
BROADCOM PMB (POWER MANAGEMENT BUS) DRIVER
M: Rafał Miłecki <rafal@milecki.pl>
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-pm@vger.kernel.org
S: Maintained
@@ -4290,7 +4241,7 @@
F: include/linux/bcma/
BROADCOM SPI DRIVER
-M: Kamal Dasu <kdasu.kdev@gmail.com>
+M: Kamal Dasu <kamal.dasu@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
S: Maintained
F: Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
@@ -4324,7 +4275,7 @@
BROADCOM STB NAND FLASH DRIVER
M: Brian Norris <computersforpeace@gmail.com>
-M: Kamal Dasu <kdasu.kdev@gmail.com>
+M: Kamal Dasu <kamal.dasu@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-mtd@lists.infradead.org
S: Maintained
@@ -4334,7 +4285,7 @@
BROADCOM STB PCIE DRIVER
M: Jim Quinlan <jim2101024@gmail.com>
M: Nicolas Saenz Julienne <nsaenz@kernel.org>
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-pci@vger.kernel.org
S: Maintained
@@ -4342,7 +4293,7 @@
F: drivers/pci/controller/pcie-brcmstb.c
BROADCOM SYSTEMPORT ETHERNET DRIVER
-M: Florian Fainelli <f.fainelli@gmail.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
@@ -4487,6 +4438,13 @@
F: Documentation/filesystems/caching/cachefiles.rst
F: fs/cachefiles/
+CACHESTAT: PAGE CACHE STATS FOR A FILE
+M: Nhat Pham <nphamcs@gmail.com>
+M: Johannes Weiner <hannes@cmpxchg.org>
+L: linux-mm@kvack.org
+S: Maintained
+F: tools/testing/selftests/cachestat/test_cachestat.c
+
CADENCE MIPI-CSI2 BRIDGES
M: Maxime Ripard <mripard@kernel.org>
L: linux-media@vger.kernel.org
@@ -4504,7 +4462,6 @@
M: Peter Chen <peter.chen@kernel.org>
M: Pawel Laszczak <pawell@cadence.com>
R: Roger Quadros <rogerq@kernel.org>
-R: Aswath Govindraju <a-govindraju@ti.com>
L: linux-usb@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
@@ -4512,6 +4469,12 @@
F: drivers/usb/cdns3/
X: drivers/usb/cdns3/cdnsp*
+CADENCE USBHS DRIVER
+M: Pawel Laszczak <pawell@cadence.com>
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/gadget/udc/cdns2
+
CADENCE USBSSP DRD IP DRIVER
M: Pawel Laszczak <pawell@cadence.com>
L: linux-usb@vger.kernel.org
@@ -5184,16 +5147,25 @@
F: include/linux/compiler_attributes.h
COMPUTE EXPRESS LINK (CXL)
+M: Davidlohr Bueso <dave@stgolabs.net>
+M: Jonathan Cameron <jonathan.cameron@huawei.com>
+M: Dave Jiang <dave.jiang@intel.com>
M: Alison Schofield <alison.schofield@intel.com>
M: Vishal Verma <vishal.l.verma@intel.com>
M: Ira Weiny <ira.weiny@intel.com>
-M: Ben Widawsky <bwidawsk@kernel.org>
M: Dan Williams <dan.j.williams@intel.com>
L: linux-cxl@vger.kernel.org
S: Maintained
F: drivers/cxl/
F: include/uapi/linux/cxl_mem.h
+COMPUTE EXPRESS LINK PMU (CPMU)
+M: Jonathan Cameron <jonathan.cameron@huawei.com>
+L: linux-cxl@vger.kernel.org
+S: Maintained
+F: Documentation/admin-guide/perf/cxl.rst
+F: drivers/perf/cxl_pmu.c
+
CONEXANT ACCESSRUNNER USB DRIVER
L: accessrunner-general@lists.sourceforge.net
S: Orphan
@@ -5344,6 +5316,18 @@
F: kernel/sched/cpufreq*.c
F: tools/testing/selftests/cpufreq/
+CPU HOTPLUG
+M: Thomas Gleixner <tglx@linutronix.de>
+M: Peter Zijlstra <peterz@infradead.org>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git smp/core
+F: include/linux/cpu.h
+F: include/linux/cpuhotplug.h
+F: include/linux/smpboot.h
+F: kernel/cpu.c
+F: kernel/smpboot.*
+
CPU IDLE TIME MANAGEMENT FRAMEWORK
M: "Rafael J. Wysocki" <rafael@kernel.org>
M: Daniel Lezcano <daniel.lezcano@linaro.org>
@@ -5477,8 +5461,7 @@
F: drivers/net/can/ctucanfd/
CW1200 WLAN driver
-M: Solomon Peachy <pizza@shaftnet.org>
-S: Maintained
+S: Orphan
F: drivers/net/wireless/st/cw1200/
CX18 VIDEO4LINUX DRIVER
@@ -5712,10 +5695,7 @@
M: Oliver Neukum <oliver@neukum.org>
M: Ali Akcaagac <aliakc@web.de>
M: Jamie Lenehan <lenehan@twibble.org>
-L: dc395x@twibble.org
S: Maintained
-W: http://twibble.org/dist/dc395x/
-W: http://lists.twibble.org/mailman/listinfo/dc395x/
F: Documentation/scsi/dc395x.rst
F: drivers/scsi/dc395x.*
@@ -5733,8 +5713,8 @@
L: linux-kernel@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/debugobjects
-F: lib/debugobjects.c
F: include/linux/debugobjects.h
+F: lib/debugobjects.c
DECSTATION PLATFORM SUPPORT
M: "Maciej W. Rozycki" <macro@orcam.me.uk>
@@ -5825,6 +5805,7 @@
S: Maintained
F: Documentation/ABI/testing/debugfs-dell-wmi-ddv
F: Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv
+F: Documentation/wmi/devices/dell-wmi-ddv.rst
F: drivers/platform/x86/dell/dell-wmi-ddv.c
DELL WMI DESCRIPTOR DRIVER
@@ -5889,7 +5870,9 @@
F: drivers/mtd/nand/raw/denali*
DESIGNWARE EDMA CORE IP DRIVER
-M: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+R: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+R: Serge Semin <fancer.lancer@gmail.com>
L: dmaengine@vger.kernel.org
S: Maintained
F: drivers/dma/dw-edma/
@@ -6006,15 +5989,15 @@
M: Christoph Niedermaier <cniedermaier@dh-electronics.com>
L: kernel@dh-electronics.com
S: Maintained
-F: arch/arm/boot/dts/imx6*-dhcom-*
-F: arch/arm/boot/dts/imx6*-dhcor-*
+F: arch/arm/boot/dts/nxp/imx/imx6*-dhcom-*
+F: arch/arm/boot/dts/nxp/imx/imx6*-dhcor-*
DH ELECTRONICS STM32MP1 DHCOM/DHCOR BOARD SUPPORT
M: Marek Vasut <marex@denx.de>
L: kernel@dh-electronics.com
S: Maintained
-F: arch/arm/boot/dts/stm32mp1*-dhcom-*
-F: arch/arm/boot/dts/stm32mp1*-dhcor-*
+F: arch/arm/boot/dts/st/stm32mp1*-dhcom-*
+F: arch/arm/boot/dts/st/stm32mp1*-dhcor-*
DIALOG SEMICONDUCTOR DRIVERS
M: Support Opensource <support.opensource@diasemi.com>
@@ -6227,6 +6210,12 @@
X: Documentation/spi/
X: Documentation/userspace-api/media/
+DOCUMENTATION PROCESS
+M: Jonathan Corbet <corbet@lwn.net>
+L: workflows@vger.kernel.org
+S: Maintained
+F: Documentation/process/
+
DOCUMENTATION REPORTING ISSUES
M: Thorsten Leemhuis <linux@leemhuis.info>
L: linux-doc@vger.kernel.org
@@ -6583,6 +6572,7 @@
M: Abhinav Kumar <quic_abhinavk@quicinc.com>
M: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
R: Sean Paul <sean@poorly.run>
+R: Marijn Suijten <marijn.suijten@somainline.org>
L: linux-arm-msm@vger.kernel.org
L: dri-devel@lists.freedesktop.org
L: freedreno@lists.freedesktop.org
@@ -6703,6 +6693,12 @@
F: Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml
F: drivers/gpu/drm/panel/panel-samsung-s6d27a1.c
+DRM DRIVER FOR SAMSUNG S6D7AA0 PANELS
+M: Artur Weber <aweber.kernel@gmail.com>
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
+F: drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
+
DRM DRIVER FOR SITRONIX ST7586 PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
@@ -6775,6 +6771,7 @@
DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS)
M: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
M: Melissa Wen <melissa.srw@gmail.com>
+M: Maíra Canal <mairacanal@riseup.net>
R: Haneen Mohammed <hamohammed.sa@gmail.com>
R: Daniel Vetter <daniel@ffwll.ch>
L: dri-devel@lists.freedesktop.org
@@ -6877,6 +6874,7 @@
T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/bridge/
F: drivers/gpu/drm/bridge/
+F: drivers/gpu/drm/drm_bridge.c
F: include/drm/drm_bridge.h
DRM DRIVERS FOR EXYNOS
@@ -6985,8 +6983,7 @@
F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
F: Documentation/devicetree/bindings/display/renesas,du.yaml
-F: drivers/gpu/drm/rcar-du/
-F: drivers/gpu/drm/shmobile/
+F: drivers/gpu/drm/renesas/
F: include/linux/platform_data/shmob_drm.h
DRM DRIVERS FOR ROCKCHIP
@@ -7082,7 +7079,6 @@
F: drivers/gpu/drm/xen/
DRM DRIVERS FOR XILINX
-M: Hyun Kwon <hyun.kwon@xilinx.com>
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
@@ -7482,6 +7478,14 @@
S: Maintained
F: drivers/edac/mpc85xx_edac.[ch]
+EDAC-NPCM
+M: Marvin Lin <kflin@nuvoton.com>
+M: Stanley Chu <yschu@nuvoton.com>
+L: linux-edac@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml
+F: drivers/edac/npcm_edac.c
+
EDAC-PASEMI
M: Egor Martovetsky <egor@pasemi.com>
L: linux-edac@vger.kernel.org
@@ -7978,6 +7982,12 @@
F: drivers/hwmon/f75375s.c
F: include/linux/f75375s.h
+FINTEK F81604 USB to 2xCANBUS DEVICE DRIVER
+M: Ji-Ze Hong (Peter Hong) <peter_hong@fintek.com.tw>
+L: linux-can@vger.kernel.org
+S: Maintained
+F: drivers/net/can/usb/f81604.c
+
FIREWIRE AUDIO DRIVERS and IEC 61883-1/6 PACKET STREAMING ENGINE
M: Clemens Ladisch <clemens@ladisch.de>
M: Takashi Sakamoto <o-takashi@sakamocchi.jp>
@@ -8073,6 +8083,7 @@
F: include/linux/fortify-string.h
F: lib/fortify_kunit.c
F: lib/memcpy_kunit.c
+F: lib/strcat_kunit.c
F: lib/strscpy_kunit.c
F: lib/test_fortify/*
F: scripts/test_fortify.sh
@@ -8669,8 +8680,14 @@
F: drivers/input/touchscreen/resistive-adc-touch.c
GENERIC STRING LIBRARY
+M: Kees Cook <keescook@chromium.org>
R: Andy Shevchenko <andy@kernel.org>
-S: Maintained
+L: linux-hardening@vger.kernel.org
+S: Supported
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/hardening
+F: include/linux/string.h
+F: include/linux/string_choices.h
+F: include/linux/string_helpers.h
F: lib/string.c
F: lib/string_helpers.c
F: lib/test-string_helpers.c
@@ -9158,6 +9175,12 @@
S: Maintained
F: drivers/hid/hid-logitech-*
+HID NVIDIA SHIELD DRIVER
+M: Rahul Rameshbabu <rrameshbabu@nvidia.com>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: drivers/hid/hid-nvidia-shield.c
+
HID PHOENIX RC FLIGHT CONTROLLER
M: Marcus Folkesson <marcus.folkesson@gmail.com>
L: linux-input@vger.kernel.org
@@ -9352,7 +9375,6 @@
F: include/linux/hisi_acc_qm.h
HISILICON ROCE DRIVER
-M: Haoyue Xu <xuhaoyue1@hisilicon.com>
M: Junxian Huang <huangjunxian6@hisilicon.com>
L: linux-rdma@vger.kernel.org
S: Maintained
@@ -9427,6 +9449,13 @@
F: mm/hmm*
F: tools/testing/selftests/mm/*hmm*
+HONEYWELL MPRLS0025PA PRESSURE SENSOR SERIES IIO DRIVER
+M: Andreas Klinger <ak@it-klinger.de>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml
+F: drivers/iio/pressure/mprls0025pa.c
+
HOST AP DRIVER
M: Jouni Malinen <j@w1.fi>
L: linux-wireless@vger.kernel.org
@@ -9439,6 +9468,13 @@
S: Orphan
F: drivers/platform/x86/hp/tc1100-wmi.c
+HP WMI HARDWARE MONITOR DRIVER
+M: James Seo <james@equiv.tech>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/hp-wmi-sensors.rst
+F: drivers/hwmon/hp-wmi-sensors.c
+
HPET: High Precision Event Timers driver
M: Clemens Ladisch <clemens@ladisch.de>
S: Maintained
@@ -9623,6 +9659,7 @@
HYPERBUS SUPPORT
M: Vignesh Raghavendra <vigneshr@ti.com>
+R: Tudor Ambarus <tudor.ambarus@linaro.org>
L: linux-mtd@lists.infradead.org
S: Supported
Q: http://patchwork.ozlabs.org/project/linux-mtd/list/
@@ -9972,8 +10009,9 @@
L: linux-wpan@vger.kernel.org
S: Maintained
W: https://linux-wpan.org/
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan.git
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git
+Q: https://patchwork.kernel.org/project/linux-wpan/list/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next.git
F: Documentation/networking/ieee802154.rst
F: drivers/net/ieee802154/
F: include/linux/ieee802154.h
@@ -10263,6 +10301,13 @@
S: Maintained
F: drivers/video/fbdev/i810/
+INTEL 8254 COUNTER DRIVER
+M: William Breathitt Gray <william.gray@linaro.org>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: drivers/counter/i8254.c
+F: include/linux/i8254.h
+
INTEL 8255 GPIO DRIVER
M: William Breathitt Gray <william.gray@linaro.org>
L: linux-gpio@vger.kernel.org
@@ -10345,9 +10390,8 @@
M: Tony Nguyen <anthony.l.nguyen@intel.com>
L: intel-wired-lan@lists.osuosl.org (moderated for non-subscribers)
S: Supported
-W: http://www.intel.com/support/feedback.htm
-W: http://e1000.sourceforge.net/
-Q: http://patchwork.ozlabs.org/project/intel-wired-lan/list/
+W: https://www.intel.com/content/www/us/en/support.html
+Q: https://patchwork.ozlabs.org/project/intel-wired-lan/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git
F: Documentation/networking/device_drivers/ethernet/intel/
@@ -10469,7 +10513,7 @@
S: Maintained
F: Documentation/admin-guide/media/ipu3.rst
F: Documentation/admin-guide/media/ipu3_rcb.svg
-F: Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst
+F: Documentation/userspace-api/media/v4l/metafmt-intel-ipu3.rst
F: drivers/staging/media/ipu3/
INTEL ISHTP ECLITE DRIVER
@@ -10813,7 +10857,6 @@
F: drivers/net/ethernet/sgi/ioc3-eth.c
IOMAP FILESYSTEM LIBRARY
-M: Christoph Hellwig <hch@infradead.org>
M: Darrick J. Wong <djwong@kernel.org>
L: linux-xfs@vger.kernel.org
L: linux-fsdevel@vger.kernel.org
@@ -11274,6 +11317,10 @@
KERNEL NFSD, SUNRPC, AND LOCKD SERVERS
M: Chuck Lever <chuck.lever@oracle.com>
M: Jeff Layton <jlayton@kernel.org>
+R: Neil Brown <neilb@suse.de>
+R: Olga Kornievskaia <kolga@netapp.com>
+R: Dai Ngo <Dai.Ngo@oracle.com>
+R: Tom Talpey <tom@talpey.com>
L: linux-nfs@vger.kernel.org
S: Supported
W: http://nfs.sourceforge.net/
@@ -11331,6 +11378,8 @@
L: kunit-dev@googlegroups.com
S: Maintained
W: https://google.github.io/kunit-docs/third_party/kernel/docs/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git kunit
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git kunit-fixes
F: Documentation/dev-tools/kunit/
F: include/kunit/
F: lib/kunit/
@@ -11379,7 +11428,6 @@
KERNEL VIRTUAL MACHINE FOR MIPS (KVM/mips)
M: Huacai Chen <chenhuacai@kernel.org>
-M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
L: linux-mips@vger.kernel.org
L: kvm@vger.kernel.org
S: Maintained
@@ -11389,7 +11437,13 @@
F: arch/mips/kvm/
KERNEL VIRTUAL MACHINE FOR POWERPC (KVM/powerpc)
+M: Michael Ellerman <mpe@ellerman.id.au>
+R: Nicholas Piggin <npiggin@gmail.com>
L: linuxppc-dev@lists.ozlabs.org
+L: kvm@vger.kernel.org
+S: Maintained (Book3S 64-bit HV)
+S: Odd fixes (Book3S 64-bit PR)
+S: Orphan (Book3E and 32-bit)
T: git git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm
F: arch/powerpc/include/asm/kvm*
F: arch/powerpc/include/uapi/asm/kvm*
@@ -11435,6 +11489,7 @@
M: Paolo Bonzini <pbonzini@redhat.com>
L: kvm@vger.kernel.org
S: Supported
+P: Documentation/process/maintainer-kvm-x86.rst
T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
F: arch/x86/include/asm/kvm*
F: arch/x86/include/asm/svm.h
@@ -11751,7 +11806,7 @@
R: David Lechner <david@lechnology.com>
S: Maintained
F: Documentation/devicetree/bindings/power/supply/lego,ev3-battery.yaml
-F: arch/arm/boot/dts/da850-lego-ev3.dts
+F: arch/arm/boot/dts/ti/davinci/da850-lego-ev3.dts
F: drivers/power/supply/lego_ev3_battery.c
LEGO USB Tower driver
@@ -11922,11 +11977,12 @@
F: lib/test_linear_ranges.c
LINUX FOR POWER MACINTOSH
-M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
L: linuxppc-dev@lists.ozlabs.org
-S: Odd Fixes
+S: Orphan
F: arch/powerpc/platforms/powermac/
F: drivers/macintosh/
+X: drivers/macintosh/adb-iop.c
+X: drivers/macintosh/via-macii.c
LINUX FOR POWERPC (32-BIT AND 64-BIT)
M: Michael Ellerman <mpe@ellerman.id.au>
@@ -12024,6 +12080,13 @@
F: Documentation/memory-barriers.txt
F: tools/memory-model/
+LINUX-NEXT TREE
+M: Stephen Rothwell <sfr@canb.auug.org.au>
+L: linux-next@vger.kernel.org
+S: Supported
+B: mailto:linux-next@vger.kernel.org and the appropriate development tree
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/
+
LIS3LV02D ACCELEROMETER DRIVER
M: Eric Piel <eric.piel@tremplin-utc.net>
S: Maintained
@@ -12416,6 +12479,7 @@
MAPLE TREE
M: Liam R. Howlett <Liam.Howlett@oracle.com>
+L: maple-tree@lists.infradead.org
L: linux-mm@kvack.org
S: Supported
F: Documentation/core-api/maple_tree.rst
@@ -12527,30 +12591,25 @@
F: drivers/net/ethernet/marvell/mvpp2/
MARVELL MWIFIEX WIRELESS DRIVER
-M: Amitkumar Karwar <amitkarwar@gmail.com>
-M: Ganapathi Bhat <ganapathi017@gmail.com>
-M: Sharvari Harisangam <sharvari.harisangam@nxp.com>
-M: Xinming Hu <huxinming820@gmail.com>
+M: Brian Norris <briannorris@chromium.org>
L: linux-wireless@vger.kernel.org
-S: Maintained
+S: Odd Fixes
F: drivers/net/wireless/marvell/mwifiex/
MARVELL MWL8K WIRELESS DRIVER
-M: Lennert Buytenhek <buytenh@wantstofly.org>
L: linux-wireless@vger.kernel.org
-S: Odd Fixes
+S: Orphan
F: drivers/net/wireless/marvell/mwl8k.c
MARVELL NAND CONTROLLER DRIVER
M: Miquel Raynal <miquel.raynal@bootlin.com>
L: linux-mtd@lists.infradead.org
S: Maintained
-F: Documentation/devicetree/bindings/mtd/marvell-nand.txt
F: drivers/mtd/nand/raw/marvell_nand.c
MARVELL OCTEON ENDPOINT DRIVER
M: Veerasenareddy Burru <vburru@marvell.com>
-M: Abhijit Ayarekar <aayarekar@marvell.com>
+M: Sathesh Edara <sedara@marvell.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/marvell/octeon_ep
@@ -12632,6 +12691,15 @@
F: drivers/media/i2c/max2175*
F: include/uapi/linux/max2175.h
+MAX31827 TEMPERATURE SWITCH DRIVER
+M: Daniel Matyas <daniel.matyas@analog.com>
+L: linux-hwmon@vger.kernel.org
+S: Supported
+W: http://ez.analog.com/community/linux-device-drivers
+F: Documentation/devicetree/bindings/hwmon/adi,max31827.yaml
+F: Documentation/hwmon/max31827.rst
+F: drivers/hwmon/max31827.c
+
MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER
L: linux-hwmon@vger.kernel.org
S: Orphan
@@ -12849,6 +12917,13 @@
F: drivers/net/ieee802154/mcr20a.c
F: drivers/net/ieee802154/mcr20a.h
+MDIO REGMAP DRIVER
+M: Maxime Chevallier <maxime.chevallier@bootlin.com>
+L: netdev@vger.kernel.org
+S: Maintained
+F: drivers/net/mdio/mdio-regmap.c
+F: include/linux/mdio/mdio-regmap.h
+
MEASUREMENT COMPUTING CIO-DAC IIO DRIVER
M: William Breathitt Gray <william.gray@linaro.org>
L: linux-iio@vger.kernel.org
@@ -13148,6 +13223,15 @@
F: drivers/net/pcs/pcs-mtk-lynxi.c
F: include/linux/pcs/pcs-mtk-lynxi.h
+MEDIATEK ETHERNET PHY DRIVERS
+M: Daniel Golle <daniel@makrotopia.org>
+M: Qingfang Deng <dqfext@gmail.com>
+M: SkyLake Huang <SkyLake.Huang@mediatek.com>
+L: netdev@vger.kernel.org
+S: Maintained
+F: drivers/net/phy/mediatek-ge-soc.c
+F: drivers/net/phy/mediatek-ge.c
+
MEDIATEK I2C CONTROLLER DRIVER
M: Qii Wang <qii.wang@mediatek.com>
L: linux-i2c@vger.kernel.org
@@ -13209,6 +13293,7 @@
R: Sean Wang <sean.wang@mediatek.com>
L: linux-wireless@vger.kernel.org
S: Maintained
+T: git https://github.com/nbd168/wireless
F: Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
F: drivers/net/wireless/mediatek/mt76/
@@ -13243,6 +13328,12 @@
F: Documentation/devicetree/bindings/i2c/mediatek,mt7621-i2c.yaml
F: drivers/i2c/busses/i2c-mt7621.c
+MEDIATEK MTMIPS CLOCK DRIVER
+M: Sergio Paracuellos <sergio.paracuellos@gmail.com>
+S: Maintained
+F: Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml
+F: drivers/clk/ralink/clk-mtmips.c
+
MEDIATEK NAND CONTROLLER DRIVER
L: linux-mtd@lists.infradead.org
S: Orphan
@@ -13269,10 +13360,11 @@
F: include/soc/mediatek/smi.h
MEDIATEK SWITCH DRIVER
-M: Sean Wang <sean.wang@mediatek.com>
+M: Arınç ÜNAL <arinc.unal@arinc9.com>
+M: Daniel Golle <daniel@makrotopia.org>
M: Landen Chao <Landen.Chao@mediatek.com>
M: DENG Qingfang <dqfext@gmail.com>
-M: Daniel Golle <daniel@makrotopia.org>
+M: Sean Wang <sean.wang@mediatek.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/dsa/mt7530-mdio.c
@@ -13637,6 +13729,7 @@
F: Documentation/ABI/stable/sysfs-bus-mhi
F: Documentation/mhi/
F: drivers/bus/mhi/
+F: drivers/pci/endpoint/functions/pci-epf-mhi.c
F: include/linux/mhi.h
MICROBLAZE ARCHITECTURE
@@ -13693,7 +13786,7 @@
F: drivers/spi/spi-at91-usart.c
MICROCHIP AUDIO ASOC DRIVERS
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/sound/atmel*
@@ -13716,9 +13809,10 @@
F: drivers/crypto/atmel-ecc.*
MICROCHIP EIC DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
+F: Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml
F: drivers/irqchip/irq-mchp-eic.c
MICROCHIP I2C DRIVER
@@ -13788,7 +13882,7 @@
F: include/video/atmel_lcdc.h
MICROCHIP MCP16502 PMIC DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
@@ -13815,7 +13909,7 @@
F: drivers/mtd/nand/raw/atmel/*
MICROCHIP OTPC DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
@@ -13854,7 +13948,7 @@
F: drivers/fpga/microchip-spi.c
MICROCHIP PWM DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-pwm@vger.kernel.org
S: Supported
@@ -13870,8 +13964,9 @@
F: include/dt-bindings/iio/adc/at91-sama5d2_adc.h
MICROCHIP SAMA5D2-COMPATIBLE SHUTDOWN CONTROLLER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
S: Supported
+F: Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml
F: drivers/power/reset/at91-sama5d2_shdwc.c
MICROCHIP SOC DRIVERS
@@ -13881,12 +13976,12 @@
F: drivers/soc/microchip/
MICROCHIP SPI DRIVER
-M: Tudor Ambarus <tudor.ambarus@linaro.org>
+M: Ryan Wanner <ryan.wanner@microchip.com>
S: Supported
F: drivers/spi/spi-atmel.*
MICROCHIP SSC DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -13915,7 +14010,7 @@
MICROCHIP WILC1000 WIFI DRIVER
M: Ajay Singh <ajay.kathat@microchip.com>
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-wireless@vger.kernel.org
S: Supported
F: drivers/net/wireless/microchip/wilc1000/
@@ -14045,12 +14140,12 @@
M: Luka Kovacic <luka.kovacic@sartura.hr>
M: Luka Perkov <luka.perkov@sartura.hr>
S: Maintained
-F: arch/arm/boot/dts/armada-xp-crs305-1g-4s-bit.dts
-F: arch/arm/boot/dts/armada-xp-crs305-1g-4s.dts
-F: arch/arm/boot/dts/armada-xp-crs326-24g-2s-bit.dts
-F: arch/arm/boot/dts/armada-xp-crs326-24g-2s.dts
-F: arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s-bit.dts
-F: arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dts
+F: arch/arm/boot/dts/marvell/armada-xp-crs305-1g-4s-bit.dts
+F: arch/arm/boot/dts/marvell/armada-xp-crs305-1g-4s.dts
+F: arch/arm/boot/dts/marvell/armada-xp-crs326-24g-2s-bit.dts
+F: arch/arm/boot/dts/marvell/armada-xp-crs326-24g-2s.dts
+F: arch/arm/boot/dts/marvell/armada-xp-crs328-4c-20s-4s-bit.dts
+F: arch/arm/boot/dts/marvell/armada-xp-crs328-4c-20s-4s.dts
MIPI CCS, SMIA AND SMIA++ IMAGE SENSOR DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
@@ -14153,7 +14248,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Odd Fixes
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp.git
-F: arch/arm/boot/dts/mmp*
+F: arch/arm/boot/dts/marvell/mmp*
F: arch/arm/mach-mmp/
F: include/linux/soc/mmp/
@@ -14581,7 +14676,6 @@
F: Documentation/devicetree/bindings/net/
F: drivers/connector/
F: drivers/net/
-X: drivers/net/wireless/
F: include/dt-bindings/net/
F: include/linux/etherdevice.h
F: include/linux/fcdevice.h
@@ -14592,6 +14686,7 @@
F: include/linux/netdevice.h
F: include/uapi/linux/if_*
F: include/uapi/linux/netdevice.h
+X: drivers/net/wireless/
NETWORKING DRIVERS (WIRELESS)
M: Kalle Valo <kvalo@kernel.org>
@@ -14646,9 +14741,9 @@
F: lib/net_utils.c
F: lib/random32.c
F: net/
-X: net/bluetooth/
F: tools/net/
F: tools/testing/selftests/net/
+X: net/bluetooth/
NETWORKING [IPSEC]
M: Steffen Klassert <steffen.klassert@secunet.com>
@@ -14693,7 +14788,7 @@
M: Paul Moore <paul@paul-moore.com>
L: netdev@vger.kernel.org
L: linux-security-module@vger.kernel.org
-S: Maintained
+S: Supported
W: https://github.com/netlabel
F: Documentation/netlabel/
F: include/net/calipso.h
@@ -14729,6 +14824,7 @@
M: Eric Dumazet <edumazet@google.com>
L: netdev@vger.kernel.org
S: Maintained
+F: include/linux/net_mm.h
F: include/linux/tcp.h
F: include/net/tcp.h
F: include/trace/events/tcp.h
@@ -14922,7 +15018,7 @@
L: ntb@lists.linux.dev
S: Supported
W: https://github.com/jonmason/ntb/wiki
-T: git git://github.com/jonmason/ntb.git
+T: git https://github.com/jonmason/ntb.git
F: drivers/net/ntb_netdev.c
F: drivers/ntb/
F: drivers/pci/endpoint/functions/pci-epf-*ntb.c
@@ -15285,19 +15381,13 @@
L: linux-omap@vger.kernel.org
L: devicetree@vger.kernel.org
S: Maintained
-F: arch/arm/boot/dts/*am3*
-F: arch/arm/boot/dts/*am4*
-F: arch/arm/boot/dts/*am5*
-F: arch/arm/boot/dts/*dra7*
-F: arch/arm/boot/dts/*omap*
-F: arch/arm/boot/dts/logicpd-som-lv*
-F: arch/arm/boot/dts/logicpd-torpedo*
+F: arch/arm/boot/dts/ti/omap/
OMAP DISPLAY SUBSYSTEM and FRAMEBUFFER SUPPORT (DSS2)
L: linux-omap@vger.kernel.org
L: linux-fbdev@vger.kernel.org
S: Orphan
-F: Documentation/arm/omap/dss.rst
+F: Documentation/arch/arm/omap/dss.rst
F: drivers/video/fbdev/omap2/
OMAP FRAMEBUFFER SUPPORT
@@ -15399,7 +15489,7 @@
M: Mark Jackson <mpfj@newflow.co.uk>
L: linux-omap@vger.kernel.org
S: Maintained
-F: arch/arm/boot/dts/am335x-nano.dts
+F: arch/arm/boot/dts/ti/omap/am335x-nano.dts
OMAP1 SUPPORT
M: Aaro Koskinen <aaro.koskinen@iki.fi>
@@ -15426,6 +15516,7 @@
F: arch/arm/configs/omap2plus_defconfig
F: arch/arm/mach-omap2/
F: drivers/bus/ti-sysc.c
+F: drivers/gpio/gpio-tps65219.c
F: drivers/i2c/busses/i2c-omap.c
F: drivers/irqchip/irq-omap-intc.c
F: drivers/mfd/*omap*.c
@@ -15463,6 +15554,13 @@
S: Maintained
F: drivers/media/i2c/og01a1b.c
+OMNIVISION OV01A10 SENSOR DRIVER
+M: Bingbu Cao <bingbu.cao@intel.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: drivers/media/i2c/ov01a10.c
+
OMNIVISION OV02A10 SENSOR DRIVER
M: Dongchun Zhu <dongchun.zhu@mediatek.com>
L: linux-media@vger.kernel.org
@@ -15811,7 +15909,7 @@
M: Mark Fasheh <mark@fasheh.com>
M: Joel Becker <jlbec@evilplan.org>
M: Joseph Qi <joseph.qi@linux.alibaba.com>
-L: ocfs2-devel@oss.oracle.com (moderated for non-subscribers)
+L: ocfs2-devel@lists.linux.dev
S: Supported
W: http://ocfs2.wiki.kernel.org
F: Documentation/filesystems/dlmfs.rst
@@ -15846,6 +15944,7 @@
OVERLAY FILESYSTEM
M: Miklos Szeredi <miklos@szeredi.hu>
+M: Amir Goldstein <amir73il@gmail.com>
L: linux-unionfs@vger.kernel.org
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
@@ -15948,7 +16047,7 @@
PARAVIRT_OPS INTERFACE
M: Juergen Gross <jgross@suse.com>
-M: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
+R: Ajay Kaher <akaher@vmware.com>
R: Alexey Makhalov <amakhalov@vmware.com>
R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
L: virtualization@lists.linux-foundation.org
@@ -16194,6 +16293,7 @@
PCI DRIVER FOR SYNOPSYS DESIGNWARE
M: Jingoo Han <jingoohan1@gmail.com>
M: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
L: linux-pci@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
@@ -16384,7 +16484,7 @@
F: drivers/pci/controller/dwc/pcie-keembay.c
PCIE DRIVER FOR INTEL LGM GW SOC
-M: Rahul Tanwar <rtanwar@maxlinear.com>
+M: Chuanhua Lei <lchuanhua@maxlinear.com>
L: linux-pci@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
@@ -16464,6 +16564,10 @@
F: crypto/pcrypt.c
F: include/crypto/pcrypt.h
+PDS DSC VIRTIO DATA PATH ACCELERATOR
+R: Shannon Nelson <shannon.nelson@amd.com>
+F: drivers/vdpa/pds/
+
PECI HARDWARE MONITORING DRIVERS
M: Iwona Winiarska <iwona.winiarska@intel.com>
L: linux-hwmon@vger.kernel.org
@@ -16691,7 +16795,7 @@
M: Bjorn Andersson <andersson@kernel.org>
L: linux-arm-msm@vger.kernel.org
S: Maintained
-F: Documentation/devicetree/bindings/pinctrl/qcom,*.txt
+F: Documentation/devicetree/bindings/pinctrl/qcom,*
F: drivers/pinctrl/qcom/
PIN CONTROLLER - RENESAS
@@ -17146,7 +17250,7 @@
S: Maintained
T: git git://github.com/hzhuang1/linux.git
T: git git://github.com/rjarzmik/linux.git
-F: arch/arm/boot/dts/pxa*
+F: arch/arm/boot/dts/intel/pxa/
F: arch/arm/mach-pxa/
F: drivers/dma/pxa*
F: drivers/pcmcia/pxa2xx*
@@ -17184,6 +17288,7 @@
F: sound/soc/codecs/wcd934x.c
F: sound/soc/codecs/wsa881x.c
F: sound/soc/codecs/wsa883x.c
+F: sound/soc/codecs/wsa884x.c
F: sound/soc/qcom/
QCOM EMBEDDED USB DEBUGGER (EUD)
@@ -17340,6 +17445,7 @@
QUALCOMM ATH12K WIRELESS DRIVER
M: Kalle Valo <kvalo@kernel.org>
+M: Jeff Johnson <quic_jjohnson@quicinc.com>
L: ath12k@lists.infradead.org
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
@@ -17347,6 +17453,7 @@
QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
M: Kalle Valo <kvalo@kernel.org>
+M: Jeff Johnson <quic_jjohnson@quicinc.com>
L: ath10k@lists.infradead.org
S: Supported
W: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
@@ -17356,8 +17463,11 @@
QUALCOMM ATHEROS ATH11K WIRELESS DRIVER
M: Kalle Valo <kvalo@kernel.org>
+M: Jeff Johnson <quic_jjohnson@quicinc.com>
L: ath11k@lists.infradead.org
S: Supported
+W: https://wireless.wiki.kernel.org/en/users/Drivers/ath11k
+B: https://wireless.wiki.kernel.org/en/users/Drivers/ath11k/bugreport
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
F: Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
F: drivers/net/wireless/ath/ath11k/
@@ -17367,6 +17477,7 @@
L: linux-wireless@vger.kernel.org
S: Maintained
W: https://wireless.wiki.kernel.org/en/users/Drivers/ath9k
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
F: Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml
F: drivers/net/wireless/ath/ath9k/
@@ -17399,6 +17510,8 @@
QUALCOMM CLOUD AI (QAIC) DRIVER
M: Jeffrey Hugo <quic_jhugo@quicinc.com>
+R: Carl Vanderlip <quic_carlv@quicinc.com>
+R: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com>
L: linux-arm-msm@vger.kernel.org
L: dri-devel@lists.freedesktop.org
S: Supported
@@ -17442,6 +17555,7 @@
M: Vinod Koul <vkoul@kernel.org>
R: Bhupesh Sharma <bhupesh.sharma@linaro.org>
L: netdev@vger.kernel.org
+L: linux-arm-msm@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/qcom,ethqos.yaml
F: drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -17551,9 +17665,18 @@
F: Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
F: drivers/thermal/qcom/
+QUALCOMM TYPEC PORT MANAGER DRIVER
+M: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+L: linux-arm-msm@vger.kernel.org
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/usb/qcom,pmic-*.yaml
+F: drivers/usb/typec/tcpm/qcom/
+
QUALCOMM VENUS VIDEO ACCELERATOR DRIVER
M: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
M: Vikash Garodia <quic_vgarodia@quicinc.com>
+R: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
L: linux-media@vger.kernel.org
L: linux-arm-msm@vger.kernel.org
S: Maintained
@@ -17796,7 +17919,7 @@
R: Steven Rostedt <rostedt@goodmis.org>
R: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
R: Lai Jiangshan <jiangshanlai@gmail.com>
-R: Zqiang <qiang1.zhang@intel.com>
+R: Zqiang <qiang.zhang1211@gmail.com>
L: rcu@vger.kernel.org
S: Supported
W: http://www.rdrop.com/users/paulmck/RCU/
@@ -17827,7 +17950,7 @@
Real-time Linux Analysis (RTLA) tools
M: Daniel Bristot de Oliveira <bristot@kernel.org>
M: Steven Rostedt <rostedt@goodmis.org>
-L: linux-trace-devel@vger.kernel.org
+L: linux-trace-kernel@vger.kernel.org
S: Maintained
F: Documentation/tools/rtla/
F: tools/tracing/rtla/
@@ -17861,7 +17984,7 @@
F: drivers/net/wireless/realtek/rtlwifi/
REALTEK WIRELESS DRIVER (rtw88)
-M: Yan-Hsuan Chuang <tony0620emma@gmail.com>
+M: Ping-Ke Shih <pkshih@realtek.com>
L: linux-wireless@vger.kernel.org
S: Maintained
F: drivers/net/wireless/realtek/rtw88/
@@ -18068,6 +18191,13 @@
F: Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml
F: drivers/clk/clk-versaclock7.c
+RENESAS X9250 DIGITAL POTENTIOMETERS DRIVER
+M: Herve Codina <herve.codina@bootlin.com>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml
+F: drivers/iio/potentiometer/x9250.c
+
RESET CONTROLLER FRAMEWORK
M: Philipp Zabel <p.zabel@pengutronix.de>
S: Maintained
@@ -18163,6 +18293,7 @@
F: drivers/i2c/busses/i2c-microchip-corei2c.c
F: drivers/mailbox/mailbox-mpfs.c
F: drivers/pci/controller/pcie-microchip-host.c
+F: drivers/pwm/pwm-microchip-core.c
F: drivers/reset/reset-mpfs.c
F: drivers/rtc/rtc-mpfs.c
F: drivers/soc/microchip/mpfs-sys-controller.c
@@ -18179,6 +18310,8 @@
T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
F: Documentation/devicetree/bindings/riscv/
F: arch/riscv/boot/dts/
+X: arch/riscv/boot/dts/allwinner/
+X: arch/riscv/boot/dts/renesas/
RISC-V PMU DRIVERS
M: Atish Patra <atishp@atishpatra.org>
@@ -18189,6 +18322,14 @@
F: drivers/perf/riscv_pmu_legacy.c
F: drivers/perf/riscv_pmu_sbi.c
+RISC-V THEAD SoC SUPPORT
+M: Jisheng Zhang <jszhang@kernel.org>
+M: Guo Ren <guoren@kernel.org>
+M: Fu Wei <wefu@redhat.com>
+L: linux-riscv@lists.infradead.org
+S: Maintained
+F: arch/riscv/boot/dts/thead/
+
RNBD BLOCK DRIVERS
M: Md. Haris Iqbal <haris.iqbal@ionos.com>
M: Jack Wang <jinpu.wang@ionos.com>
@@ -18225,7 +18366,7 @@
S: Maintained
F: Documentation/admin-guide/media/rkisp1.rst
F: Documentation/devicetree/bindings/media/rockchip-isp1.yaml
-F: Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
+F: Documentation/userspace-api/media/v4l/metafmt-rkisp1.rst
F: drivers/media/platform/rockchip/rkisp1
F: include/uapi/linux/rkisp1-config.h
@@ -18270,10 +18411,11 @@
F: Documentation/devicetree/bindings/iio/light/bh1750.yaml
F: drivers/iio/light/bh1750.c
-ROHM BU27034 AMBIENT LIGHT SENSOR DRIVER
+ROHM BU270xx LIGHT SENSOR DRIVERs
M: Matti Vaittinen <mazziesaccount@gmail.com>
L: linux-iio@vger.kernel.org
S: Supported
+F: drivers/iio/light/rohm-bu27008.c
F: drivers/iio/light/rohm-bu27034.c
ROHM MULTIFUNCTION BD9571MWV-M PMIC DEVICE DRIVERS
@@ -18367,17 +18509,14 @@
L: linux-wireless@vger.kernel.org
S: Orphan
W: https://wireless.wiki.kernel.org/
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
F: drivers/net/wireless/realtek/rtl818x/rtl8180/
RTL8187 WIRELESS DRIVER
-M: Herton Ronaldo Krzesinski <herton@canonical.com>
-M: Hin-Tak Leung <htl10@users.sourceforge.net>
+M: Hin-Tak Leung <hintak.leung@gmail.com>
M: Larry Finger <Larry.Finger@lwfinger.net>
L: linux-wireless@vger.kernel.org
S: Maintained
W: https://wireless.wiki.kernel.org/
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
F: drivers/net/wireless/realtek/rtl818x/rtl8187/
RTL8XXXU WIRELESS DRIVER (rtl8xxxu)
@@ -18397,7 +18536,7 @@
RUNTIME VERIFICATION (RV)
M: Daniel Bristot de Oliveira <bristot@kernel.org>
M: Steven Rostedt <rostedt@goodmis.org>
-L: linux-trace-devel@vger.kernel.org
+L: linux-trace-kernel@vger.kernel.org
S: Maintained
F: Documentation/trace/rv/
F: include/linux/rv.h
@@ -18772,7 +18911,7 @@
M: Paul Barker <paul.barker@sancloud.com>
R: Marc Murphy <marc.murphy@sancloud.com>
S: Supported
-F: arch/arm/boot/dts/am335x-sancloud*
+F: arch/arm/boot/dts/ti/omap/am335x-sancloud*
SC1200 WDT DRIVER
M: Zwane Mwaikambo <zwanem@gmail.com>
@@ -18799,6 +18938,16 @@
F: include/uapi/linux/sched.h
F: kernel/sched/
+SCSI LIBSAS SUBSYSTEM
+R: John Garry <john.g.garry@oracle.com>
+R: Jason Yan <yanaijie@huawei.com>
+L: linux-scsi@vger.kernel.org
+S: Supported
+F: Documentation/scsi/libsas.rst
+F: drivers/scsi/libsas/
+F: include/scsi/libsas.h
+F: include/scsi/sas_ata.h
+
SCSI RDMA PROTOCOL (SRP) INITIATOR
M: Bart Van Assche <bvanassche@acm.org>
L: linux-rdma@vger.kernel.org
@@ -18927,7 +19076,7 @@
K: \bTIF_SECCOMP\b
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) Broadcom BRCMSTB DRIVER
-M: Kamal Dasu <kdasu.kdev@gmail.com>
+M: Kamal Dasu <kamal.dasu@broadcom.com>
M: Al Cooper <alcooperx@gmail.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
L: linux-mmc@vger.kernel.org
@@ -19601,15 +19750,15 @@
SOLIDRUN CLEARFOG SUPPORT
M: Russell King <linux@armlinux.org.uk>
S: Maintained
-F: arch/arm/boot/dts/armada-388-clearfog*
-F: arch/arm/boot/dts/armada-38x-solidrun-*
+F: arch/arm/boot/dts/marvell/armada-388-clearfog*
+F: arch/arm/boot/dts/marvell/armada-38x-solidrun-*
SOLIDRUN CUBOX-I/HUMMINGBOARD SUPPORT
M: Russell King <linux@armlinux.org.uk>
S: Maintained
-F: arch/arm/boot/dts/imx6*-cubox-i*
-F: arch/arm/boot/dts/imx6*-hummingboard*
-F: arch/arm/boot/dts/imx6*-sr-*
+F: arch/arm/boot/dts/nxp/imx/imx6*-cubox-i*
+F: arch/arm/boot/dts/nxp/imx/imx6*-hummingboard*
+F: arch/arm/boot/dts/nxp/imx/imx6*-sr-*
SONIC NETWORK DRIVER
M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
@@ -19894,7 +20043,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
W: http://www.st.com/spear
-F: arch/arm/boot/dts/spear*
+F: arch/arm/boot/dts/st/spear*
F: arch/arm/mach-spear/
F: drivers/clk/spear/
F: drivers/pinctrl/spear/
@@ -20107,6 +20256,13 @@
S: Odd Fixes
F: drivers/net/ethernet/adaptec/starfire*
+STARFIVE CRYPTO DRIVER
+M: Jia Jie Ho <jiajie.ho@starfivetech.com>
+M: William Qiu <william.qiu@starfivetech.com>
+S: Supported
+F: Documentation/devicetree/bindings/crypto/starfive*
+F: drivers/crypto/starfive/
+
STARFIVE DEVICETREES
M: Emil Renner Berthing <kernel@esmil.dk>
S: Maintained
@@ -20125,6 +20281,12 @@
F: Documentation/devicetree/bindings/mmc/starfive*
F: drivers/mmc/host/dw_mmc-starfive.c
+STARFIVE JH7110 TDM DRIVER
+M: Walker Chen <walker.chen@starfivetech.com>
+S: Maintained
+F: Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml
+F: sound/soc/starfive/jh7110_tdm.c
+
STARFIVE JH71X0 CLOCK DRIVERS
M: Emil Renner Berthing <kernel@esmil.dk>
M: Hal Feng <hal.feng@starfivetech.com>
@@ -20151,6 +20313,12 @@
F: drivers/reset/starfive/reset-starfive-jh71*
F: include/dt-bindings/reset/starfive?jh71*.h
+STARFIVE JH71X0 USB DRIVERS
+M: Minda Chen <minda.chen@starfivetech.com>
+S: Maintained
+F: Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml
+F: drivers/usb/cdns3/cdns3-starfive.c
+
STARFIVE JH71XX PMU CONTROLLER DRIVER
M: Walker Chen <walker.chen@starfivetech.com>
S: Supported
@@ -20232,7 +20400,6 @@
F: include/linux/*/stm32-*tim*
STMMAC ETHERNET DRIVER
-M: Giuseppe Cavallaro <peppe.cavallaro@st.com>
M: Alexandre Torgue <alexandre.torgue@foss.st.com>
M: Jose Abreu <joabreu@synopsys.com>
L: netdev@vger.kernel.org
@@ -20844,10 +21011,13 @@
M: Thierry Reding <thierry.reding@gmail.com>
M: Jonathan Hunter <jonathanh@nvidia.com>
M: Sowjanya Komatineni <skomatineni@nvidia.com>
+M: Luca Ceresoli <luca.ceresoli@bootlin.com>
L: linux-media@vger.kernel.org
L: linux-tegra@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
+F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
+F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml
F: drivers/staging/media/tegra-video/
TEGRA XUSB PADCTL DRIVER
@@ -21102,7 +21272,7 @@
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
F: Documentation/devicetree/bindings/i2c/i2c-davinci.txt
-F: arch/arm/boot/dts/da850*
+F: arch/arm/boot/dts/ti/davinci/
F: arch/arm/mach-davinci/
F: drivers/i2c/busses/i2c-davinci.c
@@ -21467,11 +21637,17 @@
TTY LAYER
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Jiri Slaby <jirislaby@kernel.org>
+L: linux-kernel@vger.kernel.org
+L: linux-serial@vger.kernel.org
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
F: Documentation/driver-api/serial/
F: drivers/tty/
+F: drivers/tty/serial/serial_base.h
+F: drivers/tty/serial/serial_base_bus.c
F: drivers/tty/serial/serial_core.c
+F: drivers/tty/serial/serial_ctrl.c
+F: drivers/tty/serial/serial_port.c
F: include/linux/selection.h
F: include/linux/serial.h
F: include/linux/serial_core.h
@@ -21500,11 +21676,14 @@
F: drivers/net/ethernet/dec/tulip/
TUN/TAP driver
-M: Maxim Krasnyansky <maxk@qti.qualcomm.com>
+M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
+M: Jason Wang <jasowang@redhat.com>
S: Maintained
W: http://vtun.sourceforge.net/tun
F: Documentation/networking/tuntap.rst
F: arch/um/os-Linux/drivers/
+F: drivers/net/tap.c
+F: drivers/net/tun.c
TURBOCHANNEL SUBSYSTEM
M: "Maciej W. Rozycki" <macro@orcam.me.uk>
@@ -21727,9 +21906,8 @@
F: drivers/usb/misc/apple-mfi-fastcharge.c
USB AR5523 WIRELESS DRIVER
-M: Pontus Fuchs <pontus.fuchs@gmail.com>
L: linux-wireless@vger.kernel.org
-S: Maintained
+S: Orphan
F: drivers/net/wireless/ath/ar5523/
USB ATTACHED SCSI
@@ -21942,6 +22120,7 @@
F: include/dt-bindings/usb/
F: include/linux/usb.h
F: include/linux/usb/
+F: include/uapi/linux/usb/
USB TYPEC BUS FOR ALTERNATE MODES
M: Heikki Krogerus <heikki.krogerus@linux.intel.com>
@@ -22005,9 +22184,8 @@
F: include/uapi/linux/usb/g_uvc.h
USB WIRELESS RNDIS DRIVER (rndis_wlan)
-M: Jussi Kivilinna <jussi.kivilinna@iki.fi>
L: linux-wireless@vger.kernel.org
-S: Maintained
+S: Orphan
F: drivers/net/wireless/legacy/rndis_wlan.c
USB XHCI DRIVER
@@ -22116,6 +22294,13 @@
F: fs/fat/
F: tools/testing/selftests/filesystems/fat/
+VFIO CDX DRIVER
+M: Nipun Gupta <nipun.gupta@amd.com>
+M: Nikhil Agarwal <nikhil.agarwal@amd.com>
+L: kvm@vger.kernel.org
+S: Maintained
+F: drivers/vfio/cdx/*
+
VFIO DRIVER
M: Alex Williamson <alex.williamson@redhat.com>
L: kvm@vger.kernel.org
@@ -22197,7 +22382,6 @@
S: Maintained
F: drivers/video/fbdev/via/
F: include/linux/via-core.h
-F: include/linux/via-gpio.h
F: include/linux/via_i2c.h
VIA VELOCITY NETWORK DRIVER
@@ -22450,6 +22634,14 @@
S: Maintained
F: fs/vboxsf/*
+VIRTUAL PCM TEST DRIVER
+M: Ivan Orlov <ivan.orlov0322@gmail.com>
+L: alsa-devel@alsa-project.org
+S: Maintained
+F: Documentation/sound/cards/pcmtest.rst
+F: sound/drivers/pcmtest.c
+F: tools/testing/selftests/alsa/test-pcmtest-driver.c
+
VIRTUAL SERIO DEVICE DRIVER
M: Stephen Chandler Paul <thatslyude@gmail.com>
S: Maintained
@@ -22520,7 +22712,7 @@
F: drivers/misc/vmw_balloon.c
VMWARE HYPERVISOR INTERFACE
-M: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
+M: Ajay Kaher <akaher@vmware.com>
M: Alexey Makhalov <amakhalov@vmware.com>
R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
L: virtualization@lists.linux-foundation.org
@@ -22547,8 +22739,8 @@
F: drivers/scsi/vmw_pvscsi.h
VMWARE VIRTUAL PTP CLOCK DRIVER
-M: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
M: Deep Shah <sdeep@vmware.com>
+R: Ajay Kaher <akaher@vmware.com>
R: Alexey Makhalov <amakhalov@vmware.com>
R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
L: netdev@vger.kernel.org
@@ -22768,9 +22960,16 @@
WL3501 WIRELESS PCMCIA CARD DRIVER
L: linux-wireless@vger.kernel.org
-S: Odd fixes
+S: Orphan
F: drivers/net/wireless/legacy/wl3501*
+WMI BINARY MOF DRIVER
+L: platform-drivers-x86@vger.kernel.org
+S: Orphan
+F: Documentation/ABI/stable/sysfs-platform-wmi-bmof
+F: Documentation/wmi/devices/wmi-bmof.rst
+F: drivers/platform/x86/wmi-bmof.c
+
WOLFSON MICROELECTRONICS DRIVERS
L: patches@opensource.cirrus.com
S: Supported
@@ -23150,8 +23349,9 @@
F: drivers/iio/adc/xilinx-ams.c
XILINX AXI ETHERNET DRIVER
-M: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
+M: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
S: Maintained
+F: Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
F: drivers/net/ethernet/xilinx/xilinx_axienet*
XILINX CAN DRIVER
@@ -23169,8 +23369,8 @@
F: include/linux/firmware/xlnx-event-manager.h
XILINX GPIO DRIVER
-M: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
-R: Srinivas Neeli <srinivas.neeli@xilinx.com>
+M: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
+R: Srinivas Neeli <srinivas.neeli@amd.com>
R: Michal Simek <michal.simek@amd.com>
S: Maintained
F: Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
@@ -23185,8 +23385,8 @@
F: include/clocksource/timer-xilinx.h
XILINX SD-FEC IP CORES
-M: Derek Kiernan <derek.kiernan@xilinx.com>
-M: Dragan Cvetic <dragan.cvetic@xilinx.com>
+M: Derek Kiernan <derek.kiernan@amd.com>
+M: Dragan Cvetic <dragan.cvetic@amd.com>
S: Maintained
F: Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt
F: Documentation/misc-devices/xilinx_sdfec.rst
@@ -23202,7 +23402,6 @@
F: drivers/tty/serial/uartlite.c
XILINX VIDEO IP CORES
-M: Hyun Kwon <hyun.kwon@xilinx.com>
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: linux-media@vger.kernel.org
S: Supported
@@ -23216,8 +23415,10 @@
R: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
R: Michal Simek <michal.simek@amd.com>
S: Maintained
+F: Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
F: Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml
F: drivers/watchdog/of_xilinx_wdt.c
+F: drivers/watchdog/xilinx_wwdt.c
XILINX XDMA DRIVER
M: Lizhi Hou <lizhi.hou@amd.com>
@@ -23231,7 +23432,6 @@
F: include/linux/platform_data/amd_xdma.h
XILINX ZYNQMP DPDMA DRIVER
-M: Hyun Kwon <hyun.kwon@xilinx.com>
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: dmaengine@vger.kernel.org
S: Supported
@@ -23247,7 +23447,6 @@
F: drivers/edac/zynqmp_edac.c
XILINX ZYNQMP PSGTR PHY DRIVER
-M: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: linux-kernel@vger.kernel.org
S: Supported
@@ -23256,7 +23455,7 @@
F: drivers/phy/xilinx/phy-zynqmp.c
XILINX ZYNQMP SHA3 DRIVER
-M: Harsha <harsha.harsha@xilinx.com>
+M: Harsha <harsha.harsha@amd.com>
S: Maintained
F: drivers/crypto/xilinx/zynqmp-sha.c
@@ -23332,11 +23531,8 @@
F: mm/zbud.c
ZD1211RW WIRELESS DRIVER
-M: Ulrich Kunitz <kune@deine-taler.de>
L: linux-wireless@vger.kernel.org
-L: zd1211-devs@lists.sourceforge.net (subscribers-only)
-S: Maintained
-W: http://zd1211.ath.cx/wiki/DriverRewrite
+S: Orphan
F: drivers/net/wireless/zydas/zd1211rw/
ZD1301 MEDIA DRIVER
diff --git a/Makefile b/Makefile
index b68b43c..6bbf9db 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 6
-PATCHLEVEL = 4
+PATCHLEVEL = 5
SUBLEVEL = 0
-EXTRAVERSION = -rc7
+EXTRAVERSION = -rc5
NAME = Hurr durr I'ma ninja sloth
# *DOCUMENTATION*
@@ -38,6 +38,10 @@
# descending is started. They are now explicitly listed as the
# prepare rule.
+this-makefile := $(lastword $(MAKEFILE_LIST))
+export abs_srctree := $(realpath $(dir $(this-makefile)))
+export abs_objtree := $(CURDIR)
+
ifneq ($(sub_make_done),1)
# Do not use make's built-in rules and variables
@@ -185,20 +189,8 @@
# $(realpath ...) resolves symlinks
abs_objtree := $(realpath $(abs_objtree))
-else
-abs_objtree := $(CURDIR)
endif # ifneq ($(KBUILD_OUTPUT),)
-ifeq ($(abs_objtree),$(CURDIR))
-# Suppress "Entering directory ..." unless we are changing the work directory.
-MAKEFLAGS += --no-print-directory
-else
-need-sub-make := 1
-endif
-
-this-makefile := $(lastword $(MAKEFILE_LIST))
-abs_srctree := $(realpath $(dir $(this-makefile)))
-
ifneq ($(words $(subst :, ,$(abs_srctree))), 1)
$(error source directory cannot contain spaces or colons)
endif
@@ -211,9 +203,25 @@
$(this-makefile): ;
endif
-export abs_srctree abs_objtree
export sub_make_done := 1
+endif # sub_make_done
+
+ifeq ($(abs_objtree),$(CURDIR))
+# Suppress "Entering directory ..." if we are at the final work directory.
+no-print-directory := --no-print-directory
+else
+# Recursion to show "Entering directory ..."
+need-sub-make := 1
+endif
+
+ifeq ($(filter --no-print-directory, $(MAKEFLAGS)),)
+# If --no-print-directory is unset, recurse once again to set it.
+# You may end up recursing into __sub-make twice. This is needed due to the
+# behavior change in GNU Make 4.4.1.
+need-sub-make := 1
+endif
+
ifeq ($(need-sub-make),1)
PHONY += $(MAKECMDGOALS) __sub-make
@@ -223,18 +231,12 @@
# Invoke a second make in the output directory, passing relevant variables
__sub-make:
- $(Q)$(MAKE) -C $(abs_objtree) -f $(abs_srctree)/Makefile $(MAKECMDGOALS)
+ $(Q)$(MAKE) $(no-print-directory) -C $(abs_objtree) \
+ -f $(abs_srctree)/Makefile $(MAKECMDGOALS)
-endif # need-sub-make
-endif # sub_make_done
+else # need-sub-make
# We process the rest of the Makefile if this is the final invocation of make
-ifeq ($(need-sub-make),)
-
-# Do not print "Entering directory ...",
-# but we want to display it when entering to the output directory
-# so that IDEs/editors are able to understand relative filenames.
-MAKEFLAGS += --no-print-directory
ifeq ($(abs_srctree),$(abs_objtree))
# building in the source tree
@@ -447,8 +449,7 @@
HOSTPKG_CONFIG = pkg-config
KBUILD_USERHOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
- -O2 -fomit-frame-pointer -std=gnu11 \
- -Wdeclaration-after-statement
+ -O2 -fomit-frame-pointer -std=gnu11
KBUILD_USERCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(USERCFLAGS)
KBUILD_USERLDFLAGS := $(USERLDFLAGS)
@@ -554,11 +555,23 @@
$(USERINCLUDE)
KBUILD_AFLAGS := -D__ASSEMBLY__ -fno-PIE
-KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
- -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \
- -Werror=implicit-function-declaration -Werror=implicit-int \
- -Werror=return-type -Wno-format-security -funsigned-char \
- -std=gnu11
+
+KBUILD_CFLAGS :=
+KBUILD_CFLAGS += -std=gnu11
+KBUILD_CFLAGS += -fshort-wchar
+KBUILD_CFLAGS += -funsigned-char
+KBUILD_CFLAGS += -fno-common
+KBUILD_CFLAGS += -fno-PIE
+KBUILD_CFLAGS += -fno-strict-aliasing
+KBUILD_CFLAGS += -Wall
+KBUILD_CFLAGS += -Wundef
+KBUILD_CFLAGS += -Werror=implicit-function-declaration
+KBUILD_CFLAGS += -Werror=implicit-int
+KBUILD_CFLAGS += -Werror=return-type
+KBUILD_CFLAGS += -Werror=strict-prototypes
+KBUILD_CFLAGS += -Wno-format-security
+KBUILD_CFLAGS += -Wno-trigraphs
+
KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_RUSTFLAGS := $(rust_common_flags) \
--target=$(objtree)/scripts/target.json \
@@ -1012,9 +1025,6 @@
# arch Makefile may override CC so keep this after arch Makefile is included
NOSTDINC_FLAGS += -nostdinc
-# warn about C99 declaration after statement
-KBUILD_CFLAGS += -Wdeclaration-after-statement
-
# Variable Length Arrays (VLAs) should not be used anywhere in the kernel
KBUILD_CFLAGS += -Wvla
@@ -1026,6 +1036,12 @@
# globally built with -Wcast-function-type.
KBUILD_CFLAGS += $(call cc-option, -Wcast-function-type)
+# To gain proper coverage for CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE,
+# the kernel uses only C99 flexible arrays for dynamically sized trailing
+# arrays. Enforce this for everything that may examine structure sizes and
+# perform bounds checking.
+KBUILD_CFLAGS += $(call cc-option, -fstrict-flex-arrays=3)
+
# disable stringop warnings in gcc 8+
KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
@@ -1193,28 +1209,12 @@
export KBUILD_VMLINUX_LIBS
export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
-# Recurse until adjust_autoksyms.sh is satisfied
-PHONY += autoksyms_recursive
ifdef CONFIG_TRIM_UNUSED_KSYMS
# For the kernel to actually contain only the needed exported symbols,
# we have to build modules as well to determine what those symbols are.
-# (this can be evaluated only once include/config/auto.conf has been included)
KBUILD_MODULES := 1
-
-autoksyms_recursive: $(build-dir) modules.order
- $(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
- "$(MAKE) -f $(srctree)/Makefile autoksyms_recursive"
endif
-autoksyms_h := $(if $(CONFIG_TRIM_UNUSED_KSYMS), include/generated/autoksyms.h)
-
-quiet_cmd_autoksyms_h = GEN $@
- cmd_autoksyms_h = mkdir -p $(dir $@); \
- $(CONFIG_SHELL) $(srctree)/scripts/gen_autoksyms.sh $@
-
-$(autoksyms_h):
- $(call cmd,autoksyms_h)
-
# '$(AR) mPi' needs 'T' to workaround the bug of llvm-ar <= 14
quiet_cmd_ar_vmlinux.a = AR $@
cmd_ar_vmlinux.a = \
@@ -1223,7 +1223,7 @@
$(AR) mPiT $$($(AR) t $@ | sed -n 1p) $@ $$($(AR) t $@ | grep -F -f $(srctree)/scripts/head-object-list.txt)
targets += vmlinux.a
-vmlinux.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt autoksyms_recursive FORCE
+vmlinux.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
$(call if_changed,ar_vmlinux.a)
PHONY += vmlinux_o
@@ -1279,7 +1279,7 @@
PHONY += prepare archprepare
archprepare: outputmakefile archheaders archscripts scripts include/config/kernel.release \
- asm-generic $(version_h) $(autoksyms_h) include/generated/utsrelease.h \
+ asm-generic $(version_h) include/generated/utsrelease.h \
include/generated/compile.h include/generated/autoconf.h remove-stale-files
prepare0: archprepare
@@ -1561,6 +1561,8 @@
endif
endif
+endif # CONFIG_MODULES
+
modinst_pre :=
ifneq ($(filter modules_install,$(MAKECMDGOALS)),)
modinst_pre := __modinst_pre
@@ -1571,18 +1573,18 @@
__modinst_pre:
@rm -rf $(MODLIB)/kernel
@rm -f $(MODLIB)/source
- @mkdir -p $(MODLIB)/kernel
+ @mkdir -p $(MODLIB)
+ifdef CONFIG_MODULES
@ln -s $(abspath $(srctree)) $(MODLIB)/source
@if [ ! $(objtree) -ef $(MODLIB)/build ]; then \
rm -f $(MODLIB)/build ; \
ln -s $(CURDIR) $(MODLIB)/build ; \
fi
@sed 's:^\(.*\)\.o$$:kernel/\1.ko:' modules.order > $(MODLIB)/modules.order
+endif
@cp -f modules.builtin $(MODLIB)/
@cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/
-endif # CONFIG_MODULES
-
###
# Cleaning is done on three levels.
# make clean Delete most generated files
@@ -1924,6 +1926,13 @@
@echo ' clean - remove generated files in module directory only'
@echo ''
+__external_modules_error:
+ @echo >&2 '***'
+ @echo >&2 '*** The present kernel disabled CONFIG_MODULES.'
+ @echo >&2 '*** You cannot build or install external modules.'
+ @echo >&2 '***'
+ @false
+
endif # KBUILD_EXTMOD
# ---------------------------------------------------------------------------
@@ -1960,13 +1969,10 @@
# Modules not configured
# ---------------------------------------------------------------------------
-modules modules_install:
- @echo >&2 '***'
- @echo >&2 '*** The present kernel configuration has modules disabled.'
- @echo >&2 '*** To use the module feature, please run "make menuconfig" etc.'
- @echo >&2 '*** to enable CONFIG_MODULES.'
- @echo >&2 '***'
- @exit 1
+PHONY += __external_modules_error
+
+modules modules_install: __external_modules_error
+ @:
KBUILD_MODULES :=
@@ -2039,7 +2045,7 @@
-o -name '*.dtb.S' -o -name '*.dtbo.S' \
-o -name '*.dt.yaml' \
-o -name '*.dwo' -o -name '*.lst' \
- -o -name '*.su' -o -name '*.mod' -o -name '*.usyms' \
+ -o -name '*.su' -o -name '*.mod' \
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
-o -name '*.lex.c' -o -name '*.tab.[ch]' \
-o -name '*.asn1.[ch]' \
diff --git a/arch/Kconfig b/arch/Kconfig
index 205fd23..aff2746 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -34,6 +34,29 @@
config HOTPLUG_SMT
bool
+# Selected by HOTPLUG_CORE_SYNC_DEAD or HOTPLUG_CORE_SYNC_FULL
+config HOTPLUG_CORE_SYNC
+ bool
+
+# Basic CPU dead synchronization selected by architecture
+config HOTPLUG_CORE_SYNC_DEAD
+ bool
+ select HOTPLUG_CORE_SYNC
+
+# Full CPU synchronization with alive state selected by architecture
+config HOTPLUG_CORE_SYNC_FULL
+ bool
+ select HOTPLUG_CORE_SYNC_DEAD if HOTPLUG_CPU
+ select HOTPLUG_CORE_SYNC
+
+config HOTPLUG_SPLIT_STARTUP
+ bool
+ select HOTPLUG_CORE_SYNC_FULL
+
+config HOTPLUG_PARALLEL
+ bool
+ select HOTPLUG_SPLIT_STARTUP
+
config GENERIC_ENTRY
bool
@@ -285,6 +308,9 @@
config ARCH_HAS_DMA_CLEAR_UNCACHED
bool
+config ARCH_HAS_CPU_FINALIZE_INIT
+ bool
+
# Select if arch init_task must go in the __init_task_data section
config ARCH_TASK_STRUCT_ON_STACK
bool
@@ -400,20 +426,14 @@
The arch chooses to use the generic perf-NMI-based hardlockup
detector. Must define HAVE_PERF_EVENTS_NMI.
-config HAVE_NMI_WATCHDOG
- depends on HAVE_NMI
- bool
- help
- The arch provides a low level NMI watchdog. It provides
- asm/nmi.h, and defines its own arch_touch_nmi_watchdog().
-
config HAVE_HARDLOCKUP_DETECTOR_ARCH
bool
- select HAVE_NMI_WATCHDOG
help
- The arch chooses to provide its own hardlockup detector, which is
- a superset of the HAVE_NMI_WATCHDOG. It also conforms to config
- interfaces and parameters provided by hardlockup detector subsystem.
+ The arch provides its own hardlockup detector implementation instead
+ of the generic ones.
+
+ It uses the same command line parameters, and sysctl interface,
+ as the generic hardlockup detectors.
config HAVE_PERF_REGS
bool
@@ -1188,13 +1208,6 @@
config ARCH_NO_PREEMPT
bool
-config ARCH_EPHEMERAL_INODES
- def_bool n
- help
- An arch should select this symbol if it doesn't keep track of inode
- instances on its own, but instead relies on something else (e.g. the
- host kernel for an UML kernel).
-
config ARCH_SUPPORTS_RT
bool
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index a5c2b1a..d6968d0 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -30,6 +30,7 @@
select HAS_IOPORT
select HAVE_ARCH_AUDITSYSCALL
select HAVE_MOD_ARCH_SPECIFIC
+ select LOCK_MM_AND_FIND_VMA
select MODULES_USE_ELF_RELA
select ODD_RT_SIGACTION
select OLD_SIGSUSPEND
diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
index f2861a4..cbd9244 100644
--- a/arch/alpha/include/asm/atomic.h
+++ b/arch/alpha/include/asm/atomic.h
@@ -200,25 +200,6 @@ ATOMIC_OPS(xor, xor)
#undef ATOMIC_OP_RETURN
#undef ATOMIC_OP
-#define arch_atomic64_cmpxchg(v, old, new) \
- (arch_cmpxchg(&((v)->counter), old, new))
-#define arch_atomic64_xchg(v, new) \
- (arch_xchg(&((v)->counter), new))
-
-#define arch_atomic_cmpxchg(v, old, new) \
- (arch_cmpxchg(&((v)->counter), old, new))
-#define arch_atomic_xchg(v, new) \
- (arch_xchg(&((v)->counter), new))
-
-/**
- * arch_atomic_fetch_add_unless - add unless the number is a given value
- * @v: pointer of type atomic_t
- * @a: the amount to add to v...
- * @u: ...unless v is equal to u.
- *
- * Atomically adds @a to @v, so long as it was not @u.
- * Returns the old value of @v.
- */
static __inline__ int arch_atomic_fetch_add_unless(atomic_t *v, int a, int u)
{
int c, new, old;
@@ -242,15 +223,6 @@ static __inline__ int arch_atomic_fetch_add_unless(atomic_t *v, int a, int u)
}
#define arch_atomic_fetch_add_unless arch_atomic_fetch_add_unless
-/**
- * arch_atomic64_fetch_add_unless - add unless the number is a given value
- * @v: pointer of type atomic64_t
- * @a: the amount to add to v...
- * @u: ...unless v is equal to u.
- *
- * Atomically adds @a to @v, so long as it was not @u.
- * Returns the old value of @v.
- */
static __inline__ s64 arch_atomic64_fetch_add_unless(atomic64_t *v, s64 a, s64 u)
{
s64 c, new, old;
@@ -274,13 +246,6 @@ static __inline__ s64 arch_atomic64_fetch_add_unless(atomic64_t *v, s64 a, s64 u
}
#define arch_atomic64_fetch_add_unless arch_atomic64_fetch_add_unless
-/*
- * arch_atomic64_dec_if_positive - decrement by 1 if old value positive
- * @v: pointer of type atomic_t
- *
- * The function returns the old value of *v minus 1, even if
- * the atomic variable, v, was not decremented.
- */
static inline s64 arch_atomic64_dec_if_positive(atomic64_t *v)
{
s64 old, tmp;
diff --git a/arch/alpha/include/asm/bugs.h b/arch/alpha/include/asm/bugs.h
deleted file mode 100644
index 78030d1..0000000
--- a/arch/alpha/include/asm/bugs.h
+++ /dev/null
@@ -1,20 +0,0 @@
-/*
- * include/asm-alpha/bugs.h
- *
- * Copyright (C) 1994 Linus Torvalds
- */
-
-/*
- * This is included by init/main.c to check for architecture-dependent bugs.
- *
- * Needs:
- * void check_bugs(void);
- */
-
-/*
- * I don't know of any alpha bugs yet.. Nice chip
- */
-
-static void check_bugs(void)
-{
-}
diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
index 714abe4..55bb1c0 100644
--- a/arch/alpha/include/asm/processor.h
+++ b/arch/alpha/include/asm/processor.h
@@ -47,12 +47,6 @@ unsigned long __get_wchan(struct task_struct *p);
#define ARCH_HAS_PREFETCH
#define ARCH_HAS_PREFETCHW
-#define ARCH_HAS_SPINLOCK_PREFETCH
-
-#ifndef CONFIG_SMP
-/* Nothing to prefetch. */
-#define spin_lock_prefetch(lock) do { } while (0)
-#endif
extern inline void prefetch(const void *ptr)
{
@@ -64,11 +58,4 @@ extern inline void prefetchw(const void *ptr)
__builtin_prefetch(ptr, 1, 3);
}
-#ifdef CONFIG_SMP
-extern inline void spin_lock_prefetch(const void *ptr)
-{
- __builtin_prefetch(ptr, 1, 3);
-}
-#endif
-
#endif /* __ASM_ALPHA_PROCESSOR_H */
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 739891b..e94f621 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -137,6 +137,9 @@
#define SO_RCVMARK 75
+#define SO_PASSPIDFD 76
+#define SO_PEERPIDFD 77
+
#if !defined(__KERNEL__)
#if __BITS_PER_LONG == 64
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index 2a9a877..d98701e 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1014,8 +1014,6 @@ SYSCALL_DEFINE2(osf_settimeofday, struct timeval32 __user *, tv,
return do_sys_settimeofday64(tv ? &kts : NULL, tz ? &ktz : NULL);
}
-asmlinkage long sys_ni_posix_timers(void);
-
SYSCALL_DEFINE2(osf_utimes, const char __user *, filename,
struct timeval32 __user *, tvs)
{
diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
index 33bf3a6..b650ff1 100644
--- a/arch/alpha/kernel/setup.c
+++ b/arch/alpha/kernel/setup.c
@@ -658,7 +658,7 @@ setup_arch(char **cmdline_p)
#endif
/* Default root filesystem to sda2. */
- ROOT_DEV = Root_SDA2;
+ ROOT_DEV = MKDEV(SCSI_DISK0_MAJOR, 2);
#ifdef CONFIG_EISA
/* FIXME: only set this when we actually have EISA in this box? */
diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl
index 8ebacf3..1f13995 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -490,3 +490,4 @@
558 common process_mrelease sys_process_mrelease
559 common futex_waitv sys_futex_waitv
560 common set_mempolicy_home_node sys_ni_syscall
+561 common cachestat sys_cachestat
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index 7b01ae4..8c98504 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -119,20 +119,12 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
flags |= FAULT_FLAG_USER;
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
retry:
- mmap_read_lock(mm);
- vma = find_vma(mm, address);
+ vma = lock_mm_and_find_vma(mm, address, regs);
if (!vma)
- goto bad_area;
- if (vma->vm_start <= address)
- goto good_area;
- if (!(vma->vm_flags & VM_GROWSDOWN))
- goto bad_area;
- if (expand_stack(vma, address))
- goto bad_area;
+ goto bad_area_nosemaphore;
/* Ok, we have a good vm_area for this memory access, so
we can handle it. */
- good_area:
si_code = SEGV_ACCERR;
if (cause < 0) {
if (!(vma->vm_flags & VM_EXEC))
@@ -192,6 +184,7 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
bad_area:
mmap_read_unlock(mm);
+ bad_area_nosemaphore:
if (user_mode(regs))
goto do_sigsegv;
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index ab6d701..96cf872 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -41,6 +41,7 @@
select HAVE_PERF_EVENTS
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
+ select LOCK_MM_AND_FIND_VMA
select MODULES_USE_ELF_RELA
select OF
select OF_EARLY_FLATTREE
diff --git a/arch/arc/configs/axs103_smp_defconfig b/arch/arc/configs/axs103_smp_defconfig
index 2f336d9..07c8928 100644
--- a/arch/arc/configs/axs103_smp_defconfig
+++ b/arch/arc/configs/axs103_smp_defconfig
@@ -13,7 +13,6 @@
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
-CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
diff --git a/arch/arc/configs/haps_hs_defconfig b/arch/arc/configs/haps_hs_defconfig
index 899b2fd..8c3ed5d 100644
--- a/arch/arc/configs/haps_hs_defconfig
+++ b/arch/arc/configs/haps_hs_defconfig
@@ -14,7 +14,6 @@
CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_COMPAT_BRK is not set
-CONFIG_SLAB=y
CONFIG_ARC_BUILTIN_DTB_NAME="haps_hs"
CONFIG_MODULES=y
# CONFIG_BLK_DEV_BSG is not set
diff --git a/arch/arc/configs/haps_hs_smp_defconfig b/arch/arc/configs/haps_hs_smp_defconfig
index 0d32aac..61107e8 100644
--- a/arch/arc/configs/haps_hs_smp_defconfig
+++ b/arch/arc/configs/haps_hs_smp_defconfig
@@ -15,7 +15,6 @@
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
-CONFIG_SLAB=y
CONFIG_SMP=y
CONFIG_ARC_BUILTIN_DTB_NAME="haps_hs_idu"
CONFIG_KPROBES=y
diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig
index d18378d..4ee2a15 100644
--- a/arch/arc/configs/hsdk_defconfig
+++ b/arch/arc/configs/hsdk_defconfig
@@ -13,7 +13,6 @@
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
-CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_ARC_SOC_HSDK=y
diff --git a/arch/arc/configs/tb10x_defconfig b/arch/arc/configs/tb10x_defconfig
index 6f0d2be..941bbad 100644
--- a/arch/arc/configs/tb10x_defconfig
+++ b/arch/arc/configs/tb10x_defconfig
@@ -19,7 +19,6 @@
CONFIG_EMBEDDED=y
# CONFIG_COMPAT_BRK is not set
CONFIG_ISA_ARCOMPACT=y
-CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
diff --git a/arch/arc/include/asm/atomic-spinlock.h b/arch/arc/include/asm/atomic-spinlock.h
index 2c83034..89d12a6 100644
--- a/arch/arc/include/asm/atomic-spinlock.h
+++ b/arch/arc/include/asm/atomic-spinlock.h
@@ -81,6 +81,11 @@ static inline int arch_atomic_fetch_##op(int i, atomic_t *v) \
ATOMIC_OPS(add, +=, add)
ATOMIC_OPS(sub, -=, sub)
+#define arch_atomic_fetch_add arch_atomic_fetch_add
+#define arch_atomic_fetch_sub arch_atomic_fetch_sub
+#define arch_atomic_add_return arch_atomic_add_return
+#define arch_atomic_sub_return arch_atomic_sub_return
+
#undef ATOMIC_OPS
#define ATOMIC_OPS(op, c_op, asm_op) \
ATOMIC_OP(op, c_op, asm_op) \
@@ -92,7 +97,11 @@ ATOMIC_OPS(or, |=, or)
ATOMIC_OPS(xor, ^=, xor)
#define arch_atomic_andnot arch_atomic_andnot
+
+#define arch_atomic_fetch_and arch_atomic_fetch_and
#define arch_atomic_fetch_andnot arch_atomic_fetch_andnot
+#define arch_atomic_fetch_or arch_atomic_fetch_or
+#define arch_atomic_fetch_xor arch_atomic_fetch_xor
#undef ATOMIC_OPS
#undef ATOMIC_FETCH_OP
diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index 52ee51e..592d7ff 100644
--- a/arch/arc/include/asm/atomic.h
+++ b/arch/arc/include/asm/atomic.h
@@ -22,30 +22,6 @@
#include <asm/atomic-spinlock.h>
#endif
-#define arch_atomic_cmpxchg(v, o, n) \
-({ \
- arch_cmpxchg(&((v)->counter), (o), (n)); \
-})
-
-#ifdef arch_cmpxchg_relaxed
-#define arch_atomic_cmpxchg_relaxed(v, o, n) \
-({ \
- arch_cmpxchg_relaxed(&((v)->counter), (o), (n)); \
-})
-#endif
-
-#define arch_atomic_xchg(v, n) \
-({ \
- arch_xchg(&((v)->counter), (n)); \
-})
-
-#ifdef arch_xchg_relaxed
-#define arch_atomic_xchg_relaxed(v, n) \
-({ \
- arch_xchg_relaxed(&((v)->counter), (n)); \
-})
-#endif
-
/*
* 64-bit atomics
*/
diff --git a/arch/arc/include/asm/atomic64-arcv2.h b/arch/arc/include/asm/atomic64-arcv2.h
index c5a8010..6b6db98 100644
--- a/arch/arc/include/asm/atomic64-arcv2.h
+++ b/arch/arc/include/asm/atomic64-arcv2.h
@@ -159,6 +159,7 @@ arch_atomic64_cmpxchg(atomic64_t *ptr, s64 expected, s64 new)
return prev;
}
+#define arch_atomic64_cmpxchg arch_atomic64_cmpxchg
static inline s64 arch_atomic64_xchg(atomic64_t *ptr, s64 new)
{
@@ -179,14 +180,7 @@ static inline s64 arch_atomic64_xchg(atomic64_t *ptr, s64 new)
return prev;
}
-
-/**
- * arch_atomic64_dec_if_positive - decrement by 1 if old value positive
- * @v: pointer of type atomic64_t
- *
- * The function returns the old value of *v minus 1, even if
- * the atomic variable, v, was not decremented.
- */
+#define arch_atomic64_xchg arch_atomic64_xchg
static inline s64 arch_atomic64_dec_if_positive(atomic64_t *v)
{
@@ -212,15 +206,6 @@ static inline s64 arch_atomic64_dec_if_positive(atomic64_t *v)
}
#define arch_atomic64_dec_if_positive arch_atomic64_dec_if_positive
-/**
- * arch_atomic64_fetch_add_unless - add unless the number is a given value
- * @v: pointer of type atomic64_t
- * @a: the amount to add to v...
- * @u: ...unless v is equal to u.
- *
- * Atomically adds @a to @v, if it was not @u.
- * Returns the old value of @v
- */
static inline s64 arch_atomic64_fetch_add_unless(atomic64_t *v, s64 a, s64 u)
{
s64 old, temp;
diff --git a/arch/arc/include/asm/fb.h b/arch/arc/include/asm/fb.h
index dc2e303..9c2383d 100644
--- a/arch/arc/include/asm/fb.h
+++ b/arch/arc/include/asm/fb.h
@@ -1,20 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0 */
+
#ifndef _ASM_FB_H_
#define _ASM_FB_H_
-#include <linux/fb.h>
-#include <linux/fs.h>
-#include <asm/page.h>
-
-static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
- unsigned long off)
-{
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-}
-
-static inline int fb_is_primary_device(struct fb_info *info)
-{
- return 0;
-}
+#include <asm-generic/fb.h>
#endif /* _ASM_FB_H_ */
diff --git a/arch/arc/include/asm/linkage.h b/arch/arc/include/asm/linkage.h
index c9434ff..8a3fb71 100644
--- a/arch/arc/include/asm/linkage.h
+++ b/arch/arc/include/asm/linkage.h
@@ -8,6 +8,10 @@
#include <asm/dwarf.h>
+#define ASM_NL ` /* use '`' to mark new line in macro */
+#define __ALIGN .align 4
+#define __ALIGN_STR __stringify(__ALIGN)
+
#ifdef __ASSEMBLY__
.macro ST2 e, o, off
@@ -28,10 +32,6 @@
#endif
.endm
-#define ASM_NL ` /* use '`' to mark new line in macro */
-#define __ALIGN .align 4
-#define __ALIGN_STR __stringify(__ALIGN)
-
/* annotation for data we want in DCCM - if enabled in .config */
.macro ARCFP_DATA nm
#ifdef CONFIG_ARC_HAS_DCCM
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index 5ca59a4..f59e722 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -113,15 +113,9 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
retry:
- mmap_read_lock(mm);
-
- vma = find_vma(mm, address);
+ vma = lock_mm_and_find_vma(mm, address, regs);
if (!vma)
- goto bad_area;
- if (unlikely(address < vma->vm_start)) {
- if (!(vma->vm_flags & VM_GROWSDOWN) || expand_stack(vma, address))
- goto bad_area;
- }
+ goto bad_area_nosemaphore;
/*
* vm_area is good, now check permissions for this memory access
@@ -161,6 +155,7 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)
bad_area:
mmap_read_unlock(mm);
+bad_area_nosemaphore:
/*
* Major/minor page fault accounting
* (in case of retry we only land here once)
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index 2b89b6c..9f64d72 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -87,7 +87,7 @@ void __init setup_arch_memory(void)
setup_initial_init_mm(_text, _etext, _edata, _end);
/* first page of system - kernel .vector starts here */
- min_low_pfn = virt_to_pfn(CONFIG_LINUX_RAM_BASE);
+ min_low_pfn = virt_to_pfn((void *)CONFIG_LINUX_RAM_BASE);
/* Last usable page of low mem */
max_low_pfn = max_pfn = PFN_DOWN(low_mem_start + low_mem_sz);
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0fb4b21..7a27550 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -5,6 +5,7 @@
select ARCH_32BIT_OFF_T
select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE if HAVE_KRETPROBES && FRAME_POINTER && !ARM_UNWIND
select ARCH_HAS_BINFMT_FLAT
+ select ARCH_HAS_CPU_FINALIZE_INIT if MMU
select ARCH_HAS_CURRENT_STACK_POINTER
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DMA_WRITE_COMBINE if !ARM_DMA_MEM_BUFFERABLE
@@ -124,7 +125,9 @@
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UID16
select HAVE_VIRT_CPU_ACCOUNTING_GEN
+ select HOTPLUG_CORE_SYNC_DEAD if HOTPLUG_CPU
select IRQ_FORCED_THREADING
+ select LOCK_MM_AND_FIND_VMA
select MODULES_USE_ELF_REL
select NEED_DMA_MAP_STATE
select OF_EARLY_FLATTREE if OF
@@ -1460,6 +1463,9 @@
help
Include support for flattened device tree machine descriptions.
+config ARCH_WANT_FLAT_DTB_INSTALL
+ def_bool y
+
config ATAGS
bool "Support for the traditional ATAGS boot data passing"
default y
@@ -1780,7 +1786,7 @@
Say Y to include VFP support code in the kernel. This is needed
if your hardware includes a VFP unit.
- Please see <file:Documentation/arm/vfp/release-notes.rst> for
+ Please see <file:Documentation/arch/arm/vfp/release-notes.rst> for
release notes and additional status information.
Say N if your target does not have VFP hardware.
diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index 1feb6b0..627752f 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -2,6 +2,7 @@
#include <linux/libfdt_env.h>
#include <asm/setup.h>
#include <libfdt.h>
+#include "misc.h"
#if defined(CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND)
#define do_extend_cmdline 1
diff --git a/arch/arm/boot/compressed/fdt_check_mem_start.c b/arch/arm/boot/compressed/fdt_check_mem_start.c
index 9291a26..aa85656 100644
--- a/arch/arm/boot/compressed/fdt_check_mem_start.c
+++ b/arch/arm/boot/compressed/fdt_check_mem_start.c
@@ -3,6 +3,7 @@
#include <linux/kernel.h>
#include <linux/libfdt.h>
#include <linux/sizes.h>
+#include "misc.h"
static const void *get_prop(const void *fdt, const char *node_path,
const char *property, int minlen)
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index abfed1a..6b4baa6a 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -103,9 +103,6 @@ static void putstr(const char *ptr)
/*
* gzip declarations
*/
-extern char input_data[];
-extern char input_data_end[];
-
unsigned char *output_data;
unsigned long free_mem_ptr;
@@ -131,9 +128,6 @@ asmlinkage void __div0(void)
error("Attempting division by 0!");
}
-extern int do_decompress(u8 *input, int len, u8 *output, void (*error)(char *x));
-
-
void
decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
unsigned long free_mem_ptr_end_p,
diff --git a/arch/arm/boot/compressed/misc.h b/arch/arm/boot/compressed/misc.h
index c958dcc..6da00a2 100644
--- a/arch/arm/boot/compressed/misc.h
+++ b/arch/arm/boot/compressed/misc.h
@@ -6,5 +6,16 @@
void error(char *x) __noreturn;
extern unsigned long free_mem_ptr;
extern unsigned long free_mem_end_ptr;
+void __div0(void);
+void
+decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
+ unsigned long free_mem_ptr_end_p, int arch_id);
+void fortify_panic(const char *name);
+int atags_to_fdt(void *atag_list, void *fdt, int total_space);
+uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt);
+int do_decompress(u8 *input, int len, u8 *output, void (*error)(char *x));
+
+extern char input_data[];
+extern char input_data_end[];
#endif
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 59829fc..efe38eb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1,1672 +1,41 @@
# SPDX-License-Identifier: GPL-2.0
-dtb-$(CONFIG_ARCH_ALPINE) += \
- alpine-db.dtb
-dtb-$(CONFIG_MACH_ARTPEC6) += \
- artpec6-devboard.dtb
-dtb-$(CONFIG_MACH_ASM9260) += \
- alphascale-asm9260-devkit.dtb
-# Keep at91 dtb files sorted alphabetically for each SoC
-dtb-$(CONFIG_SOC_AT91RM9200) += \
- at91rm9200ek.dtb \
- mpa1600.dtb
-dtb-$(CONFIG_SOC_AT91SAM9) += \
- animeo_ip.dtb \
- at91-qil_a9260.dtb \
- aks-cdu.dtb \
- ethernut5.dtb \
- evk-pro3.dtb \
- tny_a9260.dtb \
- usb_a9260.dtb \
- at91sam9260ek.dtb \
- at91sam9261ek.dtb \
- at91sam9263ek.dtb \
- at91-sam9_l9260.dtb \
- tny_a9263.dtb \
- usb_a9263.dtb \
- at91-foxg20.dtb \
- at91-kizbox.dtb \
- at91-lmu5000.dtb \
- at91sam9g20ek.dtb \
- at91sam9g20ek_2mmc.dtb \
- tny_a9g20.dtb \
- usb_a9g20.dtb \
- usb_a9g20_lpw.dtb \
- at91sam9m10g45ek.dtb \
- pm9g45.dtb \
- at91sam9n12ek.dtb \
- at91sam9rlek.dtb \
- at91-ariag25.dtb \
- at91-ariettag25.dtb \
- at91-cosino_mega2560.dtb \
- at91-kizboxmini-base.dtb \
- at91-kizboxmini-mb.dtb \
- at91-kizboxmini-rd.dtb \
- at91-q5xr5.dtb \
- at91-smartkiz.dtb \
- at91-wb45n.dtb \
- at91sam9g15ek.dtb \
- at91sam9g25-gardena-smart-gateway.dtb \
- at91sam9g25ek.dtb \
- at91sam9g35ek.dtb \
- at91sam9x25ek.dtb \
- at91sam9x35ek.dtb
-dtb-$(CONFIG_SOC_SAM9X60) += \
- at91-sam9x60_curiosity.dtb \
- at91-sam9x60ek.dtb
-dtb-$(CONFIG_SOC_SAM_V7) += \
- at91-kizbox2-2.dtb \
- at91-kizbox3-hs.dtb \
- at91-nattis-2-natte-2.dtb \
- at91-sama5d27_som1_ek.dtb \
- at91-sama5d27_wlsom1_ek.dtb \
- at91-sama5d2_icp.dtb \
- at91-sama5d2_ptc_ek.dtb \
- at91-sama5d2_xplained.dtb \
- at91-sama5d3_eds.dtb \
- at91-sama5d3_ksz9477_evb.dtb \
- at91-sama5d3_xplained.dtb \
- at91-dvk_som60.dtb \
- at91-gatwick.dtb \
- at91-tse850-3.dtb \
- at91-wb50n.dtb \
- sama5d31ek.dtb \
- sama5d33ek.dtb \
- sama5d34ek.dtb \
- sama5d35ek.dtb \
- sama5d36ek.dtb \
- sama5d36ek_cmp.dtb \
- at91-sama5d4_ma5d4evk.dtb \
- at91-sama5d4_xplained.dtb \
- at91-sama5d4ek.dtb \
- at91-vinco.dtb
-dtb-$(CONFIG_SOC_SAMA7G5) += \
- at91-sama7g5ek.dtb
-dtb-$(CONFIG_SOC_SP7021) += \
- sunplus-sp7021-demo-v3.dtb
-dtb-$(CONFIG_ARCH_AXXIA) += \
- axm5516-amarillo.dtb
-dtb-$(CONFIG_ARCH_BCM2835) += \
- bcm2835-rpi-b.dtb \
- bcm2835-rpi-a.dtb \
- bcm2835-rpi-b-rev2.dtb \
- bcm2835-rpi-b-plus.dtb \
- bcm2835-rpi-a-plus.dtb \
- bcm2835-rpi-cm1-io1.dtb \
- bcm2836-rpi-2-b.dtb \
- bcm2837-rpi-3-a-plus.dtb \
- bcm2837-rpi-3-b.dtb \
- bcm2837-rpi-3-b-plus.dtb \
- bcm2837-rpi-cm3-io3.dtb \
- bcm2837-rpi-zero-2-w.dtb \
- bcm2711-rpi-400.dtb \
- bcm2711-rpi-4-b.dtb \
- bcm2711-rpi-cm4-io.dtb \
- bcm2835-rpi-zero.dtb \
- bcm2835-rpi-zero-w.dtb
-dtb-$(CONFIG_ARCH_BCM_5301X) += \
- bcm4708-asus-rt-ac56u.dtb \
- bcm4708-asus-rt-ac68u.dtb \
- bcm4708-buffalo-wzr-1750dhp.dtb \
- bcm4708-buffalo-wzr-1166dhp.dtb \
- bcm4708-buffalo-wzr-1166dhp2.dtb \
- bcm4708-linksys-ea6300-v1.dtb \
- bcm4708-linksys-ea6500-v2.dtb \
- bcm4708-luxul-xap-1510.dtb \
- bcm4708-luxul-xwc-1000.dtb \
- bcm4708-netgear-r6250.dtb \
- bcm4708-netgear-r6300-v2.dtb \
- bcm4708-smartrg-sr400ac.dtb \
- bcm47081-asus-rt-n18u.dtb \
- bcm47081-buffalo-wzr-600dhp2.dtb \
- bcm47081-buffalo-wzr-900dhp.dtb \
- bcm47081-luxul-xap-1410.dtb \
- bcm47081-luxul-xwr-1200.dtb \
- bcm47081-tplink-archer-c5-v2.dtb \
- bcm4709-asus-rt-ac87u.dtb \
- bcm4709-buffalo-wxr-1900dhp.dtb \
- bcm4709-linksys-ea9200.dtb \
- bcm4709-netgear-r7000.dtb \
- bcm4709-netgear-r8000.dtb \
- bcm4709-tplink-archer-c9-v1.dtb \
- bcm47094-asus-rt-ac88u.dtb \
- bcm47094-dlink-dir-885l.dtb \
- bcm47094-dlink-dir-890l.dtb \
- bcm47094-linksys-panamera.dtb \
- bcm47094-luxul-abr-4500.dtb \
- bcm47094-luxul-xap-1610.dtb \
- bcm47094-luxul-xbr-4500.dtb \
- bcm47094-luxul-xwc-2000.dtb \
- bcm47094-luxul-xwr-3100.dtb \
- bcm47094-luxul-xwr-3150-v1.dtb \
- bcm47094-netgear-r8500.dtb \
- bcm47094-phicomm-k3.dtb \
- bcm53015-meraki-mr26.dtb \
- bcm53016-dlink-dwl-8610ap.dtb \
- bcm53016-meraki-mr32.dtb \
- bcm94708.dtb \
- bcm94709.dtb \
- bcm953012er.dtb \
- bcm953012hr.dtb \
- bcm953012k.dtb
-dtb-$(CONFIG_ARCH_BCM_53573) += \
- bcm47189-luxul-xap-1440.dtb \
- bcm47189-luxul-xap-810.dtb \
- bcm47189-tenda-ac9.dtb \
- bcm947189acdbmr.dtb
-dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
- bcm911360_entphn.dtb \
- bcm911360k.dtb \
- bcm958300k.dtb \
- bcm958305k.dtb
-dtb-$(CONFIG_ARCH_BCM_HR2) += \
- bcm53340-ubnt-unifi-switch8.dtb
-dtb-$(CONFIG_ARCH_BCM_MOBILE) += \
- bcm28155-ap.dtb \
- bcm21664-garnet.dtb \
- bcm23550-sparrow.dtb
-dtb-$(CONFIG_ARCH_BCM_NSP) += \
- bcm958522er.dtb \
- bcm958525er.dtb \
- bcm958525xmc.dtb \
- bcm958622hr.dtb \
- bcm958623hr.dtb \
- bcm958625-meraki-mx64.dtb \
- bcm958625-meraki-mx64-a0.dtb \
- bcm958625-meraki-mx64w.dtb \
- bcm958625-meraki-mx64w-a0.dtb \
- bcm958625-meraki-mx65.dtb \
- bcm958625-meraki-mx65w.dtb \
- bcm958625hr.dtb \
- bcm988312hr.dtb \
- bcm958625k.dtb
-dtb-$(CONFIG_ARCH_BERLIN) += \
- berlin2-sony-nsz-gs7.dtb \
- berlin2cd-google-chromecast.dtb \
- berlin2cd-valve-steamlink.dtb \
- berlin2q-marvell-dmp.dtb
-dtb-$(CONFIG_ARCH_BRCMSTB) += \
- bcm7445-bcm97445svmb.dtb
-dtb-$(CONFIG_ARCH_BCMBCA) += \
- bcm947622.dtb \
- bcm963138.dtb \
- bcm963138dvt.dtb \
- bcm963148.dtb \
- bcm963178.dtb \
- bcm96756.dtb \
- bcm96846.dtb \
- bcm96855.dtb \
- bcm96878.dtb
-dtb-$(CONFIG_ARCH_CLPS711X) += \
- ep7211-edb7211.dtb
-dtb-$(CONFIG_ARCH_DAVINCI) += \
- da850-lcdk.dtb \
- da850-enbw-cmc.dtb \
- da850-evm.dtb \
- da850-lego-ev3.dtb
-dtb-$(CONFIG_ARCH_DIGICOLOR) += \
- cx92755_equinox.dtb
-dtb-$(CONFIG_ARCH_AIROHA) += \
- en7523-evb.dtb
-dtb-$(CONFIG_ARCH_EXYNOS3) += \
- exynos3250-artik5-eval.dtb \
- exynos3250-monk.dtb \
- exynos3250-rinato.dtb
-dtb-$(CONFIG_ARCH_EXYNOS4) += \
- exynos4210-i9100.dtb \
- exynos4210-origen.dtb \
- exynos4210-smdkv310.dtb \
- exynos4210-trats.dtb \
- exynos4210-universal_c210.dtb \
- exynos4412-i9300.dtb \
- exynos4412-i9305.dtb \
- exynos4412-itop-elite.dtb \
- exynos4412-n710x.dtb \
- exynos4412-odroidu3.dtb \
- exynos4412-odroidx.dtb \
- exynos4412-odroidx2.dtb \
- exynos4412-origen.dtb \
- exynos4412-p4note-n8010.dtb \
- exynos4412-smdk4412.dtb \
- exynos4412-tiny4412.dtb \
- exynos4412-trats2.dtb
-dtb-$(CONFIG_ARCH_EXYNOS5) += \
- exynos5250-arndale.dtb \
- exynos5250-smdk5250.dtb \
- exynos5250-snow.dtb \
- exynos5250-snow-rev5.dtb \
- exynos5250-spring.dtb \
- exynos5260-xyref5260.dtb \
- exynos5410-odroidxu.dtb \
- exynos5410-smdk5410.dtb \
- exynos5420-arndale-octa.dtb \
- exynos5420-peach-pit.dtb \
- exynos5420-smdk5420.dtb \
- exynos5420-chagall-wifi.dtb \
- exynos5420-klimt-wifi.dtb \
- exynos5422-odroidhc1.dtb \
- exynos5422-odroidxu3.dtb \
- exynos5422-odroidxu3-lite.dtb \
- exynos5422-odroidxu4.dtb \
- exynos5422-samsung-k3g.dtb \
- exynos5800-peach-pi.dtb
-dtb-$(CONFIG_ARCH_GEMINI) += \
- gemini-dlink-dir-685.dtb \
- gemini-dlink-dns-313.dtb \
- gemini-nas4220b.dtb \
- gemini-ns2502.dtb \
- gemini-rut1xx.dtb \
- gemini-sl93512r.dtb \
- gemini-sq201.dtb \
- gemini-ssi1328.dtb \
- gemini-wbd111.dtb \
- gemini-wbd222.dtb
-dtb-$(CONFIG_ARCH_HI3xxx) += \
- hi3620-hi4511.dtb
-dtb-$(CONFIG_ARCH_HIGHBANK) += \
- highbank.dtb \
- ecx-2000.dtb
-dtb-$(CONFIG_ARCH_HIP01) += \
- hip01-ca9x2.dtb
-dtb-$(CONFIG_ARCH_HIP04) += \
- hip04-d01.dtb
-dtb-$(CONFIG_ARCH_HISI) += \
- hi3519-demb.dtb
-dtb-$(CONFIG_ARCH_HIX5HD2) += \
- hisi-x5hd2-dkb.dtb
-dtb-$(CONFIG_ARCH_HPE_GXP) += \
- hpe-bmc-dl360gen10.dtb
-dtb-$(CONFIG_ARCH_INTEGRATOR) += \
- integratorap.dtb \
- integratorap-im-pd1.dtb \
- integratorcp.dtb
-dtb-$(CONFIG_ARCH_IXP4XX) += \
- intel-ixp42x-linksys-nslu2.dtb \
- intel-ixp42x-linksys-wrv54g.dtb \
- intel-ixp42x-freecom-fsg-3.dtb \
- intel-ixp42x-welltech-epbx100.dtb \
- intel-ixp42x-ixdp425.dtb \
- intel-ixp43x-kixrp435.dtb \
- intel-ixp46x-ixdp465.dtb \
- intel-ixp42x-adi-coyote.dtb \
- intel-ixp42x-ixdpg425.dtb \
- intel-ixp42x-goramo-multilink.dtb \
- intel-ixp42x-iomega-nas100d.dtb \
- intel-ixp42x-dlink-dsm-g600.dtb \
- intel-ixp42x-gateworks-gw2348.dtb \
- intel-ixp43x-gateworks-gw2358.dtb \
- intel-ixp42x-netgear-wg302v1.dtb \
- intel-ixp42x-arcom-vulcan.dtb \
- intel-ixp42x-gateway-7001.dtb
-dtb-$(CONFIG_ARCH_KEYSTONE) += \
- keystone-k2hk-evm.dtb \
- keystone-k2l-evm.dtb \
- keystone-k2e-evm.dtb \
- keystone-k2g-evm.dtb \
- keystone-k2g-ice.dtb
-dtb-$(CONFIG_MACH_KIRKWOOD) += \
- kirkwood-b3.dtb \
- kirkwood-blackarmor-nas220.dtb \
- kirkwood-c200-v1.dtb \
- kirkwood-cloudbox.dtb \
- kirkwood-d2net.dtb \
- kirkwood-db-88f6281.dtb \
- kirkwood-db-88f6282.dtb \
- kirkwood-dir665.dtb \
- kirkwood-dns320.dtb \
- kirkwood-dns325.dtb \
- kirkwood-dockstar.dtb \
- kirkwood-dreamplug.dtb \
- kirkwood-ds109.dtb \
- kirkwood-ds110jv10.dtb \
- kirkwood-ds111.dtb \
- kirkwood-ds112.dtb \
- kirkwood-ds209.dtb \
- kirkwood-ds210.dtb \
- kirkwood-ds212.dtb \
- kirkwood-ds212j.dtb \
- kirkwood-ds409.dtb \
- kirkwood-ds409slim.dtb \
- kirkwood-ds411.dtb \
- kirkwood-ds411j.dtb \
- kirkwood-ds411slim.dtb \
- kirkwood-goflexnet.dtb \
- kirkwood-guruplug-server-plus.dtb \
- kirkwood-ib62x0.dtb \
- kirkwood-iconnect.dtb \
- kirkwood-iomega_ix2_200.dtb \
- kirkwood-is2.dtb \
- kirkwood-km_kirkwood.dtb \
- kirkwood-l-50.dtb \
- kirkwood-laplug.dtb \
- kirkwood-linkstation-lsqvl.dtb \
- kirkwood-linkstation-lsvl.dtb \
- kirkwood-linkstation-lswsxl.dtb \
- kirkwood-linkstation-lswvl.dtb \
- kirkwood-linkstation-lswxl.dtb \
- kirkwood-linksys-viper.dtb \
- kirkwood-lschlv2.dtb \
- kirkwood-lsxhl.dtb \
- kirkwood-mplcec4.dtb \
- kirkwood-mv88f6281gtw-ge.dtb \
- kirkwood-nas2big.dtb \
- kirkwood-net2big.dtb \
- kirkwood-net5big.dtb \
- kirkwood-netgear_readynas_duo_v2.dtb \
- kirkwood-netgear_readynas_nv+_v2.dtb \
- kirkwood-ns2.dtb \
- kirkwood-ns2lite.dtb \
- kirkwood-ns2max.dtb \
- kirkwood-ns2mini.dtb \
- kirkwood-nsa310.dtb \
- kirkwood-nsa310a.dtb \
- kirkwood-nsa310s.dtb \
- kirkwood-nsa320.dtb \
- kirkwood-nsa325.dtb \
- kirkwood-openblocks_a6.dtb \
- kirkwood-openblocks_a7.dtb \
- kirkwood-openrd-base.dtb \
- kirkwood-openrd-client.dtb \
- kirkwood-openrd-ultimate.dtb \
- kirkwood-pogo_e02.dtb \
- kirkwood-pogoplug-series-4.dtb \
- kirkwood-rd88f6192.dtb \
- kirkwood-rd88f6281-z0.dtb \
- kirkwood-rd88f6281-a.dtb \
- kirkwood-rs212.dtb \
- kirkwood-rs409.dtb \
- kirkwood-rs411.dtb \
- kirkwood-sheevaplug.dtb \
- kirkwood-sheevaplug-esata.dtb \
- kirkwood-t5325.dtb \
- kirkwood-topkick.dtb \
- kirkwood-ts219-6281.dtb \
- kirkwood-ts219-6282.dtb \
- kirkwood-ts419-6281.dtb \
- kirkwood-ts419-6282.dtb
-dtb-$(CONFIG_ARCH_LPC18XX) += \
- lpc4337-ciaa.dtb \
- lpc4350-hitex-eval.dtb \
- lpc4357-ea4357-devkit.dtb \
- lpc4357-myd-lpc4357.dtb
-dtb-$(CONFIG_ARCH_LPC32XX) += \
- lpc3250-ea3250.dtb \
- lpc3250-phy3250.dtb
-dtb-$(CONFIG_ARCH_WPCM450) += \
- nuvoton-wpcm450-supermicro-x9sci-ln4f.dtb
-dtb-$(CONFIG_ARCH_NPCM7XX) += \
- nuvoton-npcm730-gsj.dtb \
- nuvoton-npcm730-gbs.dtb \
- nuvoton-npcm730-kudo.dtb \
- nuvoton-npcm750-evb.dtb \
- nuvoton-npcm750-runbmc-olympus.dtb
-dtb-$(CONFIG_MACH_MESON6) += \
- meson6-atv1200.dtb
-dtb-$(CONFIG_MACH_MESON8) += \
- meson8-minix-neo-x8.dtb \
- meson8b-ec100.dtb \
- meson8b-mxq.dtb \
- meson8b-odroidc1.dtb \
- meson8m2-mxiii-plus.dtb
-dtb-$(CONFIG_ARCH_MMP) += \
- pxa168-aspenite.dtb \
- pxa910-dkb.dtb \
- mmp2-brownstone.dtb \
- mmp2-olpc-xo-1-75.dtb \
- mmp3-dell-ariel.dtb
-dtb-$(CONFIG_ARCH_MPS2) += \
- mps2-an385.dtb \
- mps2-an399.dtb
-dtb-$(CONFIG_ARCH_MOXART) += \
- moxart-uc7112lx.dtb
-dtb-$(CONFIG_ARCH_SD5203) += \
- sd5203.dtb
-dtb-$(CONFIG_SOC_IMX1) += \
- imx1-ads.dtb \
- imx1-apf9328.dtb
-dtb-$(CONFIG_SOC_IMX25) += \
- imx25-eukrea-mbimxsd25-baseboard.dtb \
- imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dtb \
- imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dtb \
- imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dtb \
- imx25-karo-tx25.dtb \
- imx25-pdk.dtb
-dtb-$(CONFIG_SOC_IMX27) += \
- imx27-apf27.dtb \
- imx27-apf27dev.dtb \
- imx27-eukrea-mbimxsd27-baseboard.dtb \
- imx27-pdk.dtb \
- imx27-phytec-phycore-rdk.dtb \
- imx27-phytec-phycard-s-rdk.dtb
-dtb-$(CONFIG_SOC_IMX31) += \
- imx31-bug.dtb \
- imx31-lite.dtb
-dtb-$(CONFIG_SOC_IMX35) += \
- imx35-eukrea-mbimxsd35-baseboard.dtb \
- imx35-pdk.dtb
-dtb-$(CONFIG_SOC_IMX50) += \
- imx50-evk.dtb \
- imx50-kobo-aura.dtb
-dtb-$(CONFIG_SOC_IMX51) += \
- imx51-apf51.dtb \
- imx51-apf51dev.dtb \
- imx51-babbage.dtb \
- imx51-digi-connectcore-jsk.dtb \
- imx51-eukrea-mbimxsd51-baseboard.dtb \
- imx51-ts4800.dtb \
- imx51-zii-rdu1.dtb \
- imx51-zii-scu2-mezz.dtb \
- imx51-zii-scu3-esb.dtb
-dtb-$(CONFIG_SOC_IMX53) += \
- imx53-ard.dtb \
- imx53-cx9020.dtb \
- imx53-kp-ddc.dtb \
- imx53-kp-hsc.dtb \
- imx53-m53evk.dtb \
- imx53-m53menlo.dtb \
- imx53-mba53.dtb \
- imx53-ppd.dtb \
- imx53-qsb.dtb \
- imx53-qsrb.dtb \
- imx53-sk-imx53.dtb \
- imx53-smd.dtb \
- imx53-tx53-x03x.dtb \
- imx53-tx53-x13x.dtb \
- imx53-usbarmory.dtb \
- imx53-voipac-bsb.dtb
-dtb-$(CONFIG_SOC_IMX6Q) += \
- imx6dl-alti6p.dtb \
- imx6dl-apf6dev.dtb \
- imx6dl-aristainetos_4.dtb \
- imx6dl-aristainetos_7.dtb \
- imx6dl-aristainetos2_4.dtb \
- imx6dl-aristainetos2_7.dtb \
- imx6dl-colibri-aster.dtb \
- imx6dl-colibri-eval-v3.dtb \
- imx6dl-colibri-iris.dtb \
- imx6dl-colibri-iris-v2.dtb \
- imx6dl-cubox-i.dtb \
- imx6dl-cubox-i-emmc-som-v15.dtb \
- imx6dl-cubox-i-som-v15.dtb \
- imx6dl-dfi-fs700-m60.dtb \
- imx6dl-dhcom-picoitx.dtb \
- imx6dl-eckelmann-ci4x10.dtb \
- imx6dl-emcon-avari.dtb \
- imx6dl-gw51xx.dtb \
- imx6dl-gw52xx.dtb \
- imx6dl-gw53xx.dtb \
- imx6dl-gw54xx.dtb \
- imx6dl-gw551x.dtb \
- imx6dl-gw552x.dtb \
- imx6dl-gw553x.dtb \
- imx6dl-gw560x.dtb \
- imx6dl-gw5903.dtb \
- imx6dl-gw5904.dtb \
- imx6dl-gw5907.dtb \
- imx6dl-gw5910.dtb \
- imx6dl-gw5912.dtb \
- imx6dl-gw5913.dtb \
- imx6dl-hummingboard.dtb \
- imx6dl-hummingboard-emmc-som-v15.dtb \
- imx6dl-hummingboard-som-v15.dtb \
- imx6dl-hummingboard2.dtb \
- imx6dl-hummingboard2-emmc-som-v15.dtb \
- imx6dl-hummingboard2-som-v15.dtb \
- imx6dl-icore.dtb \
- imx6dl-icore-mipi.dtb \
- imx6dl-icore-rqs.dtb \
- imx6dl-lanmcu.dtb \
- imx6dl-mamoj.dtb \
- imx6dl-mba6a.dtb \
- imx6dl-mba6b.dtb \
- imx6dl-nit6xlite.dtb \
- imx6dl-nitrogen6x.dtb \
- imx6dl-phytec-mira-rdk-nand.dtb \
- imx6dl-phytec-pbab01.dtb \
- imx6dl-pico-dwarf.dtb \
- imx6dl-pico-hobbit.dtb \
- imx6dl-pico-nymph.dtb \
- imx6dl-pico-pi.dtb \
- imx6dl-plybas.dtb \
- imx6dl-plym2m.dtb \
- imx6dl-prtmvt.dtb \
- imx6dl-prtrvt.dtb \
- imx6dl-prtvt7.dtb \
- imx6dl-rex-basic.dtb \
- imx6dl-riotboard.dtb \
- imx6dl-sabreauto.dtb \
- imx6dl-sabrelite.dtb \
- imx6dl-sabresd.dtb \
- imx6dl-savageboard.dtb \
- imx6dl-skov-revc-lt2.dtb \
- imx6dl-skov-revc-lt6.dtb \
- imx6dl-solidsense.dtb \
- imx6dl-ts4900.dtb \
- imx6dl-ts7970.dtb \
- imx6dl-tx6dl-comtft.dtb \
- imx6dl-tx6s-8034.dtb \
- imx6dl-tx6s-8034-mb7.dtb \
- imx6dl-tx6s-8035.dtb \
- imx6dl-tx6s-8035-mb7.dtb \
- imx6dl-tx6u-801x.dtb \
- imx6dl-tx6u-80xx-mb7.dtb \
- imx6dl-tx6u-8033.dtb \
- imx6dl-tx6u-8033-mb7.dtb \
- imx6dl-tx6u-811x.dtb \
- imx6dl-tx6u-81xx-mb7.dtb \
- imx6dl-udoo.dtb \
- imx6dl-victgo.dtb \
- imx6dl-vicut1.dtb \
- imx6dl-wandboard.dtb \
- imx6dl-wandboard-revb1.dtb \
- imx6dl-wandboard-revd1.dtb \
- imx6dl-yapp4-draco.dtb \
- imx6dl-yapp4-hydra.dtb \
- imx6dl-yapp4-lynx.dtb \
- imx6dl-yapp4-orion.dtb \
- imx6dl-yapp4-phoenix.dtb \
- imx6dl-yapp4-ursa.dtb \
- imx6q-apalis-eval.dtb \
- imx6q-apalis-ixora.dtb \
- imx6q-apalis-ixora-v1.1.dtb \
- imx6q-apalis-ixora-v1.2.dtb \
- imx6q-apf6dev.dtb \
- imx6q-arm2.dtb \
- imx6q-b450v3.dtb \
- imx6q-b650v3.dtb \
- imx6q-b850v3.dtb \
- imx6q-bosch-acc.dtb \
- imx6q-cm-fx6.dtb \
- imx6q-cubox-i.dtb \
- imx6q-cubox-i-emmc-som-v15.dtb \
- imx6q-cubox-i-som-v15.dtb \
- imx6q-dfi-fs700-m60.dtb \
- imx6q-dhcom-pdk2.dtb \
- imx6q-display5-tianma-tm070-1280x768.dtb \
- imx6q-dmo-edmqmx6.dtb \
- imx6q-dms-ba16.dtb \
- imx6q-ds.dtb \
- imx6q-emcon-avari.dtb \
- imx6q-evi.dtb \
- imx6dl-b105pv2.dtb \
- imx6dl-b105v2.dtb \
- imx6dl-b125v2.dtb \
- imx6dl-b125pv2.dtb \
- imx6dl-b155v2.dtb \
- imx6q-gk802.dtb \
- imx6q-gw51xx.dtb \
- imx6q-gw52xx.dtb \
- imx6q-gw53xx.dtb \
- imx6q-gw5400-a.dtb \
- imx6q-gw54xx.dtb \
- imx6q-gw551x.dtb \
- imx6q-gw552x.dtb \
- imx6q-gw553x.dtb \
- imx6q-gw560x.dtb \
- imx6q-gw5903.dtb \
- imx6q-gw5904.dtb \
- imx6q-gw5907.dtb \
- imx6q-gw5910.dtb \
- imx6q-gw5912.dtb \
- imx6q-gw5913.dtb \
- imx6q-h100.dtb \
- imx6q-hummingboard.dtb \
- imx6q-hummingboard-emmc-som-v15.dtb \
- imx6q-hummingboard-som-v15.dtb \
- imx6q-hummingboard2.dtb \
- imx6q-hummingboard2-emmc-som-v15.dtb \
- imx6q-hummingboard2-som-v15.dtb \
- imx6q-icore.dtb \
- imx6q-icore-mipi.dtb \
- imx6q-icore-ofcap10.dtb \
- imx6q-icore-ofcap12.dtb \
- imx6q-icore-rqs.dtb \
- imx6q-kp-tpc.dtb \
- imx6q-logicpd.dtb \
- imx6q-marsboard.dtb \
- imx6q-mba6a.dtb \
- imx6q-mba6b.dtb \
- imx6q-mccmon6.dtb \
- imx6q-nitrogen6x.dtb \
- imx6q-nitrogen6_max.dtb \
- imx6q-nitrogen6_som2.dtb \
- imx6q-novena.dtb \
- imx6q-phytec-mira-rdk-emmc.dtb \
- imx6q-phytec-mira-rdk-nand.dtb \
- imx6q-phytec-pbab01.dtb \
- imx6q-pico-dwarf.dtb \
- imx6q-pico-hobbit.dtb \
- imx6q-pico-nymph.dtb \
- imx6q-pico-pi.dtb \
- imx6q-pistachio.dtb \
- imx6q-prti6q.dtb \
- imx6q-prtwd2.dtb \
- imx6q-rex-pro.dtb \
- imx6q-sabreauto.dtb \
- imx6q-sabrelite.dtb \
- imx6q-sabresd.dtb \
- imx6q-savageboard.dtb \
- imx6q-sbc6x.dtb \
- imx6q-skov-revc-lt2.dtb \
- imx6q-skov-revc-lt6.dtb \
- imx6q-skov-reve-mi1010ait-1cp1.dtb \
- imx6q-solidsense.dtb \
- imx6q-tbs2910.dtb \
- imx6q-ts4900.dtb \
- imx6q-ts7970.dtb \
- imx6q-tx6q-1010.dtb \
- imx6q-tx6q-1010-comtft.dtb \
- imx6q-tx6q-1020.dtb \
- imx6q-tx6q-1020-comtft.dtb \
- imx6q-tx6q-1036.dtb \
- imx6q-tx6q-1036-mb7.dtb \
- imx6q-tx6q-10x0-mb7.dtb \
- imx6q-tx6q-1110.dtb \
- imx6q-tx6q-11x0-mb7.dtb \
- imx6q-udoo.dtb \
- imx6q-utilite-pro.dtb \
- imx6q-var-dt6customboard.dtb \
- imx6q-vicut1.dtb \
- imx6q-wandboard.dtb \
- imx6q-wandboard-revb1.dtb \
- imx6q-wandboard-revd1.dtb \
- imx6q-yapp4-crux.dtb \
- imx6q-yapp4-pegasus.dtb \
- imx6q-zii-rdu2.dtb \
- imx6qp-mba6b.dtb \
- imx6qp-nitrogen6_max.dtb \
- imx6qp-nitrogen6_som2.dtb \
- imx6qp-phytec-mira-rdk-nand.dtb \
- imx6qp-prtwd3.dtb \
- imx6qp-sabreauto.dtb \
- imx6qp-sabresd.dtb \
- imx6qp-tx6qp-8037.dtb \
- imx6qp-tx6qp-8037-mb7.dtb \
- imx6qp-tx6qp-8137.dtb \
- imx6qp-tx6qp-8137-mb7.dtb \
- imx6qp-vicutp.dtb \
- imx6qp-wandboard-revd1.dtb \
- imx6qp-yapp4-crux-plus.dtb \
- imx6qp-yapp4-pegasus-plus.dtb \
- imx6qp-zii-rdu2.dtb \
- imx6s-dhcom-drc02.dtb
-dtb-$(CONFIG_SOC_IMX6SL) += \
- imx6sl-evk.dtb \
- imx6sl-kobo-aura2.dtb \
- imx6sl-tolino-shine2hd.dtb \
- imx6sl-tolino-shine3.dtb \
- imx6sl-tolino-vision.dtb \
- imx6sl-tolino-vision5.dtb \
- imx6sl-warp.dtb
-dtb-$(CONFIG_SOC_IMX6SLL) += \
- imx6sll-evk.dtb \
- imx6sll-kobo-clarahd.dtb \
- imx6sll-kobo-librah2o.dtb
-dtb-$(CONFIG_SOC_IMX6SX) += \
- imx6sx-nitrogen6sx.dtb \
- imx6sx-sabreauto.dtb \
- imx6sx-sdb-reva.dtb \
- imx6sx-sdb-sai.dtb \
- imx6sx-sdb.dtb \
- imx6sx-sdb-mqs.dtb \
- imx6sx-softing-vining-2000.dtb \
- imx6sx-udoo-neo-basic.dtb \
- imx6sx-udoo-neo-extended.dtb \
- imx6sx-udoo-neo-full.dtb
-dtb-$(CONFIG_SOC_IMX6UL) += \
- imx6ul-14x14-evk.dtb \
- imx6ul-ccimx6ulsbcexpress.dtb \
- imx6ul-ccimx6ulsbcpro.dtb \
- imx6ul-geam.dtb \
- imx6ul-isiot-emmc.dtb \
- imx6ul-isiot-nand.dtb \
- imx6ul-kontron-bl.dtb \
- imx6ul-kontron-bl-43.dtb \
- imx6ul-liteboard.dtb \
- imx6ul-tqma6ul1-mba6ulx.dtb \
- imx6ul-tqma6ul2-mba6ulx.dtb \
- imx6ul-tqma6ul2l-mba6ulx.dtb \
- imx6ul-opos6uldev.dtb \
- imx6ul-pico-dwarf.dtb \
- imx6ul-pico-hobbit.dtb \
- imx6ul-pico-pi.dtb \
- imx6ul-phytec-segin-ff-rdk-emmc.dtb \
- imx6ul-phytec-segin-ff-rdk-nand.dtb \
- imx6ul-prti6g.dtb \
- imx6ul-tx6ul-0010.dtb \
- imx6ul-tx6ul-0011.dtb \
- imx6ul-tx6ul-mainboard.dtb \
- imx6ull-14x14-evk.dtb \
- imx6ull-colibri-aster.dtb \
- imx6ull-colibri-emmc-aster.dtb \
- imx6ull-colibri-emmc-eval-v3.dtb \
- imx6ull-colibri-emmc-iris.dtb \
- imx6ull-colibri-emmc-iris-v2.dtb \
- imx6ull-colibri-eval-v3.dtb \
- imx6ull-colibri-iris.dtb \
- imx6ull-colibri-iris-v2.dtb \
- imx6ull-colibri-wifi-aster.dtb \
- imx6ull-colibri-wifi-eval-v3.dtb \
- imx6ull-colibri-wifi-iris.dtb \
- imx6ull-colibri-wifi-iris-v2.dtb \
- imx6ull-dhcom-drc02.dtb \
- imx6ull-dhcom-pdk2.dtb \
- imx6ull-dhcom-picoitx.dtb \
- imx6ull-jozacp.dtb \
- imx6ull-kontron-bl.dtb \
- imx6ull-myir-mys-6ulx-eval.dtb \
- imx6ull-opos6uldev.dtb \
- imx6ull-phytec-segin-ff-rdk-nand.dtb \
- imx6ull-phytec-segin-ff-rdk-emmc.dtb \
- imx6ull-phytec-segin-lc-rdk-nand.dtb \
- imx6ull-phytec-tauri-emmc.dtb \
- imx6ull-phytec-tauri-nand.dtb \
- imx6ull-tarragon-master.dtb \
- imx6ull-tarragon-micro.dtb \
- imx6ull-tarragon-slave.dtb \
- imx6ull-tarragon-slavext.dtb \
- imx6ull-tqma6ull2-mba6ulx.dtb \
- imx6ull-tqma6ull2l-mba6ulx.dtb \
- imx6ulz-14x14-evk.dtb \
- imx6ulz-bsh-smm-m2.dtb
-dtb-$(CONFIG_SOC_IMX7D) += \
- imx7d-cl-som-imx7.dtb \
- imx7d-colibri-aster.dtb \
- imx7d-colibri-emmc-aster.dtb \
- imx7d-colibri-emmc-iris.dtb \
- imx7d-colibri-emmc-iris-v2.dtb \
- imx7d-colibri-emmc-eval-v3.dtb \
- imx7d-colibri-eval-v3.dtb \
- imx7d-colibri-iris.dtb \
- imx7d-colibri-iris-v2.dtb \
- imx7d-flex-concentrator.dtb \
- imx7d-flex-concentrator-mfg.dtb \
- imx7d-mba7.dtb \
- imx7d-meerkat96.dtb \
- imx7d-nitrogen7.dtb \
- imx7d-pico-dwarf.dtb \
- imx7d-pico-hobbit.dtb \
- imx7d-pico-nymph.dtb \
- imx7d-pico-pi.dtb \
- imx7d-remarkable2.dtb \
- imx7d-sbc-imx7.dtb \
- imx7d-sdb.dtb \
- imx7d-sdb-reva.dtb \
- imx7d-sdb-sht11.dtb \
- imx7d-smegw01.dtb \
- imx7d-zii-rmu2.dtb \
- imx7d-zii-rpu2.dtb \
- imx7s-colibri-aster.dtb \
- imx7s-colibri-eval-v3.dtb \
- imx7s-colibri-iris.dtb \
- imx7s-colibri-iris-v2.dtb \
- imx7s-mba7.dtb \
- imx7s-warp.dtb
-dtb-$(CONFIG_SOC_IMX7ULP) += \
- imx7ulp-com.dtb \
- imx7ulp-evk.dtb
-dtb-$(CONFIG_SOC_IMXRT) += \
- imxrt1050-evk.dtb
-dtb-$(CONFIG_SOC_LAN966) += \
- lan966x-kontron-kswitch-d10-mmt-6g-2gs.dtb \
- lan966x-kontron-kswitch-d10-mmt-8g.dtb \
- lan966x-pcb8290.dtb \
- lan966x-pcb8291.dtb \
- lan966x-pcb8309.dtb
-dtb-$(CONFIG_SOC_LS1021A) += \
- ls1021a-iot.dtb \
- ls1021a-moxa-uc-8410a.dtb \
- ls1021a-qds.dtb \
- ls1021a-tsn.dtb \
- ls1021a-twr.dtb
-dtb-$(CONFIG_SOC_VF610) += \
- vf500-colibri-eval-v3.dtb \
- vf610-bk4.dtb \
- vf610-colibri-eval-v3.dtb \
- vf610m4-colibri.dtb \
- vf610-cosmic.dtb \
- vf610m4-cosmic.dtb \
- vf610-twr.dtb \
- vf610-zii-cfu1.dtb \
- vf610-zii-dev-rev-b.dtb \
- vf610-zii-dev-rev-c.dtb \
- vf610-zii-scu4-aib.dtb \
- vf610-zii-spb4.dtb \
- vf610-zii-ssmb-dtu.dtb \
- vf610-zii-ssmb-spu3.dtb
-dtb-$(CONFIG_ARCH_MXS) += \
- imx23-evk.dtb \
- imx23-olinuxino.dtb \
- imx23-sansa.dtb \
- imx23-stmp378x_devb.dtb \
- imx23-xfi3.dtb \
- imx28-apf28.dtb \
- imx28-apf28dev.dtb \
- imx28-apx4devkit.dtb \
- imx28-cfa10036.dtb \
- imx28-cfa10037.dtb \
- imx28-cfa10049.dtb \
- imx28-cfa10055.dtb \
- imx28-cfa10056.dtb \
- imx28-cfa10057.dtb \
- imx28-cfa10058.dtb \
- imx28-duckbill-2-485.dtb \
- imx28-duckbill-2.dtb \
- imx28-duckbill-2-enocean.dtb \
- imx28-duckbill-2-spi.dtb \
- imx28-duckbill.dtb \
- imx28-eukrea-mbmx283lc.dtb \
- imx28-eukrea-mbmx287lc.dtb \
- imx28-evk.dtb \
- imx28-m28cu3.dtb \
- imx28-m28evk.dtb \
- imx28-sps1.dtb \
- imx28-ts4600.dtb \
- imx28-tx28.dtb \
- imx28-xea.dtb
-dtb-$(CONFIG_ARCH_NOMADIK) += \
- ste-nomadik-s8815.dtb \
- ste-nomadik-nhk15.dtb
-dtb-$(CONFIG_ARCH_NSPIRE) += \
- nspire-cx.dtb \
- nspire-tp.dtb \
- nspire-clp.dtb
-dtb-$(CONFIG_ARCH_OMAP2) += \
- omap2420-h4.dtb \
- omap2420-n800.dtb \
- omap2420-n810.dtb \
- omap2420-n810-wimax.dtb \
- omap2430-sdp.dtb
-dtb-$(CONFIG_ARCH_OMAP3) += \
- am3517-craneboard.dtb \
- am3517-evm.dtb \
- am3517_mt_ventoux.dtb \
- logicpd-torpedo-37xx-devkit.dtb \
- logicpd-som-lv-37xx-devkit.dtb \
- omap3430-sdp.dtb \
- omap3-beagle.dtb \
- omap3-beagle-ab4.dtb \
- omap3-beagle-xm.dtb \
- omap3-beagle-xm-ab.dtb \
- omap3-cm-t3517.dtb \
- omap3-cm-t3530.dtb \
- omap3-cm-t3730.dtb \
- omap3-devkit8000.dtb \
- omap3-devkit8000-lcd43.dtb \
- omap3-devkit8000-lcd70.dtb \
- omap3-echo.dtb \
- omap3-evm.dtb \
- omap3-evm-37xx.dtb \
- omap3-gta04a3.dtb \
- omap3-gta04a4.dtb \
- omap3-gta04a5.dtb \
- omap3-gta04a5one.dtb \
- omap3-ha.dtb \
- omap3-ha-lcd.dtb \
- omap3-igep0020.dtb \
- omap3-igep0020-rev-f.dtb \
- omap3-igep0030.dtb \
- omap3-igep0030-rev-g.dtb \
- omap3-ldp.dtb \
- omap3-lilly-dbb056.dtb \
- omap3-n900.dtb \
- omap3-n9.dtb \
- omap3-n950.dtb \
- omap3-overo-alto35.dtb \
- omap3-overo-chestnut43.dtb \
- omap3-overo-gallop43.dtb \
- omap3-overo-palo35.dtb \
- omap3-overo-palo43.dtb \
- omap3-overo-storm-alto35.dtb \
- omap3-overo-storm-chestnut43.dtb \
- omap3-overo-storm-gallop43.dtb \
- omap3-overo-storm-palo35.dtb \
- omap3-overo-storm-palo43.dtb \
- omap3-overo-storm-summit.dtb \
- omap3-overo-storm-tobi.dtb \
- omap3-overo-storm-tobiduo.dtb \
- omap3-overo-summit.dtb \
- omap3-overo-tobi.dtb \
- omap3-overo-tobiduo.dtb \
- omap3-pandora-600mhz.dtb \
- omap3-pandora-1ghz.dtb \
- omap3-sbc-t3517.dtb \
- omap3-sbc-t3530.dtb \
- omap3-sbc-t3730.dtb \
- omap3-sniper.dtb \
- omap3-thunder.dtb \
- omap3-zoom3.dtb
-dtb-$(CONFIG_SOC_TI81XX) += \
- am3874-iceboard.dtb \
- dm8148-evm.dtb \
- dm8148-t410.dtb \
- dm8168-evm.dtb \
- dra62x-j5eco-evm.dtb
-dtb-$(CONFIG_SOC_AM33XX) += \
- am335x-baltos-ir2110.dtb \
- am335x-baltos-ir3220.dtb \
- am335x-baltos-ir5221.dtb \
- am335x-base0033.dtb \
- am335x-bone.dtb \
- am335x-boneblack.dtb \
- am335x-boneblack-wireless.dtb \
- am335x-boneblue.dtb \
- am335x-bonegreen.dtb \
- am335x-bonegreen-wireless.dtb \
- am335x-chiliboard.dtb \
- am335x-cm-t335.dtb \
- am335x-evm.dtb \
- am335x-evmsk.dtb \
- am335x-guardian.dtb \
- am335x-icev2.dtb \
- am335x-lxm.dtb \
- am335x-moxa-uc-2101.dtb \
- am335x-moxa-uc-8100-me-t.dtb \
- am335x-myirtech-myd.dtb \
- am335x-nano.dtb \
- am335x-netcan-plus-1xx.dtb \
- am335x-netcom-plus-2xx.dtb \
- am335x-netcom-plus-8xx.dtb \
- am335x-pdu001.dtb \
- am335x-pepper.dtb \
- am335x-phycore-rdk.dtb \
- am335x-pocketbeagle.dtb \
- am335x-regor-rdk.dtb \
- am335x-sancloud-bbe.dtb \
- am335x-sancloud-bbe-lite.dtb \
- am335x-sancloud-bbe-extended-wifi.dtb \
- am335x-shc.dtb \
- am335x-sbc-t335.dtb \
- am335x-sl50.dtb \
- am335x-wega-rdk.dtb \
- am335x-osd3358-sm-red.dtb
-dtb-$(CONFIG_ARCH_OMAP4) += \
- omap4-droid-bionic-xt875.dtb \
- omap4-droid4-xt894.dtb \
- omap4-duovero-parlor.dtb \
- omap4-kc1.dtb \
- omap4-panda.dtb \
- omap4-panda-a4.dtb \
- omap4-panda-es.dtb \
- omap4-sdp.dtb \
- omap4-sdp-es23plus.dtb \
- omap4-var-dvk-om44.dtb \
- omap4-var-stk-om44.dtb
-dtb-$(CONFIG_SOC_AM43XX) += \
- am43x-epos-evm.dtb \
- am437x-cm-t43.dtb \
- am437x-gp-evm.dtb \
- am437x-idk-evm.dtb \
- am437x-sbc-t43.dtb \
- am437x-sk-evm.dtb
-dtb-$(CONFIG_SOC_OMAP5) += \
- omap5-cm-t54.dtb \
- omap5-igep0050.dtb \
- omap5-sbc-t54.dtb \
- omap5-uevm.dtb
-am57xx-evm-dtbs := am57xx-beagle-x15.dtb am57xx-evm.dtbo
-am57xx-evm-reva3-dtbs := am57xx-beagle-x15-revc.dtb am57xx-evm.dtbo
-dtb-$(CONFIG_SOC_DRA7XX) += \
- am57xx-beagle-x15.dtb \
- am57xx-beagle-x15-revb1.dtb \
- am57xx-beagle-x15-revc.dtb \
- am57xx-evm.dtb \
- am57xx-evm-reva3.dtb \
- am5729-beagleboneai.dtb \
- am57xx-cl-som-am57x.dtb \
- am57xx-sbc-am57x.dtb \
- am572x-idk.dtb \
- am572x-idk-touchscreen.dtbo \
- am571x-idk.dtb \
- am571x-idk-touchscreen.dtbo \
- am574x-idk.dtb \
- am57xx-idk-lcd-osd101t2045.dtbo \
- am57xx-idk-lcd-osd101t2587.dtbo \
- dra7-evm.dtb \
- dra72-evm.dtb \
- dra72-evm-revc.dtb \
- dra71-evm.dtb \
- dra76-evm.dtb
-dtb-$(CONFIG_ARCH_ORION5X) += \
- orion5x-kuroboxpro.dtb \
- orion5x-lacie-d2-network.dtb \
- orion5x-lacie-ethernet-disk-mini-v2.dtb \
- orion5x-linkstation-lsgl.dtb \
- orion5x-linkstation-lswtgl.dtb \
- orion5x-linkstation-lschl.dtb \
- orion5x-lswsgl.dtb \
- orion5x-maxtor-shared-storage-2.dtb \
- orion5x-netgear-wnr854t.dtb \
- orion5x-rd88f5182-nas.dtb
-dtb-$(CONFIG_ARCH_ACTIONS) += \
- owl-s500-cubieboard6.dtb \
- owl-s500-guitar-bb-rev-b.dtb \
- owl-s500-labrador-base-m.dtb \
- owl-s500-roseapplepi.dtb \
- owl-s500-sparky.dtb
-dtb-$(CONFIG_ARCH_PXA) += \
- pxa300-raumfeld-connector.dtb \
- pxa300-raumfeld-controller.dtb \
- pxa300-raumfeld-speaker-l.dtb \
- pxa300-raumfeld-speaker-m.dtb \
- pxa300-raumfeld-speaker-one.dtb \
- pxa300-raumfeld-speaker-s.dtb
-dtb-$(CONFIG_ARCH_QCOM) += \
- qcom-apq8016-sbc.dtb \
- qcom-apq8026-asus-sparrow.dtb \
- qcom-apq8026-huawei-sturgeon.dtb \
- qcom-apq8026-lg-lenok.dtb \
- qcom-apq8026-samsung-matisse-wifi.dtb \
- qcom-apq8060-dragonboard.dtb \
- qcom-apq8064-cm-qs600.dtb \
- qcom-apq8064-ifc6410.dtb \
- qcom-apq8064-sony-xperia-lagan-yuga.dtb \
- qcom-apq8064-asus-nexus7-flo.dtb \
- qcom-apq8074-dragonboard.dtb \
- qcom-apq8084-ifc6540.dtb \
- qcom-apq8084-mtp.dtb \
- qcom-ipq4018-ap120c-ac.dtb \
- qcom-ipq4018-ap120c-ac-bit.dtb \
- qcom-ipq4018-jalapeno.dtb \
- qcom-ipq4019-ap.dk01.1-c1.dtb \
- qcom-ipq4019-ap.dk04.1-c1.dtb \
- qcom-ipq4019-ap.dk04.1-c3.dtb \
- qcom-ipq4019-ap.dk07.1-c1.dtb \
- qcom-ipq4019-ap.dk07.1-c2.dtb \
- qcom-ipq8064-ap148.dtb \
- qcom-ipq8064-rb3011.dtb \
- qcom-msm8226-samsung-s3ve3g.dtb \
- qcom-msm8660-surf.dtb \
- qcom-msm8916-samsung-e5.dtb \
- qcom-msm8916-samsung-e7.dtb \
- qcom-msm8916-samsung-grandmax.dtb \
- qcom-msm8916-samsung-serranove.dtb \
- qcom-msm8960-cdp.dtb \
- qcom-msm8974-lge-nexus5-hammerhead.dtb \
- qcom-msm8974-sony-xperia-rhine-amami.dtb \
- qcom-msm8974-sony-xperia-rhine-honami.dtb \
- qcom-msm8974pro-fairphone-fp2.dtb \
- qcom-msm8974pro-oneplus-bacon.dtb \
- qcom-msm8974pro-samsung-klte.dtb \
- qcom-msm8974pro-sony-xperia-shinano-castor.dtb \
- qcom-mdm9615-wp8548-mangoh-green.dtb \
- qcom-sdx55-mtp.dtb \
- qcom-sdx55-t55.dtb \
- qcom-sdx55-telit-fn980-tlb.dtb \
- qcom-sdx65-mtp.dtb
-dtb-$(CONFIG_ARCH_RDA) += \
- rda8810pl-orangepi-2g-iot.dtb \
- rda8810pl-orangepi-i96.dtb
-dtb-$(CONFIG_ARCH_REALTEK) += \
- rtd1195-horseradish.dtb \
- rtd1195-mele-x1000.dtb
-dtb-$(CONFIG_ARCH_REALVIEW) += \
- arm-realview-pb1176.dtb \
- arm-realview-pb11mp.dtb \
- arm-realview-eb.dtb \
- arm-realview-eb-bbrevd.dtb \
- arm-realview-eb-11mp.dtb \
- arm-realview-eb-11mp-bbrevd.dtb \
- arm-realview-eb-11mp-ctrevb.dtb \
- arm-realview-eb-11mp-bbrevd-ctrevb.dtb \
- arm-realview-eb-a9mp.dtb \
- arm-realview-eb-a9mp-bbrevd.dtb \
- arm-realview-pba8.dtb \
- arm-realview-pbx-a9.dtb
-dtb-$(CONFIG_ARCH_RENESAS) += \
- emev2-kzm9d.dtb \
- r7s72100-genmai.dtb \
- r7s72100-gr-peach.dtb \
- r7s72100-rskrza1.dtb \
- r7s9210-rza2mevb.dtb \
- r8a73a4-ape6evm.dtb \
- r8a7740-armadillo800eva.dtb \
- r8a7742-iwg21d-q7.dtb \
- r8a7742-iwg21d-q7-dbcm-ca.dtb \
- r8a7743-iwg20d-q7.dtb \
- r8a7743-iwg20d-q7-dbcm-ca.dtb \
- r8a7743-sk-rzg1m.dtb \
- r8a7744-iwg20d-q7.dtb \
- r8a7744-iwg20d-q7-dbcm-ca.dtb \
- r8a7745-iwg22d-sodimm.dtb \
- r8a7745-iwg22d-sodimm-dbhd-ca.dtb \
- r8a7745-sk-rzg1e.dtb \
- r8a77470-iwg23s-sbc.dtb \
- r8a7778-bockw.dtb \
- r8a7779-marzen.dtb \
- r8a7790-lager.dtb \
- r8a7790-stout.dtb \
- r8a7791-koelsch.dtb \
- r8a7791-porter.dtb \
- r8a7792-blanche.dtb \
- r8a7792-wheat.dtb \
- r8a7793-gose.dtb \
- r8a7794-alt.dtb \
- r8a7794-silk.dtb \
- r9a06g032-rzn1d400-db.dtb \
- sh73a0-kzm9g.dtb
-dtb-$(CONFIG_ARCH_ROCKCHIP) += \
- rv1108-elgin-r1.dtb \
- rv1108-evb.dtb \
- rv1126-edgeble-neu2-io.dtb \
- rk3036-evb.dtb \
- rk3036-kylin.dtb \
- rk3066a-bqcurie2.dtb \
- rk3066a-marsboard.dtb \
- rk3066a-mk808.dtb \
- rk3066a-rayeager.dtb \
- rk3128-evb.dtb \
- rk3188-bqedison2qc.dtb \
- rk3188-px3-evb.dtb \
- rk3188-radxarock.dtb \
- rk3228-evb.dtb \
- rk3229-evb.dtb \
- rk3229-xms6.dtb \
- rk3288-evb-act8846.dtb \
- rk3288-evb-rk808.dtb \
- rk3288-firefly-beta.dtb \
- rk3288-firefly.dtb \
- rk3288-firefly-reload.dtb \
- rk3288-miqi.dtb \
- rk3288-phycore-rdk.dtb \
- rk3288-popmetal.dtb \
- rk3288-r89.dtb \
- rk3288-rock2-square.dtb \
- rk3288-rock-pi-n8.dtb \
- rk3288-tinker.dtb \
- rk3288-tinker-s.dtb \
- rk3288-veyron-brain.dtb \
- rk3288-veyron-fievel.dtb \
- rk3288-veyron-jaq.dtb \
- rk3288-veyron-jerry.dtb \
- rk3288-veyron-mickey.dtb \
- rk3288-veyron-mighty.dtb \
- rk3288-veyron-minnie.dtb \
- rk3288-veyron-pinky.dtb \
- rk3288-veyron-speedy.dtb \
- rk3288-veyron-tiger.dtb \
- rk3288-vyasa.dtb
-dtb-$(CONFIG_ARCH_S3C64XX) += \
- s3c6410-mini6410.dtb \
- s3c6410-smdk6410.dtb
-dtb-$(CONFIG_ARCH_S5PV210) += \
- s5pv210-aquila.dtb \
- s5pv210-fascinate4g.dtb \
- s5pv210-galaxys.dtb \
- s5pv210-goni.dtb \
- s5pv210-smdkc110.dtb \
- s5pv210-smdkv210.dtb \
- s5pv210-torbreck.dtb
-dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += \
- socfpga_arria5_socdk.dtb \
- socfpga_arria10_chameleonv3.dtb \
- socfpga_arria10_mercury_pe1.dtb \
- socfpga_arria10_socdk_nand.dtb \
- socfpga_arria10_socdk_qspi.dtb \
- socfpga_arria10_socdk_sdmmc.dtb \
- socfpga_cyclone5_chameleon96.dtb \
- socfpga_cyclone5_mcvevk.dtb \
- socfpga_cyclone5_socdk.dtb \
- socfpga_cyclone5_de0_nano_soc.dtb \
- socfpga_cyclone5_sockit.dtb \
- socfpga_cyclone5_socrates.dtb \
- socfpga_cyclone5_sodia.dtb \
- socfpga_cyclone5_vining_fpga.dtb \
- socfpga_vt.dtb
-dtb-$(CONFIG_ARCH_SPEAR13XX) += \
- spear1310-evb.dtb \
- spear1340-evb.dtb
-dtb-$(CONFIG_ARCH_SPEAR3XX) += \
- spear300-evb.dtb \
- spear310-evb.dtb \
- spear320-evb.dtb \
- spear320-hmi.dtb
-dtb-$(CONFIG_ARCH_SPEAR6XX) += \
- spear600-evb.dtb
-dtb-$(CONFIG_ARCH_STI) += \
- stih407-b2120.dtb \
- stih410-b2120.dtb \
- stih410-b2260.dtb \
- stih418-b2199.dtb \
- stih418-b2264.dtb
-dtb-$(CONFIG_ARCH_STM32) += \
- stm32f429-disco.dtb \
- stm32f469-disco.dtb \
- stm32f746-disco.dtb \
- stm32f769-disco.dtb \
- stm32429i-eval.dtb \
- stm32746g-eval.dtb \
- stm32h743i-eval.dtb \
- stm32h743i-disco.dtb \
- stm32h750i-art-pi.dtb \
- stm32mp135f-dk.dtb \
- stm32mp151a-prtt1a.dtb \
- stm32mp151a-prtt1c.dtb \
- stm32mp151a-prtt1s.dtb \
- stm32mp151a-dhcor-testbench.dtb \
- stm32mp153c-dhcom-drc02.dtb \
- stm32mp153c-dhcor-drc-compact.dtb \
- stm32mp157a-avenger96.dtb \
- stm32mp157a-dhcor-avenger96.dtb \
- stm32mp157a-dk1.dtb \
- stm32mp157a-dk1-scmi.dtb \
- stm32mp157a-iot-box.dtb \
- stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \
- stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb \
- stm32mp157a-icore-stm32mp1-ctouch2.dtb \
- stm32mp157a-icore-stm32mp1-ctouch2-of10.dtb \
- stm32mp157a-icore-stm32mp1-edimm2.2.dtb \
- stm32mp157a-stinger96.dtb \
- stm32mp157c-dhcom-pdk2.dtb \
- stm32mp157c-dhcom-picoitx.dtb \
- stm32mp157c-dk2.dtb \
- stm32mp157c-dk2-scmi.dtb \
- stm32mp157c-ed1.dtb \
- stm32mp157c-ed1-scmi.dtb \
- stm32mp157c-emsbc-argon.dtb \
- stm32mp157c-ev1.dtb \
- stm32mp157c-ev1-scmi.dtb \
- stm32mp157c-lxa-mc1.dtb \
- stm32mp157c-odyssey.dtb
-dtb-$(CONFIG_MACH_SUN4I) += \
- sun4i-a10-a1000.dtb \
- sun4i-a10-ba10-tvbox.dtb \
- sun4i-a10-chuwi-v7-cw0825.dtb \
- sun4i-a10-cubieboard.dtb \
- sun4i-a10-dserve-dsrv9703c.dtb \
- sun4i-a10-gemei-g9.dtb \
- sun4i-a10-hackberry.dtb \
- sun4i-a10-hyundai-a7hd.dtb \
- sun4i-a10-inet1.dtb \
- sun4i-a10-inet97fv2.dtb \
- sun4i-a10-inet9f-rev03.dtb \
- sun4i-a10-itead-iteaduino-plus.dtb \
- sun4i-a10-jesurun-q5.dtb \
- sun4i-a10-marsboard.dtb \
- sun4i-a10-mini-xplus.dtb \
- sun4i-a10-mk802.dtb \
- sun4i-a10-mk802ii.dtb \
- sun4i-a10-olinuxino-lime.dtb \
- sun4i-a10-pcduino.dtb \
- sun4i-a10-pcduino2.dtb \
- sun4i-a10-pov-protab2-ips9.dtb \
- sun4i-a10-topwise-a721.dtb
-dtb-$(CONFIG_MACH_SUN5I) += \
- sun5i-a10s-auxtek-t003.dtb \
- sun5i-a10s-auxtek-t004.dtb \
- sun5i-a10s-mk802.dtb \
- sun5i-a10s-olinuxino-micro.dtb \
- sun5i-a10s-r7-tv-dongle.dtb \
- sun5i-a10s-wobo-i5.dtb \
- sun5i-a13-difrnce-dit4350.dtb \
- sun5i-a13-empire-electronix-d709.dtb \
- sun5i-a13-empire-electronix-m712.dtb \
- sun5i-a13-hsg-h702.dtb \
- sun5i-a13-inet-98v-rev2.dtb \
- sun5i-a13-licheepi-one.dtb \
- sun5i-a13-olinuxino.dtb \
- sun5i-a13-olinuxino-micro.dtb \
- sun5i-a13-pocketbook-touch-lux-3.dtb \
- sun5i-a13-q8-tablet.dtb \
- sun5i-a13-utoo-p66.dtb \
- sun5i-gr8-chip-pro.dtb \
- sun5i-gr8-evb.dtb \
- sun5i-r8-chip.dtb
-dtb-$(CONFIG_MACH_SUN6I) += \
- sun6i-a31-app4-evb1.dtb \
- sun6i-a31-colombus.dtb \
- sun6i-a31-hummingbird.dtb \
- sun6i-a31-i7.dtb \
- sun6i-a31-m9.dtb \
- sun6i-a31-mele-a1000g-quad.dtb \
- sun6i-a31s-colorfly-e708-q1.dtb \
- sun6i-a31s-cs908.dtb \
- sun6i-a31s-inet-q972.dtb \
- sun6i-a31s-primo81.dtb \
- sun6i-a31s-sina31s.dtb \
- sun6i-a31s-sinovoip-bpi-m2.dtb \
- sun6i-a31s-yones-toptech-bs1078-v2.dtb
-dtb-$(CONFIG_MACH_SUN7I) += \
- sun7i-a20-bananapi.dtb \
- sun7i-a20-bananapi-m1-plus.dtb \
- sun7i-a20-bananapro.dtb \
- sun7i-a20-cubieboard2.dtb \
- sun7i-a20-cubietruck.dtb \
- sun7i-a20-haoyu-marsboard.dtb \
- sun7i-a20-hummingbird.dtb \
- sun7i-a20-itead-ibox.dtb \
- sun7i-a20-i12-tvbox.dtb \
- sun7i-a20-icnova-swac.dtb \
- sun7i-a20-lamobo-r1.dtb \
- sun7i-a20-linutronix-testbox-v2.dtb \
- sun7i-a20-m3.dtb \
- sun7i-a20-mk808c.dtb \
- sun7i-a20-olimex-som-evb.dtb \
- sun7i-a20-olimex-som-evb-emmc.dtb \
- sun7i-a20-olimex-som204-evb.dtb \
- sun7i-a20-olimex-som204-evb-emmc.dtb \
- sun7i-a20-olinuxino-lime.dtb \
- sun7i-a20-olinuxino-lime-emmc.dtb \
- sun7i-a20-olinuxino-lime2.dtb \
- sun7i-a20-olinuxino-lime2-emmc.dtb \
- sun7i-a20-olinuxino-micro.dtb \
- sun7i-a20-olinuxino-micro-emmc.dtb \
- sun7i-a20-orangepi.dtb \
- sun7i-a20-orangepi-mini.dtb \
- sun7i-a20-pcduino3.dtb \
- sun7i-a20-pcduino3-nano.dtb \
- sun7i-a20-wexler-tab7200.dtb \
- sun7i-a20-wits-pro-a20-dkt.dtb
-dtb-$(CONFIG_MACH_SUN8I) += \
- sun8i-a23-evb.dtb \
- sun8i-a23-gt90h-v4.dtb \
- sun8i-a23-inet86dz.dtb \
- sun8i-a23-ippo-q8h-v5.dtb \
- sun8i-a23-ippo-q8h-v1.2.dtb \
- sun8i-a23-polaroid-mid2407pxe03.dtb \
- sun8i-a23-polaroid-mid2809pxe04.dtb \
- sun8i-a23-q8-tablet.dtb \
- sun8i-a33-et-q8-v1.6.dtb \
- sun8i-a33-ga10h-v1.1.dtb \
- sun8i-a33-inet-d978-rev2.dtb \
- sun8i-a33-ippo-q8h-v1.2.dtb \
- sun8i-a33-olinuxino.dtb \
- sun8i-a33-q8-tablet.dtb \
- sun8i-a33-sinlinx-sina33.dtb \
- sun8i-a83t-allwinner-h8homlet-v2.dtb \
- sun8i-a83t-bananapi-m3.dtb \
- sun8i-a83t-cubietruck-plus.dtb \
- sun8i-a83t-tbs-a711.dtb \
- sun8i-h2-plus-bananapi-m2-zero.dtb \
- sun8i-h2-plus-libretech-all-h3-cc.dtb \
- sun8i-h2-plus-orangepi-r1.dtb \
- sun8i-h2-plus-orangepi-zero.dtb \
- sun8i-h3-bananapi-m2-plus.dtb \
- sun8i-h3-bananapi-m2-plus-v1.2.dtb \
- sun8i-h3-beelink-x2.dtb \
- sun8i-h3-libretech-all-h3-cc.dtb \
- sun8i-h3-mapleboard-mp130.dtb \
- sun8i-h3-nanopi-duo2.dtb \
- sun8i-h3-nanopi-m1.dtb \
- sun8i-h3-nanopi-m1-plus.dtb \
- sun8i-h3-nanopi-neo.dtb \
- sun8i-h3-nanopi-neo-air.dtb \
- sun8i-h3-nanopi-r1.dtb \
- sun8i-h3-orangepi-2.dtb \
- sun8i-h3-orangepi-lite.dtb \
- sun8i-h3-orangepi-one.dtb \
- sun8i-h3-orangepi-pc.dtb \
- sun8i-h3-orangepi-pc-plus.dtb \
- sun8i-h3-orangepi-plus.dtb \
- sun8i-h3-orangepi-plus2e.dtb \
- sun8i-h3-orangepi-zero-plus2.dtb \
- sun8i-h3-rervision-dvk.dtb \
- sun8i-h3-zeropi.dtb \
- sun8i-h3-emlid-neutis-n5h3-devboard.dtb \
- sun8i-r16-bananapi-m2m.dtb \
- sun8i-r16-nintendo-nes-classic.dtb \
- sun8i-r16-nintendo-super-nes-classic.dtb \
- sun8i-r16-parrot.dtb \
- sun8i-r40-bananapi-m2-ultra.dtb \
- sun8i-r40-oka40i-c.dtb \
- sun8i-s3-elimo-initium.dtb \
- sun8i-s3-lichee-zero-plus.dtb \
- sun8i-s3-pinecube.dtb \
- sun8i-t113s-mangopi-mq-r-t113.dtb \
- sun8i-t3-cqa3t-bv3.dtb \
- sun8i-v3-sl631-imx179.dtb \
- sun8i-v3s-licheepi-zero.dtb \
- sun8i-v3s-licheepi-zero-dock.dtb \
- sun8i-v40-bananapi-m2-berry.dtb
-dtb-$(CONFIG_MACH_SUN9I) += \
- sun9i-a80-optimus.dtb \
- sun9i-a80-cubieboard4.dtb
-dtb-$(CONFIG_MACH_SUNIV) += \
- suniv-f1c100s-licheepi-nano.dtb \
- suniv-f1c200s-lctech-pi.dtb \
- suniv-f1c200s-popstick-v1.1.dtb
-dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
- tegra20-acer-a500-picasso.dtb \
- tegra20-asus-tf101.dtb \
- tegra20-harmony.dtb \
- tegra20-colibri-eval-v3.dtb \
- tegra20-colibri-iris.dtb \
- tegra20-medcom-wide.dtb \
- tegra20-paz00.dtb \
- tegra20-plutux.dtb \
- tegra20-seaboard.dtb \
- tegra20-tec.dtb \
- tegra20-trimslice.dtb \
- tegra20-ventana.dtb
-dtb-$(CONFIG_ARCH_TEGRA_3x_SOC) += \
- tegra30-apalis-eval.dtb \
- tegra30-apalis-v1.1-eval.dtb \
- tegra30-asus-nexus7-grouper-PM269.dtb \
- tegra30-asus-nexus7-grouper-E1565.dtb \
- tegra30-asus-nexus7-tilapia-E1565.dtb \
- tegra30-asus-tf201.dtb \
- tegra30-asus-tf300t.dtb \
- tegra30-asus-tf300tg.dtb \
- tegra30-asus-tf700t.dtb \
- tegra30-beaver.dtb \
- tegra30-cardhu-a02.dtb \
- tegra30-cardhu-a04.dtb \
- tegra30-colibri-eval-v3.dtb \
- tegra30-ouya.dtb \
- tegra30-pegatron-chagall.dtb
-dtb-$(CONFIG_ARCH_TEGRA_114_SOC) += \
- tegra114-asus-tf701t.dtb \
- tegra114-dalmore.dtb \
- tegra114-roth.dtb \
- tegra114-tn7.dtb
-dtb-$(CONFIG_ARCH_TEGRA_124_SOC) += \
- tegra124-apalis-eval.dtb \
- tegra124-apalis-v1.2-eval.dtb \
- tegra124-jetson-tk1.dtb \
- tegra124-nyan-big.dtb \
- tegra124-nyan-big-fhd.dtb \
- tegra124-nyan-blaze.dtb \
- tegra124-venice2.dtb
-dtb-$(CONFIG_ARCH_U8500) += \
- ste-snowball.dtb \
- ste-hrefprev60-stuib.dtb \
- ste-hrefprev60-tvk.dtb \
- ste-hrefv60plus-stuib.dtb \
- ste-hrefv60plus-tvk.dtb \
- ste-href520-tvk.dtb \
- ste-ux500-samsung-golden.dtb \
- ste-ux500-samsung-janice.dtb \
- ste-ux500-samsung-gavini.dtb \
- ste-ux500-samsung-codina.dtb \
- ste-ux500-samsung-codina-tmo.dtb \
- ste-ux500-samsung-skomer.dtb \
- ste-ux500-samsung-kyle.dtb
-dtb-$(CONFIG_ARCH_UNIPHIER) += \
- uniphier-ld4-ref.dtb \
- uniphier-ld6b-ref.dtb \
- uniphier-pro4-ace.dtb \
- uniphier-pro4-ref.dtb \
- uniphier-pro4-sanji.dtb \
- uniphier-pro5-epcore.dtb \
- uniphier-pro5-proex.dtb \
- uniphier-pxs2-gentil.dtb \
- uniphier-pxs2-vodka.dtb \
- uniphier-sld8-ref.dtb
-dtb-$(CONFIG_ARCH_VERSATILE) += \
- versatile-ab.dtb \
- versatile-ab-ib2.dtb \
- versatile-pb.dtb
-dtb-$(CONFIG_ARCH_VEXPRESS) += \
- vexpress-v2p-ca5s.dtb \
- vexpress-v2p-ca9.dtb \
- vexpress-v2p-ca15-tc1.dtb \
- vexpress-v2p-ca15_a7.dtb
-dtb-$(CONFIG_ARCH_VIRT) += \
- xenvm-4.2.dtb
-dtb-$(CONFIG_ARCH_VT8500) += \
- vt8500-bv07.dtb \
- wm8505-ref.dtb \
- wm8650-mid.dtb \
- wm8750-apc8750.dtb \
- wm8850-w70v2.dtb
-dtb-$(CONFIG_ARCH_ZYNQ) += \
- zynq-cc108.dtb \
- zynq-ebaz4205.dtb \
- zynq-microzed.dtb \
- zynq-parallella.dtb \
- zynq-zc702.dtb \
- zynq-zc706.dtb \
- zynq-zc770-xm010.dtb \
- zynq-zc770-xm011.dtb \
- zynq-zc770-xm012.dtb \
- zynq-zc770-xm013.dtb \
- zynq-zed.dtb \
- zynq-zturn.dtb \
- zynq-zturn-v5.dtb \
- zynq-zybo.dtb \
- zynq-zybo-z7.dtb
-dtb-$(CONFIG_MACH_ARMADA_370) += \
- armada-370-c200-v2.dtb \
- armada-370-db.dtb \
- armada-370-dlink-dns327l.dtb \
- armada-370-mirabox.dtb \
- armada-370-netgear-rn102.dtb \
- armada-370-netgear-rn104.dtb \
- armada-370-rd.dtb \
- armada-370-seagate-nas-2bay.dtb \
- armada-370-seagate-nas-4bay.dtb \
- armada-370-seagate-personal-cloud.dtb \
- armada-370-seagate-personal-cloud-2bay.dtb \
- armada-370-synology-ds213j.dtb
-dtb-$(CONFIG_MACH_ARMADA_375) += \
- armada-375-db.dtb
-dtb-$(CONFIG_MACH_ARMADA_38X) += \
- armada-381-netgear-gs110emx.dtb \
- armada-382-rd-ac3x-48g4x2xl.dtb \
- armada-385-atl-x530.dtb\
- armada-385-clearfog-gtr-s4.dtb \
- armada-385-clearfog-gtr-l8.dtb \
- armada-385-db-88f6820-amc.dtb \
- armada-385-db-ap.dtb \
- armada-385-linksys-caiman.dtb \
- armada-385-linksys-cobra.dtb \
- armada-385-linksys-rango.dtb \
- armada-385-linksys-shelby.dtb \
- armada-385-synology-ds116.dtb \
- armada-385-turris-omnia.dtb \
- armada-388-clearfog.dtb \
- armada-388-clearfog-base.dtb \
- armada-388-clearfog-pro.dtb \
- armada-388-db.dtb \
- armada-388-gp.dtb \
- armada-388-helios4.dtb \
- armada-388-rd.dtb
-dtb-$(CONFIG_MACH_ARMADA_39X) += \
- armada-398-db.dtb
-dtb-$(CONFIG_MACH_ARMADA_XP) += \
- armada-xp-axpwifiap.dtb \
- armada-xp-crs305-1g-4s.dtb \
- armada-xp-crs305-1g-4s-bit.dtb \
- armada-xp-crs326-24g-2s.dtb \
- armada-xp-crs326-24g-2s-bit.dtb \
- armada-xp-crs328-4c-20s-4s.dtb \
- armada-xp-crs328-4c-20s-4s-bit.dtb \
- armada-xp-db.dtb \
- armada-xp-db-dxbc2.dtb \
- armada-xp-db-xc3-24g4xg.dtb \
- armada-xp-gp.dtb \
- armada-xp-lenovo-ix4-300d.dtb \
- armada-xp-linksys-mamba.dtb \
- armada-xp-matrix.dtb \
- armada-xp-netgear-rn2120.dtb \
- armada-xp-openblocks-ax3-4.dtb \
- armada-xp-synology-ds414.dtb
-dtb-$(CONFIG_MACH_DOVE) += \
- dove-cubox.dtb \
- dove-cubox-es.dtb \
- dove-d2plug.dtb \
- dove-d3plug.dtb \
- dove-dove-db.dtb \
- dove-sbc-a510.dtb
-dtb-$(CONFIG_ARCH_MEDIATEK) += \
- mt2701-evb.dtb \
- mt6580-evbp1.dtb \
- mt6589-aquaris5.dtb \
- mt6589-fairphone-fp1.dtb \
- mt6592-evb.dtb \
- mt7623a-rfb-emmc.dtb \
- mt7623a-rfb-nand.dtb \
- mt7623n-rfb-emmc.dtb \
- mt7623n-bananapi-bpi-r2.dtb \
- mt7629-rfb.dtb \
- mt8127-moose.dtb \
- mt8135-evbp1.dtb
-dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
-dtb-$(CONFIG_ARCH_MSTARV7) += \
- mstar-infinity-msc313-breadbee_crust.dtb \
- mstar-infinity2m-ssd202d-100ask-dongshanpione.dtb \
- mstar-infinity2m-ssd202d-miyoo-mini.dtb \
- mstar-infinity2m-ssd202d-wirelesstag-ido-sbc2d06-v1b-22w.dtb \
- mstar-infinity2m-ssd202d-ssd201htv2.dtb \
- mstar-infinity2m-ssd202d-unitv2.dtb \
- mstar-infinity3-msc313e-breadbee.dtb \
- mstar-mercury5-ssc8336n-midrived08.dtb
-dtb-$(CONFIG_ARCH_ASPEED) += \
- aspeed-ast2500-evb.dtb \
- aspeed-ast2600-evb-a1.dtb \
- aspeed-ast2600-evb.dtb \
- aspeed-bmc-amd-daytonax.dtb \
- aspeed-bmc-amd-ethanolx.dtb \
- aspeed-bmc-ampere-mtjade.dtb \
- aspeed-bmc-ampere-mtmitchell.dtb \
- aspeed-bmc-arm-stardragon4800-rep2.dtb \
- aspeed-bmc-asrock-e3c246d4i.dtb \
- aspeed-bmc-asrock-romed8hm3.dtb \
- aspeed-bmc-bytedance-g220a.dtb \
- aspeed-bmc-delta-ahe50dc.dtb \
- aspeed-bmc-facebook-bletchley.dtb \
- aspeed-bmc-facebook-cloudripper.dtb \
- aspeed-bmc-facebook-cmm.dtb \
- aspeed-bmc-facebook-elbert.dtb \
- aspeed-bmc-facebook-fuji.dtb \
- aspeed-bmc-facebook-galaxy100.dtb \
- aspeed-bmc-facebook-greatlakes.dtb \
- aspeed-bmc-facebook-minipack.dtb \
- aspeed-bmc-facebook-tiogapass.dtb \
- aspeed-bmc-facebook-wedge40.dtb \
- aspeed-bmc-facebook-wedge100.dtb \
- aspeed-bmc-facebook-wedge400.dtb \
- aspeed-bmc-facebook-yamp.dtb \
- aspeed-bmc-facebook-yosemitev2.dtb \
- aspeed-bmc-ibm-bonnell.dtb \
- aspeed-bmc-ibm-everest.dtb \
- aspeed-bmc-ibm-rainier.dtb \
- aspeed-bmc-ibm-rainier-1s4u.dtb \
- aspeed-bmc-ibm-rainier-4u.dtb \
- aspeed-bmc-intel-s2600wf.dtb \
- aspeed-bmc-inspur-fp5280g2.dtb \
- aspeed-bmc-inspur-nf5280m6.dtb \
- aspeed-bmc-lenovo-hr630.dtb \
- aspeed-bmc-lenovo-hr855xg2.dtb \
- aspeed-bmc-microsoft-olympus.dtb \
- aspeed-bmc-opp-lanyang.dtb \
- aspeed-bmc-opp-mowgli.dtb \
- aspeed-bmc-opp-nicole.dtb \
- aspeed-bmc-opp-palmetto.dtb \
- aspeed-bmc-opp-romulus.dtb \
- aspeed-bmc-opp-swift.dtb \
- aspeed-bmc-opp-tacoma.dtb \
- aspeed-bmc-opp-vesnin.dtb \
- aspeed-bmc-opp-witherspoon.dtb \
- aspeed-bmc-opp-zaius.dtb \
- aspeed-bmc-portwell-neptune.dtb \
- aspeed-bmc-qcom-dc-scm-v1.dtb \
- aspeed-bmc-quanta-q71l.dtb \
- aspeed-bmc-quanta-s6q.dtb \
- aspeed-bmc-supermicro-x11spi.dtb \
- aspeed-bmc-inventec-transformers.dtb \
- aspeed-bmc-tyan-s7106.dtb \
- aspeed-bmc-tyan-s8036.dtb \
- aspeed-bmc-ufispace-ncplite.dtb \
- aspeed-bmc-vegman-n110.dtb \
- aspeed-bmc-vegman-rx20.dtb \
- aspeed-bmc-vegman-sx20.dtb
+subdir-y += actions
+subdir-y += airoha
+subdir-y += allwinner
+subdir-y += alphascale
+subdir-y += amazon
+subdir-y += amlogic
+subdir-y += arm
+subdir-y += aspeed
+subdir-y += axis
+subdir-y += broadcom
+subdir-y += calxeda
+subdir-y += cirrus
+subdir-y += cnxt
+subdir-y += gemini
+subdir-y += hisilicon
+subdir-y += hpe
+subdir-y += intel
+subdir-y += marvell
+subdir-y += mediatek
+subdir-y += microchip
+subdir-y += moxa
+subdir-y += nspire
+subdir-y += nuvoton
+subdir-y += nvidia
+subdir-y += nxp
+subdir-y += qcom
+subdir-y += realtek
+subdir-y += renesas
+subdir-y += rockchip
+subdir-y += samsung
+subdir-y += sigmastar
+subdir-y += socionext
+subdir-y += st
+subdir-y += sunplus
+subdir-y += synaptics
+subdir-y += ti
+subdir-y += unisoc
+subdir-y += vt8500
+subdir-y += xen
+subdir-y += xilinx
diff --git a/arch/arm/boot/dts/actions/Makefile b/arch/arm/boot/dts/actions/Makefile
new file mode 100644
index 0000000..f384e4a
--- /dev/null
+++ b/arch/arm/boot/dts/actions/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_ACTIONS) += \
+ owl-s500-cubieboard6.dtb \
+ owl-s500-guitar-bb-rev-b.dtb \
+ owl-s500-labrador-base-m.dtb \
+ owl-s500-roseapplepi.dtb \
+ owl-s500-sparky.dtb
diff --git a/arch/arm/boot/dts/owl-s500-cubieboard6.dts b/arch/arm/boot/dts/actions/owl-s500-cubieboard6.dts
similarity index 100%
rename from arch/arm/boot/dts/owl-s500-cubieboard6.dts
rename to arch/arm/boot/dts/actions/owl-s500-cubieboard6.dts
diff --git a/arch/arm/boot/dts/owl-s500-guitar-bb-rev-b.dts b/arch/arm/boot/dts/actions/owl-s500-guitar-bb-rev-b.dts
similarity index 100%
rename from arch/arm/boot/dts/owl-s500-guitar-bb-rev-b.dts
rename to arch/arm/boot/dts/actions/owl-s500-guitar-bb-rev-b.dts
diff --git a/arch/arm/boot/dts/owl-s500-guitar.dtsi b/arch/arm/boot/dts/actions/owl-s500-guitar.dtsi
similarity index 100%
rename from arch/arm/boot/dts/owl-s500-guitar.dtsi
rename to arch/arm/boot/dts/actions/owl-s500-guitar.dtsi
diff --git a/arch/arm/boot/dts/owl-s500-labrador-base-m.dts b/arch/arm/boot/dts/actions/owl-s500-labrador-base-m.dts
similarity index 100%
rename from arch/arm/boot/dts/owl-s500-labrador-base-m.dts
rename to arch/arm/boot/dts/actions/owl-s500-labrador-base-m.dts
diff --git a/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi b/arch/arm/boot/dts/actions/owl-s500-labrador-v2.dtsi
similarity index 100%
rename from arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
rename to arch/arm/boot/dts/actions/owl-s500-labrador-v2.dtsi
diff --git a/arch/arm/boot/dts/owl-s500-roseapplepi.dts b/arch/arm/boot/dts/actions/owl-s500-roseapplepi.dts
similarity index 100%
rename from arch/arm/boot/dts/owl-s500-roseapplepi.dts
rename to arch/arm/boot/dts/actions/owl-s500-roseapplepi.dts
diff --git a/arch/arm/boot/dts/owl-s500-sparky.dts b/arch/arm/boot/dts/actions/owl-s500-sparky.dts
similarity index 100%
rename from arch/arm/boot/dts/owl-s500-sparky.dts
rename to arch/arm/boot/dts/actions/owl-s500-sparky.dts
diff --git a/arch/arm/boot/dts/owl-s500.dtsi b/arch/arm/boot/dts/actions/owl-s500.dtsi
similarity index 100%
rename from arch/arm/boot/dts/owl-s500.dtsi
rename to arch/arm/boot/dts/actions/owl-s500.dtsi
diff --git a/arch/arm/boot/dts/airoha/Makefile b/arch/arm/boot/dts/airoha/Makefile
new file mode 100644
index 0000000..00c3138
--- /dev/null
+++ b/arch/arm/boot/dts/airoha/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_AIROHA) += \
+ en7523-evb.dtb
diff --git a/arch/arm/boot/dts/en7523-evb.dts b/arch/arm/boot/dts/airoha/en7523-evb.dts
similarity index 100%
rename from arch/arm/boot/dts/en7523-evb.dts
rename to arch/arm/boot/dts/airoha/en7523-evb.dts
diff --git a/arch/arm/boot/dts/airoha/en7523.dtsi b/arch/arm/boot/dts/airoha/en7523.dtsi
new file mode 100644
index 0000000..b523a868
--- /dev/null
+++ b/arch/arm/boot/dts/airoha/en7523.dtsi
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/clock/en7523-clk.h>
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ npu_binary@84000000 {
+ no-map;
+ reg = <0x84000000 0xA00000>;
+ };
+
+ npu_flag@84B0000 {
+ no-map;
+ reg = <0x84B00000 0x100000>;
+ };
+
+ npu_pkt@85000000 {
+ no-map;
+ reg = <0x85000000 0x1A00000>;
+ };
+
+ npu_phyaddr@86B00000 {
+ no-map;
+ reg = <0x86B00000 0x100000>;
+ };
+
+ npu_rxdesc@86D00000 {
+ no-map;
+ reg = <0x86D00000 0x100000>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ enable-method = "psci";
+ clock-frequency = <80000000>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1>;
+ enable-method = "psci";
+ clock-frequency = <80000000>;
+ next-level-cache = <&L2_0>;
+ };
+
+ L2_0: l2-cache0 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-unified;
+ };
+ };
+
+ scu: system-controller@1fa20000 {
+ compatible = "airoha,en7523-scu";
+ reg = <0x1fa20000 0x400>,
+ <0x1fb00000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ gic: interrupt-controller@9000000 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x09000000 0x20000>,
+ <0x09080000 0x80000>,
+ <0x09400000 0x2000>,
+ <0x09500000 0x2000>,
+ <0x09600000 0x20000>;
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ uart1: serial@1fbf0000 {
+ compatible = "ns16550";
+ reg = <0x1fbf0000 0x30>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <1843200>;
+ status = "okay";
+ };
+
+ gpio0: gpio@1fbf0200 {
+ compatible = "airoha,en7523-gpio";
+ reg = <0x1fbf0204 0x4>,
+ <0x1fbf0200 0x4>,
+ <0x1fbf0220 0x4>,
+ <0x1fbf0214 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio1: gpio@1fbf0270 {
+ compatible = "airoha,en7523-gpio";
+ reg = <0x1fbf0270 0x4>,
+ <0x1fbf0260 0x4>,
+ <0x1fbf0264 0x4>,
+ <0x1fbf0278 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ pcie0: pcie@1fa91000 {
+ compatible = "airoha,en7523-pcie", "mediatek,mt7622-pcie";
+ device_type = "pci";
+ reg = <0x1fa91000 0x1000>;
+ reg-names = "port0";
+ linux,pci-domain = <0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie_irq";
+ clocks = <&scu EN7523_CLK_PCIE>;
+ clock-names = "sys_ck0";
+ bus-range = <0x00 0xff>;
+ ranges = <0x82000000 0 0x20000000 0x20000000 0 0x8000000>;
+ status = "disabled";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc0 0>,
+ <0 0 0 2 &pcie_intc0 1>,
+ <0 0 0 3 &pcie_intc0 2>,
+ <0 0 0 4 &pcie_intc0 3>;
+ pcie_intc0: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ pcie1: pcie@1fa92000 {
+ compatible = "airoha,en7523-pcie", "mediatek,mt7622-pcie";
+ device_type = "pci";
+ reg = <0x1fa92000 0x1000>;
+ reg-names = "port1";
+ linux,pci-domain = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie_irq";
+ clocks = <&scu EN7523_CLK_PCIE>;
+ clock-names = "sys_ck1";
+ bus-range = <0x00 0xff>;
+ ranges = <0x82000000 0 0x28000000 0x28000000 0 0x8000000>;
+ status = "disabled";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc1 0>,
+ <0 0 0 2 &pcie_intc1 1>,
+ <0 0 0 3 &pcie_intc1 2>,
+ <0 0 0 4 &pcie_intc1 3>;
+ pcie_intc1: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/allwinner/Makefile b/arch/arm/boot/dts/allwinner/Makefile
new file mode 100644
index 0000000..589a1ce
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/Makefile
@@ -0,0 +1,315 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_MACH_SUN4I) += \
+ sun4i-a10-a1000.dtb \
+ sun4i-a10-ba10-tvbox.dtb \
+ sun4i-a10-chuwi-v7-cw0825.dtb \
+ sun4i-a10-cubieboard.dtb \
+ sun4i-a10-dserve-dsrv9703c.dtb \
+ sun4i-a10-gemei-g9.dtb \
+ sun4i-a10-hackberry.dtb \
+ sun4i-a10-hyundai-a7hd.dtb \
+ sun4i-a10-inet1.dtb \
+ sun4i-a10-inet97fv2.dtb \
+ sun4i-a10-inet9f-rev03.dtb \
+ sun4i-a10-itead-iteaduino-plus.dtb \
+ sun4i-a10-jesurun-q5.dtb \
+ sun4i-a10-marsboard.dtb \
+ sun4i-a10-mini-xplus.dtb \
+ sun4i-a10-mk802.dtb \
+ sun4i-a10-mk802ii.dtb \
+ sun4i-a10-olinuxino-lime.dtb \
+ sun4i-a10-pcduino.dtb \
+ sun4i-a10-pcduino2.dtb \
+ sun4i-a10-pov-protab2-ips9.dtb \
+ sun4i-a10-topwise-a721.dtb
+dtb-$(CONFIG_MACH_SUN4I) += \
+ sun4i-a10-a1000.dtb \
+ sun4i-a10-ba10-tvbox.dtb \
+ sun4i-a10-chuwi-v7-cw0825.dtb \
+ sun4i-a10-cubieboard.dtb \
+ sun4i-a10-dserve-dsrv9703c.dtb \
+ sun4i-a10-gemei-g9.dtb \
+ sun4i-a10-hackberry.dtb \
+ sun4i-a10-hyundai-a7hd.dtb \
+ sun4i-a10-inet1.dtb \
+ sun4i-a10-inet97fv2.dtb \
+ sun4i-a10-inet9f-rev03.dtb \
+ sun4i-a10-itead-iteaduino-plus.dtb \
+ sun4i-a10-jesurun-q5.dtb \
+ sun4i-a10-marsboard.dtb \
+ sun4i-a10-mini-xplus.dtb \
+ sun4i-a10-mk802.dtb \
+ sun4i-a10-mk802ii.dtb \
+ sun4i-a10-olinuxino-lime.dtb \
+ sun4i-a10-pcduino.dtb \
+ sun4i-a10-pcduino2.dtb \
+ sun4i-a10-pov-protab2-ips9.dtb \
+ sun4i-a10-topwise-a721.dtb
+dtb-$(CONFIG_MACH_SUN5I) += \
+ sun5i-a10s-auxtek-t003.dtb \
+ sun5i-a10s-auxtek-t004.dtb \
+ sun5i-a10s-mk802.dtb \
+ sun5i-a10s-olinuxino-micro.dtb \
+ sun5i-a10s-r7-tv-dongle.dtb \
+ sun5i-a10s-wobo-i5.dtb \
+ sun5i-a13-difrnce-dit4350.dtb \
+ sun5i-a13-empire-electronix-d709.dtb \
+ sun5i-a13-empire-electronix-m712.dtb \
+ sun5i-a13-hsg-h702.dtb \
+ sun5i-a13-inet-98v-rev2.dtb \
+ sun5i-a13-licheepi-one.dtb \
+ sun5i-a13-olinuxino.dtb \
+ sun5i-a13-olinuxino-micro.dtb \
+ sun5i-a13-pocketbook-touch-lux-3.dtb \
+ sun5i-a13-q8-tablet.dtb \
+ sun5i-a13-utoo-p66.dtb \
+ sun5i-gr8-chip-pro.dtb \
+ sun5i-gr8-evb.dtb \
+ sun5i-r8-chip.dtb
+dtb-$(CONFIG_MACH_SUN5I) += \
+ sun5i-a10s-auxtek-t003.dtb \
+ sun5i-a10s-auxtek-t004.dtb \
+ sun5i-a10s-mk802.dtb \
+ sun5i-a10s-olinuxino-micro.dtb \
+ sun5i-a10s-r7-tv-dongle.dtb \
+ sun5i-a10s-wobo-i5.dtb \
+ sun5i-a13-difrnce-dit4350.dtb \
+ sun5i-a13-empire-electronix-d709.dtb \
+ sun5i-a13-empire-electronix-m712.dtb \
+ sun5i-a13-hsg-h702.dtb \
+ sun5i-a13-inet-98v-rev2.dtb \
+ sun5i-a13-licheepi-one.dtb \
+ sun5i-a13-olinuxino.dtb \
+ sun5i-a13-olinuxino-micro.dtb \
+ sun5i-a13-pocketbook-touch-lux-3.dtb \
+ sun5i-a13-q8-tablet.dtb \
+ sun5i-a13-utoo-p66.dtb \
+ sun5i-gr8-chip-pro.dtb \
+ sun5i-gr8-evb.dtb \
+ sun5i-r8-chip.dtb
+dtb-$(CONFIG_MACH_SUN6I) += \
+ sun6i-a31-app4-evb1.dtb \
+ sun6i-a31-colombus.dtb \
+ sun6i-a31-hummingbird.dtb \
+ sun6i-a31-i7.dtb \
+ sun6i-a31-m9.dtb \
+ sun6i-a31-mele-a1000g-quad.dtb \
+ sun6i-a31s-colorfly-e708-q1.dtb \
+ sun6i-a31s-cs908.dtb \
+ sun6i-a31s-inet-q972.dtb \
+ sun6i-a31s-primo81.dtb \
+ sun6i-a31s-sina31s.dtb \
+ sun6i-a31s-sinovoip-bpi-m2.dtb \
+ sun6i-a31s-yones-toptech-bs1078-v2.dtb
+dtb-$(CONFIG_MACH_SUN6I) += \
+ sun6i-a31-app4-evb1.dtb \
+ sun6i-a31-colombus.dtb \
+ sun6i-a31-hummingbird.dtb \
+ sun6i-a31-i7.dtb \
+ sun6i-a31-m9.dtb \
+ sun6i-a31-mele-a1000g-quad.dtb \
+ sun6i-a31s-colorfly-e708-q1.dtb \
+ sun6i-a31s-cs908.dtb \
+ sun6i-a31s-inet-q972.dtb \
+ sun6i-a31s-primo81.dtb \
+ sun6i-a31s-sina31s.dtb \
+ sun6i-a31s-sinovoip-bpi-m2.dtb \
+ sun6i-a31s-yones-toptech-bs1078-v2.dtb
+dtb-$(CONFIG_MACH_SUN7I) += \
+ sun7i-a20-bananapi.dtb \
+ sun7i-a20-bananapi-m1-plus.dtb \
+ sun7i-a20-bananapro.dtb \
+ sun7i-a20-cubieboard2.dtb \
+ sun7i-a20-cubietruck.dtb \
+ sun7i-a20-haoyu-marsboard.dtb \
+ sun7i-a20-hummingbird.dtb \
+ sun7i-a20-itead-ibox.dtb \
+ sun7i-a20-i12-tvbox.dtb \
+ sun7i-a20-icnova-a20-adb4006.dtb \
+ sun7i-a20-icnova-swac.dtb \
+ sun7i-a20-lamobo-r1.dtb \
+ sun7i-a20-linutronix-testbox-v2.dtb \
+ sun7i-a20-m3.dtb \
+ sun7i-a20-mk808c.dtb \
+ sun7i-a20-olimex-som-evb.dtb \
+ sun7i-a20-olimex-som-evb-emmc.dtb \
+ sun7i-a20-olimex-som204-evb.dtb \
+ sun7i-a20-olimex-som204-evb-emmc.dtb \
+ sun7i-a20-olinuxino-lime.dtb \
+ sun7i-a20-olinuxino-lime-emmc.dtb \
+ sun7i-a20-olinuxino-lime2.dtb \
+ sun7i-a20-olinuxino-lime2-emmc.dtb \
+ sun7i-a20-olinuxino-micro.dtb \
+ sun7i-a20-olinuxino-micro-emmc.dtb \
+ sun7i-a20-orangepi.dtb \
+ sun7i-a20-orangepi-mini.dtb \
+ sun7i-a20-pcduino3.dtb \
+ sun7i-a20-pcduino3-nano.dtb \
+ sun7i-a20-wexler-tab7200.dtb \
+ sun7i-a20-wits-pro-a20-dkt.dtb
+dtb-$(CONFIG_MACH_SUN7I) += \
+ sun7i-a20-bananapi.dtb \
+ sun7i-a20-bananapi-m1-plus.dtb \
+ sun7i-a20-bananapro.dtb \
+ sun7i-a20-cubieboard2.dtb \
+ sun7i-a20-cubietruck.dtb \
+ sun7i-a20-haoyu-marsboard.dtb \
+ sun7i-a20-hummingbird.dtb \
+ sun7i-a20-itead-ibox.dtb \
+ sun7i-a20-i12-tvbox.dtb \
+ sun7i-a20-icnova-a20-adb4006.dtb \
+ sun7i-a20-icnova-swac.dtb \
+ sun7i-a20-lamobo-r1.dtb \
+ sun7i-a20-linutronix-testbox-v2.dtb \
+ sun7i-a20-m3.dtb \
+ sun7i-a20-mk808c.dtb \
+ sun7i-a20-olimex-som-evb.dtb \
+ sun7i-a20-olimex-som-evb-emmc.dtb \
+ sun7i-a20-olimex-som204-evb.dtb \
+ sun7i-a20-olimex-som204-evb-emmc.dtb \
+ sun7i-a20-olinuxino-lime.dtb \
+ sun7i-a20-olinuxino-lime-emmc.dtb \
+ sun7i-a20-olinuxino-lime2.dtb \
+ sun7i-a20-olinuxino-lime2-emmc.dtb \
+ sun7i-a20-olinuxino-micro.dtb \
+ sun7i-a20-olinuxino-micro-emmc.dtb \
+ sun7i-a20-orangepi.dtb \
+ sun7i-a20-orangepi-mini.dtb \
+ sun7i-a20-pcduino3.dtb \
+ sun7i-a20-pcduino3-nano.dtb \
+ sun7i-a20-wexler-tab7200.dtb \
+ sun7i-a20-wits-pro-a20-dkt.dtb
+dtb-$(CONFIG_MACH_SUN8I) += \
+ sun8i-a23-evb.dtb \
+ sun8i-a23-gt90h-v4.dtb \
+ sun8i-a23-inet86dz.dtb \
+ sun8i-a23-ippo-q8h-v5.dtb \
+ sun8i-a23-ippo-q8h-v1.2.dtb \
+ sun8i-a23-polaroid-mid2407pxe03.dtb \
+ sun8i-a23-polaroid-mid2809pxe04.dtb \
+ sun8i-a23-q8-tablet.dtb \
+ sun8i-a33-et-q8-v1.6.dtb \
+ sun8i-a33-ga10h-v1.1.dtb \
+ sun8i-a33-inet-d978-rev2.dtb \
+ sun8i-a33-ippo-q8h-v1.2.dtb \
+ sun8i-a33-olinuxino.dtb \
+ sun8i-a33-q8-tablet.dtb \
+ sun8i-a33-sinlinx-sina33.dtb \
+ sun8i-a83t-allwinner-h8homlet-v2.dtb \
+ sun8i-a83t-bananapi-m3.dtb \
+ sun8i-a83t-cubietruck-plus.dtb \
+ sun8i-a83t-tbs-a711.dtb \
+ sun8i-h2-plus-bananapi-m2-zero.dtb \
+ sun8i-h2-plus-libretech-all-h3-cc.dtb \
+ sun8i-h2-plus-orangepi-r1.dtb \
+ sun8i-h2-plus-orangepi-zero.dtb \
+ sun8i-h3-bananapi-m2-plus.dtb \
+ sun8i-h3-bananapi-m2-plus-v1.2.dtb \
+ sun8i-h3-beelink-x2.dtb \
+ sun8i-h3-libretech-all-h3-cc.dtb \
+ sun8i-h3-mapleboard-mp130.dtb \
+ sun8i-h3-nanopi-duo2.dtb \
+ sun8i-h3-nanopi-m1.dtb \
+ sun8i-h3-nanopi-m1-plus.dtb \
+ sun8i-h3-nanopi-neo.dtb \
+ sun8i-h3-nanopi-neo-air.dtb \
+ sun8i-h3-nanopi-r1.dtb \
+ sun8i-h3-orangepi-2.dtb \
+ sun8i-h3-orangepi-lite.dtb \
+ sun8i-h3-orangepi-one.dtb \
+ sun8i-h3-orangepi-pc.dtb \
+ sun8i-h3-orangepi-pc-plus.dtb \
+ sun8i-h3-orangepi-plus.dtb \
+ sun8i-h3-orangepi-plus2e.dtb \
+ sun8i-h3-orangepi-zero-plus2.dtb \
+ sun8i-h3-rervision-dvk.dtb \
+ sun8i-h3-zeropi.dtb \
+ sun8i-h3-emlid-neutis-n5h3-devboard.dtb \
+ sun8i-r16-bananapi-m2m.dtb \
+ sun8i-r16-nintendo-nes-classic.dtb \
+ sun8i-r16-nintendo-super-nes-classic.dtb \
+ sun8i-r16-parrot.dtb \
+ sun8i-r40-bananapi-m2-ultra.dtb \
+ sun8i-r40-oka40i-c.dtb \
+ sun8i-s3-elimo-initium.dtb \
+ sun8i-s3-lichee-zero-plus.dtb \
+ sun8i-s3-pinecube.dtb \
+ sun8i-t113s-mangopi-mq-r-t113.dtb \
+ sun8i-t3-cqa3t-bv3.dtb \
+ sun8i-v3-sl631-imx179.dtb \
+ sun8i-v3s-licheepi-zero.dtb \
+ sun8i-v3s-licheepi-zero-dock.dtb \
+ sun8i-v40-bananapi-m2-berry.dtb
+dtb-$(CONFIG_MACH_SUN8I) += \
+ sun8i-a23-evb.dtb \
+ sun8i-a23-gt90h-v4.dtb \
+ sun8i-a23-inet86dz.dtb \
+ sun8i-a23-ippo-q8h-v5.dtb \
+ sun8i-a23-ippo-q8h-v1.2.dtb \
+ sun8i-a23-polaroid-mid2407pxe03.dtb \
+ sun8i-a23-polaroid-mid2809pxe04.dtb \
+ sun8i-a23-q8-tablet.dtb \
+ sun8i-a33-et-q8-v1.6.dtb \
+ sun8i-a33-ga10h-v1.1.dtb \
+ sun8i-a33-inet-d978-rev2.dtb \
+ sun8i-a33-ippo-q8h-v1.2.dtb \
+ sun8i-a33-olinuxino.dtb \
+ sun8i-a33-q8-tablet.dtb \
+ sun8i-a33-sinlinx-sina33.dtb \
+ sun8i-a83t-allwinner-h8homlet-v2.dtb \
+ sun8i-a83t-bananapi-m3.dtb \
+ sun8i-a83t-cubietruck-plus.dtb \
+ sun8i-a83t-tbs-a711.dtb \
+ sun8i-h2-plus-bananapi-m2-zero.dtb \
+ sun8i-h2-plus-libretech-all-h3-cc.dtb \
+ sun8i-h2-plus-orangepi-r1.dtb \
+ sun8i-h2-plus-orangepi-zero.dtb \
+ sun8i-h3-bananapi-m2-plus.dtb \
+ sun8i-h3-bananapi-m2-plus-v1.2.dtb \
+ sun8i-h3-beelink-x2.dtb \
+ sun8i-h3-libretech-all-h3-cc.dtb \
+ sun8i-h3-mapleboard-mp130.dtb \
+ sun8i-h3-nanopi-duo2.dtb \
+ sun8i-h3-nanopi-m1.dtb\
+ \
+ sun8i-h3-nanopi-m1-plus.dtb \
+ sun8i-h3-nanopi-neo.dtb \
+ sun8i-h3-nanopi-neo-air.dtb \
+ sun8i-h3-nanopi-r1.dtb \
+ sun8i-h3-orangepi-2.dtb \
+ sun8i-h3-orangepi-lite.dtb \
+ sun8i-h3-orangepi-one.dtb \
+ sun8i-h3-orangepi-pc.dtb \
+ sun8i-h3-orangepi-pc-plus.dtb \
+ sun8i-h3-orangepi-plus.dtb \
+ sun8i-h3-orangepi-plus2e.dtb \
+ sun8i-h3-orangepi-zero-plus2.dtb \
+ sun8i-h3-rervision-dvk.dtb \
+ sun8i-h3-zeropi.dtb \
+ sun8i-h3-emlid-neutis-n5h3-devboard.dtb \
+ sun8i-r16-bananapi-m2m.dtb \
+ sun8i-r16-nintendo-nes-classic.dtb \
+ sun8i-r16-nintendo-super-nes-classic.dtb \
+ sun8i-r16-parrot.dtb \
+ sun8i-r40-bananapi-m2-ultra.dtb \
+ sun8i-r40-oka40i-c.dtb \
+ sun8i-s3-elimo-initium.dtb \
+ sun8i-s3-lichee-zero-plus.dtb \
+ sun8i-s3-pinecube.dtb \
+ sun8i-t113s-mangopi-mq-r-t113.dtb \
+ sun8i-t3-cqa3t-bv3.dtb \
+ sun8i-v3-sl631-imx179.dtb \
+ sun8i-v3s-licheepi-zero.dtb \
+ sun8i-v3s-licheepi-zero-dock.dtb \
+ sun8i-v40-bananapi-m2-berry.dtb
+dtb-$(CONFIG_MACH_SUN9I) += \
+ sun9i-a80-optimus.dtb \
+ sun9i-a80-cubieboard4.dtb
+dtb-$(CONFIG_MACH_SUNIV) += \
+ suniv-f1c100s-licheepi-nano.dtb \
+ suniv-f1c200s-lctech-pi.dtb \
+ suniv-f1c200s-popstick-v1.1.dtb
+dtb-$(CONFIG_MACH_SUNIV) += \
+ suniv-f1c100s-licheepi-nano.dtb \
+ suniv-f1c200s-lctech-pi.dtb \
+ suniv-f1c200s-popstick-v1.1.dtb
diff --git a/arch/arm/boot/dts/axp152.dtsi b/arch/arm/boot/dts/allwinner/axp152.dtsi
similarity index 100%
rename from arch/arm/boot/dts/axp152.dtsi
rename to arch/arm/boot/dts/allwinner/axp152.dtsi
diff --git a/arch/arm/boot/dts/allwinner/axp209.dtsi b/arch/arm/boot/dts/allwinner/axp209.dtsi
new file mode 100644
index 0000000..469d0f7
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/axp209.dtsi
@@ -0,0 +1,126 @@
+/*
+ * Copyright 2015 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai <wens@csie.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP202/209 Integrated Power Management Chip
+ * http://www.x-powers.com/product/AXP20X.php
+ * http://dl.linux-sunxi.org/AXP/AXP209%20Datasheet%20v1.0_cn.pdf
+ */
+
+/ {
+ pmic-temp {
+ compatible = "iio-hwmon";
+ io-channels = <&axp_adc 4>; /* Internal temperature */
+ };
+};
+
+&axp209 {
+ compatible = "x-powers,axp209";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ ac_power_supply: ac-power {
+ compatible = "x-powers,axp202-ac-power-supply";
+ status = "disabled";
+ };
+
+ axp_adc: adc {
+ compatible = "x-powers,axp209-adc";
+ #io-channel-cells = <1>;
+ };
+
+ axp_gpio: gpio {
+ compatible = "x-powers,axp209-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ battery_power_supply: battery-power {
+ compatible = "x-powers,axp209-battery-power-supply";
+ status = "disabled";
+ };
+
+ regulators {
+ /* Default work frequency for buck regulators */
+ x-powers,dcdc-freq = <1500>;
+
+ reg_dcdc2: dcdc2 {
+ regulator-name = "dcdc2";
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-name = "dcdc3";
+ };
+
+ reg_ldo1: ldo1 {
+ /* LDO1 is a fixed output regulator */
+ regulator-always-on;
+ regulator-min-microvolt = <1300000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "ldo1";
+ };
+
+ reg_ldo2: ldo2 {
+ regulator-name = "ldo2";
+ };
+
+ reg_ldo3: ldo3 {
+ regulator-name = "ldo3";
+ };
+
+ reg_ldo4: ldo4 {
+ regulator-name = "ldo4";
+ };
+
+ reg_ldo5: ldo5 {
+ regulator-name = "ldo5";
+ status = "disabled";
+ };
+ };
+
+ usb_power_supply: usb-power {
+ compatible = "x-powers,axp202-usb-power-supply";
+ status = "disabled";
+ };
+};
diff --git a/arch/arm/boot/dts/axp223.dtsi b/arch/arm/boot/dts/allwinner/axp223.dtsi
similarity index 100%
rename from arch/arm/boot/dts/axp223.dtsi
rename to arch/arm/boot/dts/allwinner/axp223.dtsi
diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/allwinner/axp22x.dtsi
similarity index 100%
rename from arch/arm/boot/dts/axp22x.dtsi
rename to arch/arm/boot/dts/allwinner/axp22x.dtsi
diff --git a/arch/arm/boot/dts/axp809.dtsi b/arch/arm/boot/dts/allwinner/axp809.dtsi
similarity index 100%
rename from arch/arm/boot/dts/axp809.dtsi
rename to arch/arm/boot/dts/allwinner/axp809.dtsi
diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/allwinner/axp81x.dtsi
similarity index 100%
rename from arch/arm/boot/dts/axp81x.dtsi
rename to arch/arm/boot/dts/allwinner/axp81x.dtsi
diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-a1000.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-a1000.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-a1000.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-ba10-tvbox.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-ba10-tvbox.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-chuwi-v7-cw0825.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-chuwi-v7-cw0825.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-cubieboard.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-cubieboard.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-cubieboard.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-dserve-dsrv9703c.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-dserve-dsrv9703c.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-gemei-g9.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-gemei-g9.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-hackberry.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-hackberry.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-hackberry.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-hackberry.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-hyundai-a7hd.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-hyundai-a7hd.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-inet1.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-inet1.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-inet1.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-inet1.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-inet97fv2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-inet97fv2.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-inet9f-rev03.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-inet9f-rev03.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-itead-iteaduino-plus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-itead-iteaduino-plus.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-jesurun-q5.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-jesurun-q5.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-marsboard.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-marsboard.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-marsboard.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-marsboard.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-mini-xplus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-mini-xplus.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-mk802.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-mk802.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-mk802.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-mk802.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-mk802ii.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-mk802ii.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-mk802ii.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-mk802ii.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-olinuxino-lime.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-olinuxino-lime.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-pcduino.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-pcduino.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-pcduino.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino2.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-pcduino2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-pcduino2.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-pcduino2.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-pov-protab2-ips9.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-pov-protab2-ips9.dts
diff --git a/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts b/arch/arm/boot/dts/allwinner/sun4i-a10-topwise-a721.dts
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
rename to arch/arm/boot/dts/allwinner/sun4i-a10-topwise-a721.dts
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/allwinner/sun4i-a10.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun4i-a10.dtsi
rename to arch/arm/boot/dts/allwinner/sun4i-a10.dtsi
diff --git a/arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts b/arch/arm/boot/dts/allwinner/sun5i-a10s-auxtek-t003.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a10s-auxtek-t003.dts
diff --git a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts b/arch/arm/boot/dts/allwinner/sun5i-a10s-auxtek-t004.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a10s-auxtek-t004.dts
diff --git a/arch/arm/boot/dts/sun5i-a10s-mk802.dts b/arch/arm/boot/dts/allwinner/sun5i-a10s-mk802.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a10s-mk802.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a10s-mk802.dts
diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts b/arch/arm/boot/dts/allwinner/sun5i-a10s-olinuxino-micro.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a10s-olinuxino-micro.dts
diff --git a/arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts b/arch/arm/boot/dts/allwinner/sun5i-a10s-r7-tv-dongle.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a10s-r7-tv-dongle.dts
diff --git a/arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts b/arch/arm/boot/dts/allwinner/sun5i-a10s-wobo-i5.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a10s-wobo-i5.dts
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/allwinner/sun5i-a10s.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a10s.dtsi
rename to arch/arm/boot/dts/allwinner/sun5i-a10s.dtsi
diff --git a/arch/arm/boot/dts/sun5i-a13-difrnce-dit4350.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-difrnce-dit4350.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-difrnce-dit4350.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-difrnce-dit4350.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-empire-electronix-d709.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-empire-electronix-d709.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-empire-electronix-m712.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-empire-electronix-m712.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-empire-electronix-m712.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-empire-electronix-m712.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-hsg-h702.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-hsg-h702.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-inet-98v-rev2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-inet-98v-rev2.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-licheepi-one.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-licheepi-one.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-licheepi-one.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-licheepi-one.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-olinuxino-micro.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-olinuxino-micro.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-olinuxino.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-olinuxino.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-olinuxino.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-pocketbook-touch-lux-3.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-touch-lux-3.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-pocketbook-touch-lux-3.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-touch-lux-3.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-q8-tablet.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-q8-tablet.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-q8-tablet.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-q8-tablet.dts
diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-utoo-p66.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
rename to arch/arm/boot/dts/allwinner/sun5i-a13-utoo-p66.dts
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/allwinner/sun5i-a13.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun5i-a13.dtsi
rename to arch/arm/boot/dts/allwinner/sun5i-a13.dtsi
diff --git a/arch/arm/boot/dts/sun5i-gr8-chip-pro.dts b/arch/arm/boot/dts/allwinner/sun5i-gr8-chip-pro.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-gr8-chip-pro.dts
rename to arch/arm/boot/dts/allwinner/sun5i-gr8-chip-pro.dts
diff --git a/arch/arm/boot/dts/sun5i-gr8-evb.dts b/arch/arm/boot/dts/allwinner/sun5i-gr8-evb.dts
similarity index 100%
rename from arch/arm/boot/dts/sun5i-gr8-evb.dts
rename to arch/arm/boot/dts/allwinner/sun5i-gr8-evb.dts
diff --git a/arch/arm/boot/dts/sun5i-gr8.dtsi b/arch/arm/boot/dts/allwinner/sun5i-gr8.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun5i-gr8.dtsi
rename to arch/arm/boot/dts/allwinner/sun5i-gr8.dtsi
diff --git a/arch/arm/boot/dts/allwinner/sun5i-r8-chip.dts b/arch/arm/boot/dts/allwinner/sun5i-r8-chip.dts
new file mode 100644
index 0000000..4192c23
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun5i-r8-chip.dts
@@ -0,0 +1,282 @@
+/*
+ * Copyright 2015 Free Electrons
+ * Copyright 2015 NextThing Co
+ *
+ * Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun5i-r8.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ model = "NextThing C.H.I.P.";
+ compatible = "nextthing,chip", "allwinner,sun5i-r8", "allwinner,sun5i-a13";
+
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ serial0 = &uart1;
+ serial1 = &uart3;
+ spi0 = &spi2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "chip:white:status";
+ gpios = <&axp_gpio 2 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ mmc0_pwrseq: mmc0_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&pio 2 19 GPIO_ACTIVE_LOW>; /* PC19 */
+ };
+
+ onewire {
+ compatible = "w1-gpio";
+ gpios = <&pio 3 2 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PD2 */
+ };
+};
+
+&be0 {
+ status = "okay";
+};
+
+&codec {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ axp209: pmic@34 {
+ reg = <0x34>;
+
+ /*
+ * The interrupt is routed through the "External Fast
+ * Interrupt Request" pin (ball G13 of the module)
+ * directly to the main interrupt controller, without
+ * any other controller interfering.
+ */
+ interrupts = <0>;
+ };
+};
+
+#include "axp209.dtsi"
+
+&ac_power_supply {
+ status = "okay";
+};
+
+&battery_power_supply {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "disabled";
+};
+
+&i2c2 {
+ status = "okay";
+
+ xio: gpio@38 {
+ compatible = "nxp,pcf8574a";
+ reg = <0x38>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-parent = <&pio>;
+ interrupts = <6 0 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
+
+&mmc0_pins {
+ bias-pull-up;
+};
+
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ mmc-pwrseq = <&mmc0_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+®_dcdc2 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "cpuvdd";
+ regulator-always-on;
+};
+
+®_dcdc3 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "corevdd";
+ regulator-always-on;
+};
+
+®_ldo1 {
+ regulator-name = "rtcvdd";
+};
+
+®_ldo2 {
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "avcc";
+ regulator-always-on;
+};
+
+/*
+ * Both LDO3 and LDO4 are used in parallel to power up the WiFi/BT
+ * Chip.
+ *
+ * If those are not enabled, the SDIO part will not enumerate, and
+ * since there's no way currently to pass DT infos to an SDIO device,
+ * we cannot really do better than this ugly hack for now.
+ */
+®_ldo3 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi-1";
+ regulator-always-on;
+};
+
+®_ldo4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi-2";
+ regulator-always-on;
+};
+
+®_ldo5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc-1v8";
+};
+
+®_usb0_vbus {
+ vin-supply = <®_vcc5v0>;
+ gpio = <&pio 1 10 GPIO_ACTIVE_HIGH>; /* PB10 */
+ status = "okay";
+};
+
+&spi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi2_pe_pins>;
+ status = "disabled";
+};
+
+&tcon0 {
+ status = "okay";
+};
+
+&tve0 {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pg_pins>;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pg_pins>,
+ <&uart3_cts_rts_pg_pins>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "realtek,rtl8723bs-bt";
+ device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_HIGH>;
+ host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ };
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usb_power_supply {
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+
+ usb0_id_det-gpios = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
+ usb0_vbus_power-supply = <&usb_power_supply>;
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_vcc5v0>;
+};
diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/allwinner/sun5i-r8.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun5i-r8.dtsi
rename to arch/arm/boot/dts/allwinner/sun5i-r8.dtsi
diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/allwinner/sun5i-reference-design-tablet.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
rename to arch/arm/boot/dts/allwinner/sun5i-reference-design-tablet.dtsi
diff --git a/arch/arm/boot/dts/allwinner/sun5i.dtsi b/arch/arm/boot/dts/allwinner/sun5i.dtsi
new file mode 100644
index 0000000..d7c7b45
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun5i.dtsi
@@ -0,0 +1,819 @@
+/*
+ * Copyright 2012-2015 Maxime Ripard
+ *
+ * Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/clock/sun5i-ccu.h>
+#include <dt-bindings/dma/sun4i-a10.h>
+#include <dt-bindings/reset/sun5i-ccu.h>
+
+/ {
+ interrupt-parent = <&intc>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a8";
+ reg = <0x0>;
+ clocks = <&ccu CLK_CPU>;
+ };
+ };
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer-lcd0 {
+ compatible = "allwinner,simple-framebuffer",
+ "simple-framebuffer";
+ allwinner,pipeline = "de_be0-lcd0";
+ clocks = <&ccu CLK_AHB_LCD>, <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
+ <&ccu CLK_TCON_CH0>, <&ccu CLK_DRAM_DE_BE>;
+ status = "disabled";
+ };
+
+ framebuffer-lcd0-tve0 {
+ compatible = "allwinner,simple-framebuffer",
+ "simple-framebuffer";
+ allwinner,pipeline = "de_be0-lcd0-tve0";
+ clocks = <&ccu CLK_AHB_TVE>, <&ccu CLK_AHB_LCD>,
+ <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
+ <&ccu CLK_TCON_CH1>, <&ccu CLK_DRAM_DE_BE>;
+ status = "disabled";
+ };
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc24M: clk-24M {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "osc24M";
+ };
+
+ osc32k: clk-32k {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "osc32k";
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+ default-pool {
+ compatible = "shared-dma-pool";
+ size = <0x6000000>;
+ alloc-ranges = <0x40000000 0x10000000>;
+ reusable;
+ linux,cma-default;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges;
+ ranges;
+
+ system-control@1c00000 {
+ compatible = "allwinner,sun5i-a13-system-control";
+ reg = <0x01c00000 0x30>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ sram_a: sram@0 {
+ compatible = "mmio-sram";
+ reg = <0x00000000 0xc000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x00000000 0xc000>;
+
+ emac_sram: sram-section@8000 {
+ compatible = "allwinner,sun5i-a13-sram-a3-a4",
+ "allwinner,sun4i-a10-sram-a3-a4";
+ reg = <0x8000 0x4000>;
+ status = "disabled";
+ };
+ };
+
+ sram_d: sram@10000 {
+ compatible = "mmio-sram";
+ reg = <0x00010000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x00010000 0x1000>;
+
+ otg_sram: sram-section@0 {
+ compatible = "allwinner,sun5i-a13-sram-d",
+ "allwinner,sun4i-a10-sram-d";
+ reg = <0x0000 0x1000>;
+ status = "disabled";
+ };
+ };
+
+ sram_c: sram@1d00000 {
+ compatible = "mmio-sram";
+ reg = <0x01d00000 0xd0000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x01d00000 0xd0000>;
+
+ ve_sram: sram-section@0 {
+ compatible = "allwinner,sun5i-a13-sram-c1",
+ "allwinner,sun4i-a10-sram-c1";
+ reg = <0x000000 0x80000>;
+ };
+ };
+ };
+
+ mbus: dram-controller@1c01000 {
+ compatible = "allwinner,sun5i-a13-mbus";
+ reg = <0x01c01000 0x1000>;
+ clocks = <&ccu CLK_MBUS>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x00000000 0x40000000 0x20000000>;
+ #interconnect-cells = <1>;
+ };
+
+ dma: dma-controller@1c02000 {
+ compatible = "allwinner,sun4i-a10-dma";
+ reg = <0x01c02000 0x1000>;
+ interrupts = <27>;
+ clocks = <&ccu CLK_AHB_DMA>;
+ #dma-cells = <2>;
+ };
+
+ nfc: nand-controller@1c03000 {
+ compatible = "allwinner,sun4i-a10-nand";
+ reg = <0x01c03000 0x1000>;
+ interrupts = <37>;
+ clocks = <&ccu CLK_AHB_NAND>, <&ccu CLK_NAND>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma SUN4I_DMA_DEDICATED 3>;
+ dma-names = "rxtx";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ spi0: spi@1c05000 {
+ compatible = "allwinner,sun4i-a10-spi";
+ reg = <0x01c05000 0x1000>;
+ interrupts = <10>;
+ clocks = <&ccu CLK_AHB_SPI0>, <&ccu CLK_SPI0>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma SUN4I_DMA_DEDICATED 27>,
+ <&dma SUN4I_DMA_DEDICATED 26>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ spi1: spi@1c06000 {
+ compatible = "allwinner,sun4i-a10-spi";
+ reg = <0x01c06000 0x1000>;
+ interrupts = <11>;
+ clocks = <&ccu CLK_AHB_SPI1>, <&ccu CLK_SPI1>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma SUN4I_DMA_DEDICATED 9>,
+ <&dma SUN4I_DMA_DEDICATED 8>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ tve0: tv-encoder@1c0a000 {
+ compatible = "allwinner,sun4i-a10-tv-encoder";
+ reg = <0x01c0a000 0x1000>;
+ clocks = <&ccu CLK_AHB_TVE>;
+ resets = <&ccu RST_TVE>;
+ status = "disabled";
+
+ port {
+
+ tve0_in_tcon0: endpoint {
+ remote-endpoint = <&tcon0_out_tve0>;
+ };
+ };
+ };
+
+ emac: ethernet@1c0b000 {
+ compatible = "allwinner,sun4i-a10-emac";
+ reg = <0x01c0b000 0x1000>;
+ interrupts = <55>;
+ clocks = <&ccu CLK_AHB_EMAC>;
+ allwinner,sram = <&emac_sram 1>;
+ status = "disabled";
+ };
+
+ mdio: mdio@1c0b080 {
+ compatible = "allwinner,sun4i-a10-mdio";
+ reg = <0x01c0b080 0x14>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ tcon0: lcd-controller@1c0c000 {
+ compatible = "allwinner,sun5i-a13-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = <44>;
+ dmas = <&dma SUN4I_DMA_DEDICATED 14>;
+ resets = <&ccu RST_LCD>;
+ reset-names = "lcd";
+ clocks = <&ccu CLK_AHB_LCD>,
+ <&ccu CLK_TCON_CH0>,
+ <&ccu CLK_TCON_CH1>;
+ clock-names = "ahb",
+ "tcon-ch0",
+ "tcon-ch1";
+ clock-output-names = "tcon-data-clock";
+ #clock-cells = <0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ reg = <0>;
+
+ tcon0_in_be0: endpoint {
+ remote-endpoint = <&be0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon0_out_tve0: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&tve0_in_tcon0>;
+ allwinner,tcon-channel = <1>;
+ };
+ };
+ };
+ };
+
+ video-codec@1c0e000 {
+ compatible = "allwinner,sun5i-a13-video-engine";
+ reg = <0x01c0e000 0x1000>;
+ clocks = <&ccu CLK_AHB_VE>, <&ccu CLK_VE>,
+ <&ccu CLK_DRAM_VE>;
+ clock-names = "ahb", "mod", "ram";
+ resets = <&ccu RST_VE>;
+ interrupts = <53>;
+ allwinner,sram = <&ve_sram 1>;
+ };
+
+ mmc0: mmc@1c0f000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ccu CLK_AHB_MMC0>, <&ccu CLK_MMC0>;
+ clock-names = "ahb", "mmc";
+ interrupts = <32>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@1c10000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ccu CLK_AHB_MMC1>, <&ccu CLK_MMC1>;
+ clock-names = "ahb", "mmc";
+ interrupts = <33>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@1c11000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ccu CLK_AHB_MMC2>, <&ccu CLK_MMC2>;
+ clock-names = "ahb", "mmc";
+ interrupts = <34>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ usb_otg: usb@1c13000 {
+ compatible = "allwinner,sun4i-a10-musb";
+ reg = <0x01c13000 0x0400>;
+ clocks = <&ccu CLK_AHB_OTG>;
+ interrupts = <38>;
+ interrupt-names = "mc";
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ extcon = <&usbphy 0>;
+ allwinner,sram = <&otg_sram 1>;
+ dr_mode = "otg";
+ status = "disabled";
+ };
+
+ usbphy: phy@1c13400 {
+ #phy-cells = <1>;
+ compatible = "allwinner,sun5i-a13-usb-phy";
+ reg = <0x01c13400 0x10>, <0x01c14800 0x4>;
+ reg-names = "phy_ctrl", "pmu1";
+ clocks = <&ccu CLK_USB_PHY0>;
+ clock-names = "usb_phy";
+ resets = <&ccu RST_USB_PHY0>, <&ccu RST_USB_PHY1>;
+ reset-names = "usb0_reset", "usb1_reset";
+ status = "disabled";
+ };
+
+ ehci0: usb@1c14000 {
+ compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
+ reg = <0x01c14000 0x100>;
+ interrupts = <39>;
+ clocks = <&ccu CLK_AHB_EHCI>;
+ phys = <&usbphy 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ohci0: usb@1c14400 {
+ compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
+ reg = <0x01c14400 0x100>;
+ interrupts = <40>;
+ clocks = <&ccu CLK_USB_OHCI>, <&ccu CLK_AHB_OHCI>;
+ phys = <&usbphy 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ crypto: crypto-engine@1c15000 {
+ compatible = "allwinner,sun5i-a13-crypto",
+ "allwinner,sun4i-a10-crypto";
+ reg = <0x01c15000 0x1000>;
+ interrupts = <54>;
+ clocks = <&ccu CLK_AHB_SS>, <&ccu CLK_SS>;
+ clock-names = "ahb", "mod";
+ };
+
+ spi2: spi@1c17000 {
+ compatible = "allwinner,sun4i-a10-spi";
+ reg = <0x01c17000 0x1000>;
+ interrupts = <12>;
+ clocks = <&ccu CLK_AHB_SPI2>, <&ccu CLK_SPI2>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma SUN4I_DMA_DEDICATED 29>,
+ <&dma SUN4I_DMA_DEDICATED 28>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ ccu: clock@1c20000 {
+ reg = <0x01c20000 0x400>;
+ clocks = <&osc24M>, <&osc32k>;
+ clock-names = "hosc", "losc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ intc: interrupt-controller@1c20400 {
+ compatible = "allwinner,sun4i-a10-ic";
+ reg = <0x01c20400 0x400>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ pio: pinctrl@1c20800 {
+ reg = <0x01c20800 0x400>;
+ interrupts = <28>;
+ clocks = <&ccu CLK_APB0_PIO>, <&osc24M>, <&osc32k>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #gpio-cells = <3>;
+
+ emac_pd_pins: emac-pd-pins {
+ pins = "PD6", "PD7", "PD10",
+ "PD11", "PD12", "PD13", "PD14",
+ "PD15", "PD18", "PD19", "PD20",
+ "PD21", "PD22", "PD23", "PD24",
+ "PD25", "PD26", "PD27";
+ function = "emac";
+ };
+
+ i2c0_pins: i2c0-pins {
+ pins = "PB0", "PB1";
+ function = "i2c0";
+ };
+
+ i2c1_pins: i2c1-pins {
+ pins = "PB15", "PB16";
+ function = "i2c1";
+ };
+
+ i2c2_pins: i2c2-pins {
+ pins = "PB17", "PB18";
+ function = "i2c2";
+ };
+
+ ir0_rx_pin: ir0-rx-pin {
+ pins = "PB4";
+ function = "ir0";
+ };
+
+ lcd_rgb565_pins: lcd-rgb565-pins {
+ pins = "PD3", "PD4", "PD5", "PD6", "PD7",
+ "PD10", "PD11", "PD12", "PD13", "PD14", "PD15",
+ "PD19", "PD20", "PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ function = "lcd0";
+ };
+
+ lcd_rgb666_pins: lcd-rgb666-pins {
+ pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
+ "PD10", "PD11", "PD12", "PD13", "PD14", "PD15",
+ "PD18", "PD19", "PD20", "PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ function = "lcd0";
+ };
+
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2", "PF3",
+ "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc2_4bit_pc_pins: mmc2-4bit-pc-pins {
+ pins = "PC6", "PC7", "PC8", "PC9",
+ "PC10", "PC11";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ /omit-if-no-ref/
+ mmc2_4bit_pe_pins: mmc2-4bit-pe-pins {
+ pins = "PE4", "PE5", "PE6", "PE7",
+ "PE8", "PE9";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc2_8bit_pins: mmc2-8bit-pins {
+ pins = "PC6", "PC7", "PC8", "PC9",
+ "PC10", "PC11", "PC12", "PC13",
+ "PC14", "PC15";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ nand_pins: nand-pins {
+ pins = "PC0", "PC1", "PC2",
+ "PC5", "PC8", "PC9", "PC10",
+ "PC11", "PC12", "PC13", "PC14",
+ "PC15";
+ function = "nand0";
+ };
+
+ nand_cs0_pin: nand-cs0-pin {
+ pins = "PC4";
+ function = "nand0";
+ };
+
+ nand_rb0_pin: nand-rb0-pin {
+ pins = "PC6";
+ function = "nand0";
+ };
+
+ pwm0_pin: pwm0-pin {
+ pins = "PB2";
+ function = "pwm";
+ };
+
+ spi2_pe_pins: spi2-pe-pins {
+ pins = "PE1", "PE2", "PE3";
+ function = "spi2";
+ };
+
+ spi2_cs0_pe_pin: spi2-cs0-pe-pin {
+ pins = "PE0";
+ function = "spi2";
+ };
+
+ uart1_pe_pins: uart1-pe-pins {
+ pins = "PE10", "PE11";
+ function = "uart1";
+ };
+
+ uart1_pg_pins: uart1-pg-pins {
+ pins = "PG3", "PG4";
+ function = "uart1";
+ };
+
+ uart2_pd_pins: uart2-pd-pins {
+ pins = "PD2", "PD3";
+ function = "uart2";
+ };
+
+ uart2_cts_rts_pd_pins: uart2-cts-rts-pd-pins {
+ pins = "PD4", "PD5";
+ function = "uart2";
+ };
+
+ uart3_pg_pins: uart3-pg-pins {
+ pins = "PG9", "PG10";
+ function = "uart3";
+ };
+
+ uart3_cts_rts_pg_pins: uart3-cts-rts-pg-pins {
+ pins = "PG11", "PG12";
+ function = "uart3";
+ };
+ };
+
+ timer@1c20c00 {
+ compatible = "allwinner,sun4i-a10-timer";
+ reg = <0x01c20c00 0x90>;
+ interrupts = <22>,
+ <23>,
+ <24>,
+ <25>,
+ <67>,
+ <68>;
+ clocks = <&ccu CLK_HOSC>;
+ };
+
+ wdt: watchdog@1c20c90 {
+ compatible = "allwinner,sun4i-a10-wdt";
+ reg = <0x01c20c90 0x10>;
+ interrupts = <24>;
+ clocks = <&osc24M>;
+ };
+
+ ir0: ir@1c21800 {
+ compatible = "allwinner,sun4i-a10-ir";
+ clocks = <&ccu CLK_APB0_IR>, <&ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ interrupts = <5>;
+ reg = <0x01c21800 0x40>;
+ status = "disabled";
+ };
+
+ lradc: lradc@1c22800 {
+ compatible = "allwinner,sun4i-a10-lradc-keys";
+ reg = <0x01c22800 0x100>;
+ interrupts = <31>;
+ status = "disabled";
+ };
+
+ codec: codec@1c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun4i-a10-codec";
+ reg = <0x01c22c00 0x40>;
+ interrupts = <30>;
+ clocks = <&ccu CLK_APB0_CODEC>, <&ccu CLK_CODEC>;
+ clock-names = "apb", "codec";
+ dmas = <&dma SUN4I_DMA_NORMAL 19>,
+ <&dma SUN4I_DMA_NORMAL 19>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ sid: eeprom@1c23800 {
+ compatible = "allwinner,sun4i-a10-sid";
+ reg = <0x01c23800 0x10>;
+ };
+
+ rtp: rtp@1c25000 {
+ compatible = "allwinner,sun5i-a13-ts";
+ reg = <0x01c25000 0x100>;
+ interrupts = <29>;
+ #thermal-sensor-cells = <0>;
+ };
+
+ uart0: serial@1c28000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28000 0x400>;
+ interrupts = <1>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_APB1_UART0>;
+ status = "disabled";
+ };
+
+ uart1: serial@1c28400 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28400 0x400>;
+ interrupts = <2>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_APB1_UART1>;
+ status = "disabled";
+ };
+
+ uart2: serial@1c28800 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28800 0x400>;
+ interrupts = <3>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_APB1_UART2>;
+ status = "disabled";
+ };
+
+ uart3: serial@1c28c00 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28c00 0x400>;
+ interrupts = <4>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_APB1_UART3>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@1c2ac00 {
+ compatible = "allwinner,sun4i-a10-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <7>;
+ clocks = <&ccu CLK_APB1_I2C0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@1c2b000 {
+ compatible = "allwinner,sun4i-a10-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <8>;
+ clocks = <&ccu CLK_APB1_I2C1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c@1c2b400 {
+ compatible = "allwinner,sun4i-a10-i2c";
+ reg = <0x01c2b400 0x400>;
+ interrupts = <9>;
+ clocks = <&ccu CLK_APB1_I2C2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mali: gpu@1c40000 {
+ compatible = "allwinner,sun4i-a10-mali", "arm,mali-400";
+ reg = <0x01c40000 0x10000>;
+ interrupts = <69>, <70>, <71>, <72>, <73>;
+ interrupt-names = "gp", "gpmmu", "pp0", "ppmmu0", "pmu";
+ clocks = <&ccu CLK_AHB_GPU>, <&ccu CLK_GPU>;
+ clock-names = "bus", "core";
+ resets = <&ccu RST_GPU>;
+ assigned-clocks = <&ccu CLK_GPU>;
+ assigned-clock-rates = <320000000>;
+ };
+
+ timer@1c60000 {
+ compatible = "allwinner,sun5i-a13-hstimer";
+ reg = <0x01c60000 0x1000>;
+ interrupts = <82>, <83>;
+ clocks = <&ccu CLK_AHB_HSTIMER>;
+ };
+
+ fe0: display-frontend@1e00000 {
+ compatible = "allwinner,sun5i-a13-display-frontend";
+ reg = <0x01e00000 0x20000>;
+ interrupts = <47>;
+ clocks = <&ccu CLK_DE_FE>, <&ccu CLK_DE_FE>,
+ <&ccu CLK_DRAM_DE_FE>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_DE_FE>;
+ interconnects = <&mbus 19>;
+ interconnect-names = "dma-mem";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fe0_out: port@1 {
+ reg = <1>;
+
+ fe0_out_be0: endpoint {
+ remote-endpoint = <&be0_in_fe0>;
+ };
+ };
+ };
+ };
+
+ be0: display-backend@1e60000 {
+ compatible = "allwinner,sun5i-a13-display-backend";
+ reg = <0x01e60000 0x10000>;
+ interrupts = <47>;
+ clocks = <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
+ <&ccu CLK_DRAM_DE_BE>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_DE_BE>;
+ interconnects = <&mbus 18>;
+ interconnect-names = "dma-mem";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ be0_in: port@0 {
+ reg = <0>;
+
+ be0_in_fe0: endpoint {
+ remote-endpoint = <&fe0_out_be0>;
+ };
+ };
+
+ be0_out: port@1 {
+ reg = <1>;
+
+ be0_out_tcon0: endpoint {
+ remote-endpoint = <&tcon0_in_be0>;
+ };
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts b/arch/arm/boot/dts/allwinner/sun6i-a31-app4-evb1.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31-app4-evb1.dts
diff --git a/arch/arm/boot/dts/sun6i-a31-colombus.dts b/arch/arm/boot/dts/allwinner/sun6i-a31-colombus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31-colombus.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31-colombus.dts
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/allwinner/sun6i-a31-hummingbird.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31-hummingbird.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31-hummingbird.dts
diff --git a/arch/arm/boot/dts/sun6i-a31-i7.dts b/arch/arm/boot/dts/allwinner/sun6i-a31-i7.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31-i7.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31-i7.dts
diff --git a/arch/arm/boot/dts/sun6i-a31-m9.dts b/arch/arm/boot/dts/allwinner/sun6i-a31-m9.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31-m9.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31-m9.dts
diff --git a/arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts b/arch/arm/boot/dts/allwinner/sun6i-a31-mele-a1000g-quad.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31-mele-a1000g-quad.dts
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31.dtsi
rename to arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
diff --git a/arch/arm/boot/dts/sun6i-a31s-colorfly-e708-q1.dts b/arch/arm/boot/dts/allwinner/sun6i-a31s-colorfly-e708-q1.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31s-colorfly-e708-q1.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31s-colorfly-e708-q1.dts
diff --git a/arch/arm/boot/dts/sun6i-a31s-cs908.dts b/arch/arm/boot/dts/allwinner/sun6i-a31s-cs908.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31s-cs908.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31s-cs908.dts
diff --git a/arch/arm/boot/dts/sun6i-a31s-inet-q972.dts b/arch/arm/boot/dts/allwinner/sun6i-a31s-inet-q972.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31s-inet-q972.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31s-inet-q972.dts
diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts b/arch/arm/boot/dts/allwinner/sun6i-a31s-primo81.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31s-primo81.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31s-primo81.dts
diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi b/arch/arm/boot/dts/allwinner/sun6i-a31s-sina31s-core.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi
rename to arch/arm/boot/dts/allwinner/sun6i-a31s-sina31s-core.dtsi
diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts b/arch/arm/boot/dts/allwinner/sun6i-a31s-sina31s.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31s-sina31s.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31s-sina31s.dts
diff --git a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts b/arch/arm/boot/dts/allwinner/sun6i-a31s-sinovoip-bpi-m2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31s-sinovoip-bpi-m2.dts
diff --git a/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts b/arch/arm/boot/dts/allwinner/sun6i-a31s-yones-toptech-bs1078-v2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
rename to arch/arm/boot/dts/allwinner/sun6i-a31s-yones-toptech-bs1078-v2.dts
diff --git a/arch/arm/boot/dts/sun6i-a31s.dtsi b/arch/arm/boot/dts/allwinner/sun6i-a31s.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun6i-a31s.dtsi
rename to arch/arm/boot/dts/allwinner/sun6i-a31s.dtsi
diff --git a/arch/arm/boot/dts/sun6i-reference-design-tablet.dtsi b/arch/arm/boot/dts/allwinner/sun6i-reference-design-tablet.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun6i-reference-design-tablet.dtsi
rename to arch/arm/boot/dts/allwinner/sun6i-reference-design-tablet.dtsi
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-bananapi-m1-plus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-bananapi-m1-plus.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-bananapi.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-bananapi.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-bananapi.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-bananapro.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-bananapro.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-bananapro.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-cubieboard2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-cubieboard2.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-cubietruck.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-cubietruck.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-cubietruck.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-haoyu-marsboard.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-haoyu-marsboard.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-haoyu-marsboard.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-haoyu-marsboard.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-hummingbird.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-hummingbird.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-hummingbird.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-hummingbird.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-i12-tvbox.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-i12-tvbox.dts
diff --git a/arch/arm/boot/dts/allwinner/sun7i-a20-icnova-a20-adb4006.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-icnova-a20-adb4006.dts
new file mode 100644
index 0000000..577ead1
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun7i-a20-icnova-a20-adb4006.dts
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+// Copyright (C) 2023 In-Circuit GmbH
+
+/dts-v1/;
+
+#include "sun7i-a20-icnova-a20.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "In-Circuit ICnova A20 ADB4006";
+ compatible = "incircuit,icnova-a20-adb4006", "incircuit,icnova-a20",
+ "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ function = LED_FUNCTION_POWER;
+ color = <LED_COLOR_ID_YELLOW>;
+ gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; /* PH21 */
+ default-state = "on";
+ };
+
+ led-1 {
+ function = LED_FUNCTION_HEARTBEAT;
+ color = <LED_COLOR_ID_RED>;
+ gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&ahci {
+ target-supply = <®_ahci_5v>;
+ status = "okay";
+};
+
+&codec {
+ status = "okay";
+};
+
+&de {
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+®_ahci_5v {
+ status = "okay";
+};
+
+&ac_power_supply {
+ status = "okay";
+};
+
+®_usb1_vbus {
+ status = "okay";
+};
+
+®_usb2_vbus {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+ usb1_vbus-supply = <®_usb1_vbus>;
+ usb2_vbus-supply = <®_usb2_vbus>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/allwinner/sun7i-a20-icnova-a20.dtsi b/arch/arm/boot/dts/allwinner/sun7i-a20-icnova-a20.dtsi
new file mode 100644
index 0000000..46616c6
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun7i-a20-icnova-a20.dtsi
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+// Copyright (C) 2023 In-Circuit GmbH
+
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&gmac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_mii_pins>;
+ phy-handle = <&phy1>;
+ phy-mode = "mii";
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ axp209: pmic@34 {
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
+#include "axp209.dtsi"
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-icnova-swac.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-icnova-swac.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-itead-ibox.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-itead-ibox.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-lamobo-r1.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-lamobo-r1.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-linutronix-testbox-v2.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-linutronix-testbox-v2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-linutronix-testbox-v2.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-linutronix-testbox-v2.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-m3.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-m3.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-m3.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-m3.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-mk808c.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-mk808c.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-mk808c.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-mk808c.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olimex-som-evb-emmc.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olimex-som-evb-emmc.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olimex-som-evb.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olimex-som-evb.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som204-evb-emmc.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olimex-som204-evb-emmc.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olimex-som204-evb-emmc.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olimex-som204-evb-emmc.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som204-evb.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olimex-som204-evb.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olimex-som204-evb.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olimex-som204-evb.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime-emmc.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-lime-emmc.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olinuxino-lime-emmc.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-lime-emmc.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-lime.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-lime.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-lime2-emmc.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-lime2-emmc.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-lime2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-lime2.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro-emmc.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-micro-emmc.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olinuxino-micro-emmc.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-micro-emmc.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-micro.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-olinuxino-micro.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-orangepi-mini.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-orangepi-mini.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-orangepi.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-orangepi.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-orangepi.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-orangepi.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-pcduino3-nano.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-pcduino3-nano.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-pcduino3.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-pcduino3.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-pcduino3.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-wexler-tab7200.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-wexler-tab7200.dts
diff --git a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts b/arch/arm/boot/dts/allwinner/sun7i-a20-wits-pro-a20-dkt.dts
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
rename to arch/arm/boot/dts/allwinner/sun7i-a20-wits-pro-a20-dkt.dts
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/allwinner/sun7i-a20.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun7i-a20.dtsi
rename to arch/arm/boot/dts/allwinner/sun7i-a20.dtsi
diff --git a/arch/arm/boot/dts/allwinner/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/allwinner/sun8i-a23-a33.dtsi
new file mode 100644
index 0000000..cd4bf60
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun8i-a23-a33.dtsi
@@ -0,0 +1,855 @@
+/*
+ * Copyright 2014 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai <wens@csie.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+#include <dt-bindings/clock/sun6i-rtc.h>
+#include <dt-bindings/clock/sun8i-a23-a33-ccu.h>
+#include <dt-bindings/reset/sun8i-a23-a33-ccu.h>
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ simplefb_lcd: framebuffer-lcd0 {
+ compatible = "allwinner,simple-framebuffer",
+ "simple-framebuffer";
+ allwinner,pipeline = "de_be0-lcd0";
+ clocks = <&ccu CLK_BUS_LCD>, <&ccu CLK_BUS_DE_BE>,
+ <&ccu CLK_LCD_CH0>, <&ccu CLK_DE_BE>,
+ <&ccu CLK_DRAM_DE_BE>, <&ccu CLK_DRC>;
+ status = "disabled";
+ };
+ };
+
+ de: display-engine {
+ /* compatible gets set in SoC specific dtsi file */
+ allwinner,pipelines = <&fe0>;
+ status = "disabled";
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ clock-frequency = <24000000>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
+ cpus {
+ enable-method = "allwinner,sun8i-a23";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <1>;
+ };
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc24M: osc24M_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-accuracy = <50000>;
+ clock-output-names = "osc24M";
+ };
+
+ ext_osc32k: ext_osc32k_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-accuracy = <50000>;
+ clock-output-names = "ext-osc32k";
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ system-control@1c00000 {
+ compatible = "allwinner,sun8i-a23-system-control";
+ reg = <0x01c00000 0x30>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ sram_c: sram@1d00000 {
+ compatible = "mmio-sram";
+ reg = <0x01d00000 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x01d00000 0x80000>;
+
+ ve_sram: sram-section@0 {
+ compatible = "allwinner,sun8i-a23-sram-c1",
+ "allwinner,sun4i-a10-sram-c1";
+ reg = <0x000000 0x80000>;
+ };
+ };
+ };
+
+ dma: dma-controller@1c02000 {
+ compatible = "allwinner,sun8i-a23-dma";
+ reg = <0x01c02000 0x1000>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_DMA>;
+ resets = <&ccu RST_BUS_DMA>;
+ #dma-cells = <1>;
+ };
+
+ nfc: nand-controller@1c03000 {
+ compatible = "allwinner,sun8i-a23-nand-controller";
+ reg = <0x01c03000 0x1000>;
+ interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_NAND>, <&ccu CLK_NAND>;
+ clock-names = "ahb", "mod";
+ resets = <&ccu RST_BUS_NAND>;
+ reset-names = "ahb";
+ dmas = <&dma 5>;
+ dma-names = "rxtx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_pins &nand_cs0_pin &nand_rb0_pin>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ tcon0: lcd-controller@1c0c000 {
+ /* compatible gets set in SoC specific dtsi file */
+ reg = <0x01c0c000 0x1000>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma 12>;
+ clocks = <&ccu CLK_BUS_LCD>,
+ <&ccu CLK_LCD_CH0>,
+ <&ccu 13>;
+ clock-names = "ahb",
+ "tcon-ch0",
+ "lvds-alt";
+ clock-output-names = "tcon-data-clock";
+ #clock-cells = <0>;
+ resets = <&ccu RST_BUS_LCD>,
+ <&ccu RST_BUS_LVDS>;
+ reset-names = "lcd",
+ "lvds";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ reg = <0>;
+
+ tcon0_in_drc0: endpoint {
+ remote-endpoint = <&drc0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ mmc0: mmc@1c0f000 {
+ compatible = "allwinner,sun7i-a20-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>,
+ <&ccu CLK_MMC0>,
+ <&ccu CLK_MMC0_OUTPUT>,
+ <&ccu CLK_MMC0_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@1c10000 {
+ compatible = "allwinner,sun7i-a20-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>,
+ <&ccu CLK_MMC1>,
+ <&ccu CLK_MMC1_OUTPUT>,
+ <&ccu CLK_MMC1_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC1>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@1c11000 {
+ compatible = "allwinner,sun7i-a20-mmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC2>,
+ <&ccu CLK_MMC2>,
+ <&ccu CLK_MMC2_OUTPUT>,
+ <&ccu CLK_MMC2_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC2>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ usb_otg: usb@1c19000 {
+ /* compatible gets set in SoC specific dtsi file */
+ reg = <0x01c19000 0x0400>;
+ clocks = <&ccu CLK_BUS_OTG>;
+ resets = <&ccu RST_BUS_OTG>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mc";
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ extcon = <&usbphy 0>;
+ dr_mode = "otg";
+ status = "disabled";
+ };
+
+ usbphy: phy@1c19400 {
+ /*
+ * compatible and address regions get set in
+ * SoC specific dtsi file
+ */
+ clocks = <&ccu CLK_USB_PHY0>,
+ <&ccu CLK_USB_PHY1>;
+ clock-names = "usb0_phy",
+ "usb1_phy";
+ resets = <&ccu RST_USB_PHY0>,
+ <&ccu RST_USB_PHY1>;
+ reset-names = "usb0_reset",
+ "usb1_reset";
+ status = "disabled";
+ #phy-cells = <1>;
+ };
+
+ ehci0: usb@1c1a000 {
+ compatible = "allwinner,sun8i-a23-ehci", "generic-ehci";
+ reg = <0x01c1a000 0x100>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_EHCI>;
+ resets = <&ccu RST_BUS_EHCI>;
+ phys = <&usbphy 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ohci0: usb@1c1a400 {
+ compatible = "allwinner,sun8i-a23-ohci", "generic-ohci";
+ reg = <0x01c1a400 0x100>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_OHCI>, <&ccu CLK_USB_OHCI>;
+ resets = <&ccu RST_BUS_OHCI>;
+ phys = <&usbphy 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ccu: clock@1c20000 {
+ reg = <0x01c20000 0x400>;
+ clocks = <&osc24M>, <&rtc CLK_OSC32K>;
+ clock-names = "hosc", "losc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ pio: pinctrl@1c20800 {
+ /* compatible gets set in SoC specific dtsi file */
+ reg = <0x01c20800 0x400>;
+ interrupt-parent = <&r_intc>;
+ /* interrupts get set in SoC specific dtsi file */
+ clocks = <&ccu CLK_BUS_PIO>, <&osc24M>,
+ <&rtc CLK_OSC32K>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #gpio-cells = <3>;
+
+ i2c0_pins: i2c0-pins {
+ pins = "PH2", "PH3";
+ function = "i2c0";
+ };
+
+ i2c1_pins: i2c1-pins {
+ pins = "PH4", "PH5";
+ function = "i2c1";
+ };
+
+ i2c2_pins: i2c2-pins {
+ pins = "PE12", "PE13";
+ function = "i2c2";
+ };
+
+ lcd_rgb666_pins: lcd-rgb666-pins {
+ pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
+ "PD10", "PD11", "PD12", "PD13", "PD14", "PD15",
+ "PD18", "PD19", "PD20", "PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ function = "lcd0";
+ };
+
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2",
+ "PF3", "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc1_pg_pins: mmc1-pg-pins {
+ pins = "PG0", "PG1", "PG2",
+ "PG3", "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc2_8bit_pins: mmc2-8bit-pins {
+ pins = "PC5", "PC6", "PC8",
+ "PC9", "PC10", "PC11",
+ "PC12", "PC13", "PC14",
+ "PC15", "PC16";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ nand_pins: nand-pins {
+ pins = "PC0", "PC1", "PC2", "PC5",
+ "PC8", "PC9", "PC10", "PC11",
+ "PC12", "PC13", "PC14", "PC15";
+ function = "nand0";
+ };
+
+ nand_cs0_pin: nand-cs0-pin {
+ pins = "PC4";
+ function = "nand0";
+ bias-pull-up;
+ };
+
+ nand_cs1_pin: nand-cs1-pin {
+ pins = "PC3";
+ function = "nand0";
+ bias-pull-up;
+ };
+
+ nand_rb0_pin: nand-rb0-pin {
+ pins = "PC6";
+ function = "nand0";
+ bias-pull-up;
+ };
+
+ nand_rb1_pin: nand-rb1-pin {
+ pins = "PC7";
+ function = "nand0";
+ bias-pull-up;
+ };
+
+ pwm0_pin: pwm0-pin {
+ pins = "PH0";
+ function = "pwm0";
+ };
+
+ uart0_pf_pins: uart0-pf-pins {
+ pins = "PF2", "PF4";
+ function = "uart0";
+ };
+
+ uart1_pg_pins: uart1-pg-pins {
+ pins = "PG6", "PG7";
+ function = "uart1";
+ };
+
+ uart1_cts_rts_pg_pins: uart1-cts-rts-pg-pins {
+ pins = "PG8", "PG9";
+ function = "uart1";
+ };
+ };
+
+ timer@1c20c00 {
+ compatible = "allwinner,sun8i-a23-timer";
+ reg = <0x01c20c00 0xa0>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
+ wdt0: watchdog@1c20ca0 {
+ compatible = "allwinner,sun6i-a31-wdt";
+ reg = <0x01c20ca0 0x20>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
+ pwm: pwm@1c21400 {
+ compatible = "allwinner,sun7i-a20-pwm";
+ reg = <0x01c21400 0xc>;
+ clocks = <&osc24M>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ lradc: lradc@1c22800 {
+ compatible = "allwinner,sun4i-a10-lradc-keys";
+ reg = <0x01c22800 0x100>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ uart0: serial@1c28000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28000 0x400>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART0>;
+ resets = <&ccu RST_BUS_UART0>;
+ dmas = <&dma 6>, <&dma 6>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart1: serial@1c28400 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28400 0x400>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART1>;
+ resets = <&ccu RST_BUS_UART1>;
+ dmas = <&dma 7>, <&dma 7>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart2: serial@1c28800 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28800 0x400>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART2>;
+ resets = <&ccu RST_BUS_UART2>;
+ dmas = <&dma 8>, <&dma 8>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart3: serial@1c28c00 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28c00 0x400>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART3>;
+ resets = <&ccu RST_BUS_UART3>;
+ dmas = <&dma 9>, <&dma 9>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart4: serial@1c29000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c29000 0x400>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART4>;
+ resets = <&ccu RST_BUS_UART4>;
+ dmas = <&dma 10>, <&dma 10>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ i2c0: i2c@1c2ac00 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C0>;
+ resets = <&ccu RST_BUS_I2C0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@1c2b000 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C1>;
+ resets = <&ccu RST_BUS_I2C1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c@1c2b400 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b400 0x400>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C2>;
+ resets = <&ccu RST_BUS_I2C2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mali: gpu@1c40000 {
+ compatible = "allwinner,sun8i-a23-mali",
+ "allwinner,sun7i-a20-mali", "arm,mali-400";
+ reg = <0x01c40000 0x10000>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "gp",
+ "gpmmu",
+ "pp0",
+ "ppmmu0",
+ "pp1",
+ "ppmmu1",
+ "pmu";
+ clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>;
+ clock-names = "bus", "core";
+ resets = <&ccu RST_BUS_GPU>;
+ #cooling-cells = <2>;
+
+ assigned-clocks = <&ccu CLK_GPU>;
+ assigned-clock-rates = <384000000>;
+ };
+
+ gic: interrupt-controller@1c81000 {
+ compatible = "arm,gic-400";
+ reg = <0x01c81000 0x1000>,
+ <0x01c82000 0x2000>,
+ <0x01c84000 0x2000>,
+ <0x01c86000 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ fe0: display-frontend@1e00000 {
+ /* compatible gets set in SoC specific dtsi file */
+ reg = <0x01e00000 0x20000>;
+ interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_DE_FE>, <&ccu CLK_DE_FE>,
+ <&ccu CLK_DRAM_DE_FE>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_BUS_DE_FE>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fe0_out: port@1 {
+ reg = <1>;
+
+ fe0_out_be0: endpoint {
+ remote-endpoint = <&be0_in_fe0>;
+ };
+ };
+ };
+ };
+
+ be0: display-backend@1e60000 {
+ /* compatible gets set in SoC specific dtsi file */
+ reg = <0x01e60000 0x10000>;
+ interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_DE_BE>, <&ccu CLK_DE_BE>,
+ <&ccu CLK_DRAM_DE_BE>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_BUS_DE_BE>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ be0_in: port@0 {
+ reg = <0>;
+
+ be0_in_fe0: endpoint {
+ remote-endpoint = <&fe0_out_be0>;
+ };
+ };
+
+ be0_out: port@1 {
+ reg = <1>;
+
+ be0_out_drc0: endpoint {
+ remote-endpoint = <&drc0_in_be0>;
+ };
+ };
+ };
+ };
+
+ drc0: drc@1e70000 {
+ /* compatible gets set in SoC specific dtsi file */
+ reg = <0x01e70000 0x10000>;
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_DRC>, <&ccu CLK_DRC>,
+ <&ccu CLK_DRAM_DRC>;
+ clock-names = "ahb", "mod", "ram";
+ resets = <&ccu RST_BUS_DRC>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ drc0_in: port@0 {
+ reg = <0>;
+
+ drc0_in_be0: endpoint {
+ remote-endpoint = <&be0_out_drc0>;
+ };
+ };
+
+ drc0_out: port@1 {
+ reg = <1>;
+
+ drc0_out_tcon0: endpoint {
+ remote-endpoint = <&tcon0_in_drc0>;
+ };
+ };
+ };
+ };
+
+ rtc: rtc@1f00000 {
+ compatible = "allwinner,sun8i-a23-rtc";
+ reg = <0x01f00000 0x400>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ clock-output-names = "osc32k", "osc32k-out";
+ clocks = <&ext_osc32k>;
+ #clock-cells = <1>;
+ };
+
+ r_intc: interrupt-controller@1f00c00 {
+ compatible = "allwinner,sun6i-a31-r-intc";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x01f00c00 0x400>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ prcm@1f01400 {
+ compatible = "allwinner,sun8i-a23-prcm";
+ reg = <0x01f01400 0x200>;
+
+ ar100: ar100_clk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ clocks = <&osc24M>;
+ clock-output-names = "ar100";
+ };
+
+ ahb0: ahb0_clk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ clocks = <&ar100>;
+ clock-output-names = "ahb0";
+ };
+
+ apb0: apb0_clk {
+ compatible = "allwinner,sun8i-a23-apb0-clk";
+ #clock-cells = <0>;
+ clocks = <&ahb0>;
+ clock-output-names = "apb0";
+ };
+
+ apb0_gates: apb0_gates_clk {
+ compatible = "allwinner,sun8i-a23-apb0-gates-clk";
+ #clock-cells = <1>;
+ clocks = <&apb0>;
+ clock-output-names = "apb0_pio", "apb0_timer",
+ "apb0_rsb", "apb0_uart",
+ "apb0_i2c";
+ };
+
+ apb0_rst: apb0_rst {
+ compatible = "allwinner,sun6i-a31-clock-reset";
+ #reset-cells = <1>;
+ };
+
+ codec_analog: codec-analog {
+ compatible = "allwinner,sun8i-a23-codec-analog";
+ };
+ };
+
+ cpucfg@1f01c00 {
+ compatible = "allwinner,sun8i-a23-cpuconfig";
+ reg = <0x01f01c00 0x300>;
+ };
+
+ r_uart: serial@1f02800 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01f02800 0x400>;
+ interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&apb0_gates 4>;
+ resets = <&apb0_rst 4>;
+ status = "disabled";
+ };
+
+ r_i2c: i2c@1f02400 {
+ compatible = "allwinner,sun8i-a23-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x01f02400 0x400>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_i2c_pins>;
+ clocks = <&apb0_gates 6>;
+ resets = <&apb0_rst 6>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ r_pio: pinctrl@1f02c00 {
+ compatible = "allwinner,sun8i-a23-r-pinctrl";
+ reg = <0x01f02c00 0x400>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&apb0_gates 0>, <&osc24M>, <&rtc CLK_OSC32K>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #gpio-cells = <3>;
+
+ r_i2c_pins: r-i2c-pins {
+ pins = "PL0", "PL1";
+ function = "s_i2c";
+ bias-pull-up;
+ };
+
+ r_rsb_pins: r-rsb-pins {
+ pins = "PL0", "PL1";
+ function = "s_rsb";
+ drive-strength = <20>;
+ bias-pull-up;
+ };
+
+ r_uart_pins_a: r-uart-pins {
+ pins = "PL2", "PL3";
+ function = "s_uart";
+ };
+ };
+
+ r_rsb: rsb@1f03400 {
+ compatible = "allwinner,sun8i-a23-rsb";
+ reg = <0x01f03400 0x400>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&apb0_gates 3>;
+ clock-frequency = <3000000>;
+ resets = <&apb0_rst 3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_rsb_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/sun8i-a23-evb.dts b/arch/arm/boot/dts/allwinner/sun8i-a23-evb.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a23-evb.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a23-evb.dts
diff --git a/arch/arm/boot/dts/sun8i-a23-gt90h-v4.dts b/arch/arm/boot/dts/allwinner/sun8i-a23-gt90h-v4.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a23-gt90h-v4.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a23-gt90h-v4.dts
diff --git a/arch/arm/boot/dts/sun8i-a23-inet86dz.dts b/arch/arm/boot/dts/allwinner/sun8i-a23-inet86dz.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a23-inet86dz.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a23-inet86dz.dts
diff --git a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v1.2.dts b/arch/arm/boot/dts/allwinner/sun8i-a23-ippo-q8h-v1.2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a23-ippo-q8h-v1.2.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a23-ippo-q8h-v1.2.dts
diff --git a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts b/arch/arm/boot/dts/allwinner/sun8i-a23-ippo-q8h-v5.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a23-ippo-q8h-v5.dts
diff --git a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts b/arch/arm/boot/dts/allwinner/sun8i-a23-polaroid-mid2407pxe03.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a23-polaroid-mid2407pxe03.dts
diff --git a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts b/arch/arm/boot/dts/allwinner/sun8i-a23-polaroid-mid2809pxe04.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a23-polaroid-mid2809pxe04.dts
diff --git a/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts b/arch/arm/boot/dts/allwinner/sun8i-a23-q8-tablet.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a23-q8-tablet.dts
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/allwinner/sun8i-a23.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a23.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-a23.dtsi
diff --git a/arch/arm/boot/dts/sun8i-a33-et-q8-v1.6.dts b/arch/arm/boot/dts/allwinner/sun8i-a33-et-q8-v1.6.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a33-et-q8-v1.6.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a33-et-q8-v1.6.dts
diff --git a/arch/arm/boot/dts/sun8i-a33-ga10h-v1.1.dts b/arch/arm/boot/dts/allwinner/sun8i-a33-ga10h-v1.1.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a33-ga10h-v1.1.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a33-ga10h-v1.1.dts
diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts b/arch/arm/boot/dts/allwinner/sun8i-a33-inet-d978-rev2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a33-inet-d978-rev2.dts
diff --git a/arch/arm/boot/dts/sun8i-a33-ippo-q8h-v1.2.dts b/arch/arm/boot/dts/allwinner/sun8i-a33-ippo-q8h-v1.2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a33-ippo-q8h-v1.2.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a33-ippo-q8h-v1.2.dts
diff --git a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts b/arch/arm/boot/dts/allwinner/sun8i-a33-olinuxino.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a33-olinuxino.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a33-olinuxino.dts
diff --git a/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts b/arch/arm/boot/dts/allwinner/sun8i-a33-q8-tablet.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a33-q8-tablet.dts
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/allwinner/sun8i-a33-sinlinx-sina33.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a33-sinlinx-sina33.dts
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/allwinner/sun8i-a33.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a33.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-a33.dtsi
diff --git a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts b/arch/arm/boot/dts/allwinner/sun8i-a83t-allwinner-h8homlet-v2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a83t-allwinner-h8homlet-v2.dts
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3.dts
diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts b/arch/arm/boot/dts/allwinner/sun8i-a83t-cubietruck-plus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a83t-cubietruck-plus.dts
diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts b/arch/arm/boot/dts/allwinner/sun8i-a83t-tbs-a711.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
rename to arch/arm/boot/dts/allwinner/sun8i-a83t-tbs-a711.dts
diff --git a/arch/arm/boot/dts/allwinner/sun8i-a83t.dtsi b/arch/arm/boot/dts/allwinner/sun8i-a83t.dtsi
new file mode 100644
index 0000000..94eb3bf
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun8i-a83t.dtsi
@@ -0,0 +1,1274 @@
+/*
+ * Copyright 2015 Vishnu Patekar
+ *
+ * Vishnu Patekar <vishnupatekar0510@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+#include <dt-bindings/clock/sun8i-a83t-ccu.h>
+#include <dt-bindings/clock/sun8i-de2.h>
+#include <dt-bindings/clock/sun8i-r-ccu.h>
+#include <dt-bindings/reset/sun8i-a83t-ccu.h>
+#include <dt-bindings/reset/sun8i-de2.h>
+#include <dt-bindings/reset/sun8i-r-ccu.h>
+#include <dt-bindings/thermal/thermal.h>
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ clocks = <&ccu CLK_C0CPUX>;
+ operating-points-v2 = <&cpu0_opp_table>;
+ cci-control-port = <&cci_control0>;
+ enable-method = "allwinner,sun8i-a83t-smp";
+ reg = <0>;
+ #cooling-cells = <2>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ clocks = <&ccu CLK_C0CPUX>;
+ operating-points-v2 = <&cpu0_opp_table>;
+ cci-control-port = <&cci_control0>;
+ enable-method = "allwinner,sun8i-a83t-smp";
+ reg = <1>;
+ #cooling-cells = <2>;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ clocks = <&ccu CLK_C0CPUX>;
+ operating-points-v2 = <&cpu0_opp_table>;
+ cci-control-port = <&cci_control0>;
+ enable-method = "allwinner,sun8i-a83t-smp";
+ reg = <2>;
+ #cooling-cells = <2>;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ clocks = <&ccu CLK_C0CPUX>;
+ operating-points-v2 = <&cpu0_opp_table>;
+ cci-control-port = <&cci_control0>;
+ enable-method = "allwinner,sun8i-a83t-smp";
+ reg = <3>;
+ #cooling-cells = <2>;
+ };
+
+ cpu100: cpu@100 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ clocks = <&ccu CLK_C1CPUX>;
+ operating-points-v2 = <&cpu1_opp_table>;
+ cci-control-port = <&cci_control1>;
+ enable-method = "allwinner,sun8i-a83t-smp";
+ reg = <0x100>;
+ #cooling-cells = <2>;
+ };
+
+ cpu101: cpu@101 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ clocks = <&ccu CLK_C1CPUX>;
+ operating-points-v2 = <&cpu1_opp_table>;
+ cci-control-port = <&cci_control1>;
+ enable-method = "allwinner,sun8i-a83t-smp";
+ reg = <0x101>;
+ #cooling-cells = <2>;
+ };
+
+ cpu102: cpu@102 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ clocks = <&ccu CLK_C1CPUX>;
+ operating-points-v2 = <&cpu1_opp_table>;
+ cci-control-port = <&cci_control1>;
+ enable-method = "allwinner,sun8i-a83t-smp";
+ reg = <0x102>;
+ #cooling-cells = <2>;
+ };
+
+ cpu103: cpu@103 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ clocks = <&ccu CLK_C1CPUX>;
+ operating-points-v2 = <&cpu1_opp_table>;
+ cci-control-port = <&cci_control1>;
+ enable-method = "allwinner,sun8i-a83t-smp";
+ reg = <0x103>;
+ #cooling-cells = <2>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ /* TODO: PRCM block has a mux for this. */
+ osc24M: osc24M_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-accuracy = <50000>;
+ clock-output-names = "osc24M";
+ };
+
+ /*
+ * This is called "internal OSC" in some places.
+ * It is an internal RC-based oscillator.
+ * TODO: Its controls are in the PRCM block.
+ */
+ osc16M: osc16M_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <16000000>;
+ clock-output-names = "osc16M";
+ };
+
+ osc16Md512: osc16Md512_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clock-div = <512>;
+ clock-mult = <1>;
+ clocks = <&osc16M>;
+ clock-output-names = "osc16M-d512";
+ };
+ };
+
+ de: display-engine {
+ compatible = "allwinner,sun8i-a83t-display-engine";
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
+ status = "disabled";
+ };
+
+ cpu0_opp_table: opp-table-cluster0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-864000000 {
+ opp-hz = /bits/ 64 <864000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-912000000 {
+ opp-hz = /bits/ 64 <912000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-1008000000 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-1128000000 {
+ opp-hz = /bits/ 64 <1128000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+ };
+
+ cpu1_opp_table: opp-table-cluster1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-864000000 {
+ opp-hz = /bits/ 64 <864000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-912000000 {
+ opp-hz = /bits/ 64 <912000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-1008000000 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-1128000000 {
+ opp-hz = /bits/ 64 <1128000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <840000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display_clocks: clock@1000000 {
+ compatible = "allwinner,sun8i-a83t-de2-clk";
+ reg = <0x01000000 0x10000>;
+ clocks = <&ccu CLK_BUS_DE>,
+ <&ccu CLK_PLL_DE>;
+ clock-names = "bus",
+ "mod";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ rotate: rotate@1020000 {
+ compatible = "allwinner,sun8i-a83t-de2-rotate";
+ reg = <0x1020000 0x10000>;
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&display_clocks CLK_BUS_ROT>,
+ <&display_clocks CLK_ROT>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_ROT>;
+ };
+
+ mixer0: mixer@1100000 {
+ compatible = "allwinner,sun8i-a83t-de2-mixer-0";
+ reg = <0x01100000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER0>,
+ <&display_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_MIXER0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_in_mixer0>;
+ };
+
+ mixer0_out_tcon1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&tcon1_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ mixer1: mixer@1200000 {
+ compatible = "allwinner,sun8i-a83t-de2-mixer-1";
+ reg = <0x01200000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+ <&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer1_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_in_mixer1>;
+ };
+
+ mixer1_out_tcon1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&tcon1_in_mixer1>;
+ };
+ };
+ };
+ };
+
+ cpucfg@1700000 {
+ compatible = "allwinner,sun8i-a83t-cpucfg";
+ reg = <0x01700000 0x400>;
+ };
+
+ cci@1790000 {
+ compatible = "arm,cci-400";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x01790000 0x10000>;
+ ranges = <0x0 0x01790000 0x10000>;
+
+ cci_control0: slave-if@4000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x4000 0x1000>;
+ };
+
+ cci_control1: slave-if@5000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x5000 0x1000>;
+ };
+
+ pmu@9000 {
+ compatible = "arm,cci-400-pmu,r1";
+ reg = <0x9000 0x5000>;
+ interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ syscon: syscon@1c00000 {
+ compatible = "allwinner,sun8i-a83t-system-controller",
+ "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
+ dma: dma-controller@1c02000 {
+ compatible = "allwinner,sun8i-a83t-dma";
+ reg = <0x01c02000 0x1000>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_DMA>;
+ resets = <&ccu RST_BUS_DMA>;
+ #dma-cells = <1>;
+ };
+
+ tcon0: lcd-controller@1c0c000 {
+ compatible = "allwinner,sun8i-a83t-tcon-lcd";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
+ clock-names = "ahb", "tcon-ch0";
+ clock-output-names = "tcon-data-clock";
+ #clock-cells = <0>;
+ resets = <&ccu RST_BUS_TCON0>, <&ccu RST_BUS_LVDS>;
+ reset-names = "lcd", "lvds";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&mixer0_out_tcon0>;
+ };
+
+ tcon0_in_mixer1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&mixer1_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ tcon1: lcd-controller@1c0d000 {
+ compatible = "allwinner,sun8i-a83t-tcon-tv";
+ reg = <0x01c0d000 0x1000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON1>, <&ccu CLK_TCON1>;
+ clock-names = "ahb", "tcon-ch1";
+ resets = <&ccu RST_BUS_TCON1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon1_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&mixer0_out_tcon1>;
+ };
+
+ tcon1_in_mixer1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&mixer1_out_tcon1>;
+ };
+ };
+
+ tcon1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon1_out_hdmi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&hdmi_in_tcon1>;
+ };
+ };
+ };
+ };
+
+ mmc0: mmc@1c0f000 {
+ compatible = "allwinner,sun8i-a83t-mmc",
+ "allwinner,sun7i-a20-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>,
+ <&ccu CLK_MMC0>,
+ <&ccu CLK_MMC0_OUTPUT>,
+ <&ccu CLK_MMC0_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@1c10000 {
+ compatible = "allwinner,sun8i-a83t-mmc",
+ "allwinner,sun7i-a20-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>,
+ <&ccu CLK_MMC1>,
+ <&ccu CLK_MMC1_OUTPUT>,
+ <&ccu CLK_MMC1_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC1>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@1c11000 {
+ compatible = "allwinner,sun8i-a83t-emmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC2>,
+ <&ccu CLK_MMC2>,
+ <&ccu CLK_MMC2_OUTPUT>,
+ <&ccu CLK_MMC2_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC2>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ sid: eeprom@1c14000 {
+ compatible = "allwinner,sun8i-a83t-sid";
+ reg = <0x1c14000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ths_calibration: thermal-sensor-calibration@34 {
+ reg = <0x34 8>;
+ };
+ };
+
+ crypto: crypto@1c15000 {
+ compatible = "allwinner,sun8i-a83t-crypto";
+ reg = <0x01c15000 0x1000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&ccu RST_BUS_SS>;
+ clocks = <&ccu CLK_BUS_SS>, <&ccu CLK_SS>;
+ clock-names = "bus", "mod";
+ };
+
+ msgbox: mailbox@1c17000 {
+ compatible = "allwinner,sun8i-a83t-msgbox",
+ "allwinner,sun6i-a31-msgbox";
+ reg = <0x01c17000 0x1000>;
+ clocks = <&ccu CLK_BUS_MSGBOX>;
+ resets = <&ccu RST_BUS_MSGBOX>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ };
+
+ usb_otg: usb@1c19000 {
+ compatible = "allwinner,sun8i-a83t-musb",
+ "allwinner,sun8i-a33-musb";
+ reg = <0x01c19000 0x0400>;
+ clocks = <&ccu CLK_BUS_OTG>;
+ resets = <&ccu RST_BUS_OTG>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mc";
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ extcon = <&usbphy 0>;
+ dr_mode = "otg";
+ status = "disabled";
+ };
+
+ usbphy: phy@1c19400 {
+ compatible = "allwinner,sun8i-a83t-usb-phy";
+ reg = <0x01c19400 0x10>,
+ <0x01c1a800 0x14>,
+ <0x01c1b800 0x14>;
+ reg-names = "phy_ctrl",
+ "pmu1",
+ "pmu2";
+ clocks = <&ccu CLK_USB_PHY0>,
+ <&ccu CLK_USB_PHY1>,
+ <&ccu CLK_USB_HSIC>,
+ <&ccu CLK_USB_HSIC_12M>;
+ clock-names = "usb0_phy",
+ "usb1_phy",
+ "usb2_phy",
+ "usb2_hsic_12M";
+ resets = <&ccu RST_USB_PHY0>,
+ <&ccu RST_USB_PHY1>,
+ <&ccu RST_USB_HSIC>;
+ reset-names = "usb0_reset",
+ "usb1_reset",
+ "usb2_reset";
+ status = "disabled";
+ #phy-cells = <1>;
+ };
+
+ ehci0: usb@1c1a000 {
+ compatible = "allwinner,sun8i-a83t-ehci",
+ "generic-ehci";
+ reg = <0x01c1a000 0x100>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_EHCI0>;
+ resets = <&ccu RST_BUS_EHCI0>;
+ phys = <&usbphy 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ohci0: usb@1c1a400 {
+ compatible = "allwinner,sun8i-a83t-ohci",
+ "generic-ohci";
+ reg = <0x01c1a400 0x100>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_OHCI0>, <&ccu CLK_USB_OHCI0>;
+ resets = <&ccu RST_BUS_OHCI0>;
+ phys = <&usbphy 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ehci1: usb@1c1b000 {
+ compatible = "allwinner,sun8i-a83t-ehci",
+ "generic-ehci";
+ reg = <0x01c1b000 0x100>;
+ interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_EHCI1>;
+ resets = <&ccu RST_BUS_EHCI1>;
+ phys = <&usbphy 2>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ccu: clock@1c20000 {
+ compatible = "allwinner,sun8i-a83t-ccu";
+ reg = <0x01c20000 0x400>;
+ clocks = <&osc24M>, <&osc16Md512>;
+ clock-names = "hosc", "losc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ pio: pinctrl@1c20800 {
+ compatible = "allwinner,sun8i-a83t-pinctrl";
+ interrupt-parent = <&r_intc>;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x01c20800 0x400>;
+ clocks = <&ccu CLK_BUS_PIO>, <&osc24M>, <&osc16Md512>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #gpio-cells = <3>;
+
+ /omit-if-no-ref/
+ csi_8bit_parallel_pins: csi-8bit-parallel-pins {
+ pins = "PE0", "PE2", "PE3", "PE6", "PE7",
+ "PE8", "PE9", "PE10", "PE11",
+ "PE12", "PE13";
+ function = "csi";
+ };
+
+ /omit-if-no-ref/
+ csi_mclk_pin: csi-mclk-pin {
+ pins = "PE1";
+ function = "csi";
+ };
+
+ emac_rgmii_pins: emac-rgmii-pins {
+ pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
+ "PD11", "PD12", "PD13", "PD14", "PD18",
+ "PD19", "PD21", "PD22", "PD23";
+ function = "gmac";
+ /*
+ * data lines in RGMII mode use DDR mode
+ * and need a higher signal drive strength
+ */
+ drive-strength = <40>;
+ };
+
+ hdmi_pins: hdmi-pins {
+ pins = "PH6", "PH7", "PH8";
+ function = "hdmi";
+ };
+
+ i2c0_pins: i2c0-pins {
+ pins = "PH0", "PH1";
+ function = "i2c0";
+ };
+
+ i2c1_pins: i2c1-pins {
+ pins = "PH2", "PH3";
+ function = "i2c1";
+ };
+
+ /omit-if-no-ref/
+ i2c2_pe_pins: i2c2-pe-pins {
+ pins = "PE14", "PE15";
+ function = "i2c2";
+ };
+
+ i2c2_ph_pins: i2c2-ph-pins {
+ pins = "PH4", "PH5";
+ function = "i2c2";
+ };
+
+ i2s1_pins: i2s1-pins {
+ /* I2S1 does not have external MCLK pin */
+ pins = "PG10", "PG11", "PG12", "PG13";
+ function = "i2s1";
+ };
+
+ lcd_lvds_pins: lcd-lvds-pins {
+ pins = "PD18", "PD19", "PD20", "PD21", "PD22",
+ "PD23", "PD24", "PD25", "PD26", "PD27";
+ function = "lvds0";
+ };
+
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2",
+ "PF3", "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc1_pins: mmc1-pins {
+ pins = "PG0", "PG1", "PG2",
+ "PG3", "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc2_8bit_emmc_pins: mmc2-8bit-emmc-pins {
+ pins = "PC5", "PC6", "PC8", "PC9",
+ "PC10", "PC11", "PC12", "PC13",
+ "PC14", "PC15", "PC16";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ pwm_pin: pwm-pin {
+ pins = "PD28";
+ function = "pwm";
+ };
+
+ spdif_tx_pin: spdif-tx-pin {
+ pins = "PE18";
+ function = "spdif";
+ };
+
+ uart0_pb_pins: uart0-pb-pins {
+ pins = "PB9", "PB10";
+ function = "uart0";
+ };
+
+ uart0_pf_pins: uart0-pf-pins {
+ pins = "PF2", "PF4";
+ function = "uart0";
+ };
+
+ uart1_pins: uart1-pins {
+ pins = "PG6", "PG7";
+ function = "uart1";
+ };
+
+ uart1_rts_cts_pins: uart1-rts-cts-pins {
+ pins = "PG8", "PG9";
+ function = "uart1";
+ };
+
+ /omit-if-no-ref/
+ uart2_pb_pins: uart2-pb-pins {
+ pins = "PB0", "PB1";
+ function = "uart2";
+ };
+ };
+
+ timer@1c20c00 {
+ compatible = "allwinner,sun8i-a23-timer";
+ reg = <0x01c20c00 0xa0>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
+ watchdog@1c20ca0 {
+ compatible = "allwinner,sun6i-a31-wdt";
+ reg = <0x01c20ca0 0x20>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
+ spdif: spdif@1c21000 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a83t-spdif",
+ "allwinner,sun8i-h3-spdif";
+ reg = <0x01c21000 0x400>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPDIF>, <&ccu CLK_SPDIF>;
+ resets = <&ccu RST_BUS_SPDIF>;
+ clock-names = "apb", "spdif";
+ dmas = <&dma 2>;
+ dma-names = "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spdif_tx_pin>;
+ status = "disabled";
+ };
+
+ i2s0: i2s@1c22000 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a83t-i2s";
+ reg = <0x01c22000 0x400>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2S0>, <&ccu CLK_I2S0>;
+ clock-names = "apb", "mod";
+ dmas = <&dma 3>, <&dma 3>;
+ resets = <&ccu RST_BUS_I2S0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ i2s1: i2s@1c22400 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a83t-i2s";
+ reg = <0x01c22400 0x400>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2S1>, <&ccu CLK_I2S1>;
+ clock-names = "apb", "mod";
+ dmas = <&dma 4>, <&dma 4>;
+ resets = <&ccu RST_BUS_I2S1>;
+ dma-names = "rx", "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1_pins>;
+ status = "disabled";
+ };
+
+ i2s2: i2s@1c22800 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a83t-i2s";
+ reg = <0x01c22800 0x400>;
+ interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2S2>, <&ccu CLK_I2S2>;
+ clock-names = "apb", "mod";
+ dmas = <&dma 27>;
+ resets = <&ccu RST_BUS_I2S2>;
+ dma-names = "tx";
+ status = "disabled";
+ };
+
+ pwm: pwm@1c21400 {
+ compatible = "allwinner,sun8i-a83t-pwm",
+ "allwinner,sun8i-h3-pwm";
+ reg = <0x01c21400 0x400>;
+ clocks = <&osc24M>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ uart0: serial@1c28000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28000 0x400>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART0>;
+ resets = <&ccu RST_BUS_UART0>;
+ status = "disabled";
+ };
+
+ uart1: serial@1c28400 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28400 0x400>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART1>;
+ resets = <&ccu RST_BUS_UART1>;
+ status = "disabled";
+ };
+
+ uart2: serial@1c28800 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28800 0x400>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART2>;
+ resets = <&ccu RST_BUS_UART2>;
+ status = "disabled";
+ };
+
+ uart3: serial@1c28c00 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28c00 0x400>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART3>;
+ resets = <&ccu RST_BUS_UART3>;
+ status = "disabled";
+ };
+
+ uart4: serial@1c29000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c29000 0x400>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART4>;
+ resets = <&ccu RST_BUS_UART4>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@1c2ac00 {
+ compatible = "allwinner,sun8i-a83t-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C0>;
+ resets = <&ccu RST_BUS_I2C0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@1c2b000 {
+ compatible = "allwinner,sun8i-a83t-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C1>;
+ resets = <&ccu RST_BUS_I2C1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c@1c2b400 {
+ compatible = "allwinner,sun8i-a83t-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b400 0x400>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C2>;
+ resets = <&ccu RST_BUS_I2C2>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ emac: ethernet@1c30000 {
+ compatible = "allwinner,sun8i-a83t-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ status = "disabled";
+
+ mdio: mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ gic: interrupt-controller@1c81000 {
+ compatible = "arm,gic-400";
+ reg = <0x01c81000 0x1000>,
+ <0x01c82000 0x2000>,
+ <0x01c84000 0x2000>,
+ <0x01c86000 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ csi: camera@1cb0000 {
+ compatible = "allwinner,sun8i-a83t-csi";
+ reg = <0x01cb0000 0x1000>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI_SCLK>,
+ <&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+ status = "disabled";
+ };
+
+ hdmi: hdmi@1ee0000 {
+ compatible = "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee0000 0x10000>;
+ reg-io-width = <1>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu CLK_HDMI>;
+ clock-names = "iahb", "isfr", "tmds";
+ resets = <&ccu RST_BUS_HDMI1>;
+ reset-names = "ctrl";
+ phys = <&hdmi_phy>;
+ phy-names = "phy";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pins>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port@0 {
+ reg = <0>;
+
+ hdmi_in_tcon1: endpoint {
+ remote-endpoint = <&tcon1_out_hdmi>;
+ };
+ };
+
+ hdmi_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ hdmi_phy: hdmi-phy@1ef0000 {
+ compatible = "allwinner,sun8i-a83t-hdmi-phy";
+ reg = <0x01ef0000 0x10000>;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>;
+ clock-names = "bus", "mod";
+ resets = <&ccu RST_BUS_HDMI0>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
+
+ r_intc: interrupt-controller@1f00c00 {
+ compatible = "allwinner,sun8i-a83t-r-intc",
+ "allwinner,sun6i-a31-r-intc";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x01f00c00 0x400>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ r_ccu: clock@1f01400 {
+ compatible = "allwinner,sun8i-a83t-r-ccu";
+ reg = <0x01f01400 0x400>;
+ clocks = <&osc24M>, <&osc16Md512>, <&osc16M>,
+ <&ccu CLK_PLL_PERIPH>;
+ clock-names = "hosc", "losc", "iosc", "pll-periph";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ r_cpucfg@1f01c00 {
+ compatible = "allwinner,sun8i-a83t-r-cpucfg";
+ reg = <0x1f01c00 0x400>;
+ };
+
+ r_cir: ir@1f02000 {
+ compatible = "allwinner,sun8i-a83t-ir",
+ "allwinner,sun6i-a31-ir";
+ clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ resets = <&r_ccu RST_APB0_IR>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x01f02000 0x400>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_cir_pin>;
+ status = "disabled";
+ };
+
+ r_lradc: lradc@1f03c00 {
+ compatible = "allwinner,sun8i-a83t-r-lradc";
+ reg = <0x01f03c00 0x100>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ r_pio: pinctrl@1f02c00 {
+ compatible = "allwinner,sun8i-a83t-r-pinctrl";
+ reg = <0x01f02c00 0x400>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_APB0_PIO>, <&osc24M>,
+ <&osc16Md512>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ r_cir_pin: r-cir-pin {
+ pins = "PL12";
+ function = "s_cir_rx";
+ };
+
+ r_rsb_pins: r-rsb-pins {
+ pins = "PL0", "PL1";
+ function = "s_rsb";
+ drive-strength = <20>;
+ bias-pull-up;
+ };
+ };
+
+ r_rsb: rsb@1f03400 {
+ compatible = "allwinner,sun8i-a83t-rsb",
+ "allwinner,sun8i-a23-rsb";
+ reg = <0x01f03400 0x400>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_APB0_RSB>;
+ clock-frequency = <3000000>;
+ resets = <&r_ccu RST_APB0_RSB>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_rsb_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ ths: thermal-sensor@1f04000 {
+ compatible = "allwinner,sun8i-a83t-ths";
+ reg = <0x01f04000 0x100>;
+ interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ nvmem-cells = <&ths_calibration>;
+ nvmem-cell-names = "calibration";
+ #thermal-sensor-cells = <1>;
+ };
+ };
+
+ thermal-zones {
+ cpu0_thermal: cpu0-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&ths 0>;
+
+ trips {
+ cpu0_hot: cpu-hot {
+ temperature = <80000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu0_very_hot: cpu-very-hot {
+ temperature = <100000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ cpu-hot-limit {
+ trip = <&cpu0_hot>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ cpu1_thermal: cpu1-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&ths 1>;
+
+ trips {
+ cpu1_hot: cpu-hot {
+ temperature = <80000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu1_very_hot: cpu-very-hot {
+ temperature = <100000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ cpu-hot-limit {
+ trip = <&cpu1_hot>;
+ cooling-device = <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ gpu_thermal: gpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&ths 2>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts b/arch/arm/boot/dts/allwinner/sun8i-h2-plus-bananapi-m2-zero.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h2-plus-bananapi-m2-zero.dts
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-libretech-all-h3-cc.dts b/arch/arm/boot/dts/allwinner/sun8i-h2-plus-libretech-all-h3-cc.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h2-plus-libretech-all-h3-cc.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h2-plus-libretech-all-h3-cc.dts
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts b/arch/arm/boot/dts/allwinner/sun8i-h2-plus-orangepi-r1.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h2-plus-orangepi-r1.dts
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/allwinner/sun8i-h2-plus-orangepi-zero.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h2-plus-orangepi-zero.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-bananapi-m2-plus-v1.2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-bananapi-m2-plus-v1.2.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-bananapi-m2-plus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-bananapi-m2-plus.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-beelink-x2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-beelink-x2.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-emlid-neutis-n5h3-devboard.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-emlid-neutis-n5h3-devboard.dts
diff --git a/arch/arm/boot/dts/allwinner/sun8i-h3-emlid-neutis-n5h3.dtsi b/arch/arm/boot/dts/allwinner/sun8i-h3-emlid-neutis-n5h3.dtsi
new file mode 100644
index 0000000..35e71f4
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun8i-h3-emlid-neutis-n5h3.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * DTSI for Emlid Neutis N5 SoM.
+ *
+ * Copyright (C) 2019 Georgii Staroselskii <georgii.staroselskii@emlid.com>
+ */
+
+/dts-v1/;
+
+#include "sun8i-h3.dtsi"
+#include "sunxi-h3-h5-emlid-neutis.dtsi"
diff --git a/arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-libretech-all-h3-cc.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-libretech-all-h3-cc.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-mapleboard-mp130.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-mapleboard-mp130.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-mapleboard-mp130.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-mapleboard-mp130.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-duo2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-duo2.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1-plus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1-plus.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo-air.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo-air.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-r1.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-r1.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi b/arch/arm/boot/dts/allwinner/sun8i-h3-nanopi.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-nanopi.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-h3-nanopi.dtsi
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-2.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-lite.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-lite.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-one.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-one.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-pc-plus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-pc-plus.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-pc.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-pc.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-plus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-plus.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-plus2e.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-plus2e.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-zero-plus2.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-orangepi-zero-plus2.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-rervision-dvk.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-rervision-dvk.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-rervision-dvk.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-rervision-dvk.dts
diff --git a/arch/arm/boot/dts/sun8i-h3-zeropi.dts b/arch/arm/boot/dts/allwinner/sun8i-h3-zeropi.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3-zeropi.dts
rename to arch/arm/boot/dts/allwinner/sun8i-h3-zeropi.dts
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/allwinner/sun8i-h3.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-h3.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-h3.dtsi
diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/allwinner/sun8i-q8-common.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-q8-common.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-q8-common.dtsi
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts b/arch/arm/boot/dts/allwinner/sun8i-r16-bananapi-m2m.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
rename to arch/arm/boot/dts/allwinner/sun8i-r16-bananapi-m2m.dts
diff --git a/arch/arm/boot/dts/sun8i-r16-nintendo-nes-classic.dts b/arch/arm/boot/dts/allwinner/sun8i-r16-nintendo-nes-classic.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-r16-nintendo-nes-classic.dts
rename to arch/arm/boot/dts/allwinner/sun8i-r16-nintendo-nes-classic.dts
diff --git a/arch/arm/boot/dts/sun8i-r16-nintendo-super-nes-classic.dts b/arch/arm/boot/dts/allwinner/sun8i-r16-nintendo-super-nes-classic.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-r16-nintendo-super-nes-classic.dts
rename to arch/arm/boot/dts/allwinner/sun8i-r16-nintendo-super-nes-classic.dts
diff --git a/arch/arm/boot/dts/sun8i-r16-parrot.dts b/arch/arm/boot/dts/allwinner/sun8i-r16-parrot.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-r16-parrot.dts
rename to arch/arm/boot/dts/allwinner/sun8i-r16-parrot.dts
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/allwinner/sun8i-r40-bananapi-m2-ultra.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
rename to arch/arm/boot/dts/allwinner/sun8i-r40-bananapi-m2-ultra.dts
diff --git a/arch/arm/boot/dts/sun8i-r40-cpu-opp.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-cpu-opp.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-r40-cpu-opp.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-r40-cpu-opp.dtsi
diff --git a/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi
diff --git a/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts b/arch/arm/boot/dts/allwinner/sun8i-r40-oka40i-c.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
rename to arch/arm/boot/dts/allwinner/sun8i-r40-oka40i-c.dts
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-r40.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-r40.dtsi
diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/allwinner/sun8i-reference-design-tablet.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-reference-design-tablet.dtsi
diff --git a/arch/arm/boot/dts/sun8i-s3-elimo-impetus.dtsi b/arch/arm/boot/dts/allwinner/sun8i-s3-elimo-impetus.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-s3-elimo-impetus.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-s3-elimo-impetus.dtsi
diff --git a/arch/arm/boot/dts/sun8i-s3-elimo-initium.dts b/arch/arm/boot/dts/allwinner/sun8i-s3-elimo-initium.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-s3-elimo-initium.dts
rename to arch/arm/boot/dts/allwinner/sun8i-s3-elimo-initium.dts
diff --git a/arch/arm/boot/dts/sun8i-s3-lichee-zero-plus.dts b/arch/arm/boot/dts/allwinner/sun8i-s3-lichee-zero-plus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-s3-lichee-zero-plus.dts
rename to arch/arm/boot/dts/allwinner/sun8i-s3-lichee-zero-plus.dts
diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts b/arch/arm/boot/dts/allwinner/sun8i-s3-pinecube.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-s3-pinecube.dts
rename to arch/arm/boot/dts/allwinner/sun8i-s3-pinecube.dts
diff --git a/arch/arm/boot/dts/sun8i-t113s-mangopi-mq-r-t113.dts b/arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-t113s-mangopi-mq-r-t113.dts
rename to arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts
diff --git a/arch/arm/boot/dts/sun8i-t113s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-t113s.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
diff --git a/arch/arm/boot/dts/sun8i-t3-cqa3t-bv3.dts b/arch/arm/boot/dts/allwinner/sun8i-t3-cqa3t-bv3.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-t3-cqa3t-bv3.dts
rename to arch/arm/boot/dts/allwinner/sun8i-t3-cqa3t-bv3.dts
diff --git a/arch/arm/boot/dts/sun8i-v3-sl631-imx179.dts b/arch/arm/boot/dts/allwinner/sun8i-v3-sl631-imx179.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-v3-sl631-imx179.dts
rename to arch/arm/boot/dts/allwinner/sun8i-v3-sl631-imx179.dts
diff --git a/arch/arm/boot/dts/sun8i-v3-sl631.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3-sl631.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-v3-sl631.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-v3-sl631.dtsi
diff --git a/arch/arm/boot/dts/sun8i-v3.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun8i-v3.dtsi
rename to arch/arm/boot/dts/allwinner/sun8i-v3.dtsi
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts b/arch/arm/boot/dts/allwinner/sun8i-v3s-licheepi-zero-dock.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
rename to arch/arm/boot/dts/allwinner/sun8i-v3s-licheepi-zero-dock.dts
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/allwinner/sun8i-v3s-licheepi-zero.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
rename to arch/arm/boot/dts/allwinner/sun8i-v3s-licheepi-zero.dts
diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
new file mode 100644
index 0000000..3b9a282
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
@@ -0,0 +1,621 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ * Copyright (C) 2021 Tobias Schramm <t.schramm@manjaro.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun6i-rtc.h>
+#include <dt-bindings/clock/sun8i-v3s-ccu.h>
+#include <dt-bindings/reset/sun8i-v3s-ccu.h>
+#include <dt-bindings/clock/sun8i-de2.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer-lcd {
+ compatible = "allwinner,simple-framebuffer",
+ "simple-framebuffer";
+ allwinner,pipeline = "mixer0-lcd0";
+ clocks = <&display_clocks CLK_MIXER0>,
+ <&ccu CLK_TCON0>;
+ status = "disabled";
+ };
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&ccu CLK_CPU>;
+ };
+ };
+
+ de: display-engine {
+ compatible = "allwinner,sun8i-v3s-display-engine";
+ allwinner,pipelines = <&mixer0>;
+ status = "disabled";
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc24M: osc24M_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-accuracy = <50000>;
+ clock-output-names = "osc24M";
+ };
+
+ osc32k: osc32k_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-accuracy = <50000>;
+ clock-output-names = "ext-osc32k";
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display_clocks: clock@1000000 {
+ compatible = "allwinner,sun8i-v3s-de2-clk";
+ reg = <0x01000000 0x10000>;
+ clocks = <&ccu CLK_BUS_DE>,
+ <&ccu CLK_DE>;
+ clock-names = "bus",
+ "mod";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ mixer0: mixer@1100000 {
+ compatible = "allwinner,sun8i-v3s-de2-mixer";
+ reg = <0x01100000 0x100000>;
+ clocks = <&display_clocks 0>,
+ <&display_clocks 6>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint {
+ remote-endpoint = <&tcon0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ syscon: system-control@1c00000 {
+ compatible = "allwinner,sun8i-v3s-system-control",
+ "allwinner,sun8i-h3-system-control";
+ reg = <0x01c00000 0xd0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ };
+
+ nmi_intc: interrupt-controller@1c000d0 {
+ compatible = "allwinner,sun8i-v3s-nmi",
+ "allwinner,sun9i-a80-nmi";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01c000d0 0x0c>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ dma: dma-controller@1c02000 {
+ compatible = "allwinner,sun8i-v3s-dma";
+ reg = <0x01c02000 0x1000>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_DMA>;
+ resets = <&ccu RST_BUS_DMA>;
+ #dma-cells = <1>;
+ };
+
+ tcon0: lcd-controller@1c0c000 {
+ compatible = "allwinner,sun8i-v3s-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON0>,
+ <&ccu CLK_TCON0>;
+ clock-names = "ahb",
+ "tcon-ch0";
+ clock-output-names = "tcon-data-clock";
+ #clock-cells = <0>;
+ resets = <&ccu RST_BUS_TCON0>;
+ reset-names = "lcd";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint {
+ remote-endpoint = <&mixer0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
+
+ mmc0: mmc@1c0f000 {
+ compatible = "allwinner,sun7i-a20-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>,
+ <&ccu CLK_MMC0>,
+ <&ccu CLK_MMC0_OUTPUT>,
+ <&ccu CLK_MMC0_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@1c10000 {
+ compatible = "allwinner,sun7i-a20-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>,
+ <&ccu CLK_MMC1>,
+ <&ccu CLK_MMC1_OUTPUT>,
+ <&ccu CLK_MMC1_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC1>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@1c11000 {
+ compatible = "allwinner,sun7i-a20-mmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC2>,
+ <&ccu CLK_MMC2>,
+ <&ccu CLK_MMC2_OUTPUT>,
+ <&ccu CLK_MMC2_SAMPLE>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <&ccu RST_BUS_MMC2>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ crypto@1c15000 {
+ compatible = "allwinner,sun8i-v3s-crypto",
+ "allwinner,sun8i-a33-crypto";
+ reg = <0x01c15000 0x1000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma 16>, <&dma 16>;
+ dma-names = "rx", "tx";
+ resets = <&ccu RST_BUS_CE>;
+ reset-names = "ahb";
+ };
+
+ usb_otg: usb@1c19000 {
+ compatible = "allwinner,sun8i-h3-musb";
+ reg = <0x01c19000 0x0400>;
+ clocks = <&ccu CLK_BUS_OTG>;
+ resets = <&ccu RST_BUS_OTG>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mc";
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ extcon = <&usbphy 0>;
+ status = "disabled";
+ };
+
+ usbphy: phy@1c19400 {
+ compatible = "allwinner,sun8i-v3s-usb-phy";
+ reg = <0x01c19400 0x2c>,
+ <0x01c1a800 0x4>;
+ reg-names = "phy_ctrl",
+ "pmu0";
+ clocks = <&ccu CLK_USB_PHY0>;
+ clock-names = "usb0_phy";
+ resets = <&ccu RST_USB_PHY0>;
+ reset-names = "usb0_reset";
+ status = "disabled";
+ #phy-cells = <1>;
+ };
+
+ ccu: clock@1c20000 {
+ compatible = "allwinner,sun8i-v3s-ccu";
+ reg = <0x01c20000 0x400>;
+ clocks = <&osc24M>, <&rtc CLK_OSC32K>;
+ clock-names = "hosc", "losc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ rtc: rtc@1c20400 {
+ #clock-cells = <1>;
+ compatible = "allwinner,sun8i-v3-rtc";
+ reg = <0x01c20400 0x54>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc32k>;
+ clock-output-names = "osc32k", "osc32k-out";
+ };
+
+ pio: pinctrl@1c20800 {
+ compatible = "allwinner,sun8i-v3s-pinctrl";
+ reg = <0x01c20800 0x400>;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_PIO>, <&osc24M>,
+ <&rtc CLK_OSC32K>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ /omit-if-no-ref/
+ csi0_mclk_pin: csi0-mclk-pin {
+ pins = "PE20";
+ function = "csi_mipi";
+ };
+
+ /omit-if-no-ref/
+ csi1_8bit_pins: csi1-8bit-pins {
+ pins = "PE0", "PE2", "PE3", "PE8", "PE9",
+ "PE10", "PE11", "PE12", "PE13", "PE14",
+ "PE15";
+ function = "csi";
+ };
+
+ /omit-if-no-ref/
+ csi1_mclk_pin: csi1-mclk-pin {
+ pins = "PE1";
+ function = "csi";
+ };
+
+ i2c0_pins: i2c0-pins {
+ pins = "PB6", "PB7";
+ function = "i2c0";
+ };
+
+ /omit-if-no-ref/
+ i2c1_pb_pins: i2c1-pb-pins {
+ pins = "PB8", "PB9";
+ function = "i2c1";
+ };
+
+ /omit-if-no-ref/
+ i2c1_pe_pins: i2c1-pe-pins {
+ pins = "PE21", "PE22";
+ function = "i2c1";
+ };
+
+ uart0_pb_pins: uart0-pb-pins {
+ pins = "PB8", "PB9";
+ function = "uart0";
+ };
+
+ uart2_pins: uart2-pins {
+ pins = "PB0", "PB1";
+ function = "uart2";
+ };
+
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2", "PF3",
+ "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc1_pins: mmc1-pins {
+ pins = "PG0", "PG1", "PG2", "PG3",
+ "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ spi0_pins: spi0-pins {
+ pins = "PC0", "PC1", "PC2", "PC3";
+ function = "spi0";
+ };
+ };
+
+ timer@1c20c00 {
+ compatible = "allwinner,sun8i-v3s-timer";
+ reg = <0x01c20c00 0xa0>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
+ wdt0: watchdog@1c20ca0 {
+ compatible = "allwinner,sun6i-a31-wdt";
+ reg = <0x01c20ca0 0x20>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
+ pwm: pwm@1c21400 {
+ compatible = "allwinner,sun8i-v3s-pwm",
+ "allwinner,sun7i-a20-pwm";
+ reg = <0x01c21400 0xc>;
+ clocks = <&osc24M>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ lradc: lradc@1c22800 {
+ compatible = "allwinner,sun4i-a10-lradc-keys";
+ reg = <0x01c22800 0x400>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ codec: codec@1c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-v3s-codec";
+ reg = <0x01c22c00 0x400>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+ clock-names = "apb", "codec";
+ resets = <&ccu RST_BUS_CODEC>;
+ dmas = <&dma 15>, <&dma 15>;
+ dma-names = "rx", "tx";
+ allwinner,codec-analog-controls = <&codec_analog>;
+ status = "disabled";
+ };
+
+ codec_analog: codec-analog@1c23000 {
+ compatible = "allwinner,sun8i-v3s-codec-analog";
+ reg = <0x01c23000 0x4>;
+ };
+
+ uart0: serial@1c28000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28000 0x400>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART0>;
+ dmas = <&dma 6>, <&dma 6>;
+ dma-names = "tx", "rx";
+ resets = <&ccu RST_BUS_UART0>;
+ status = "disabled";
+ };
+
+ uart1: serial@1c28400 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28400 0x400>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART1>;
+ dmas = <&dma 7>, <&dma 7>;
+ dma-names = "tx", "rx";
+ resets = <&ccu RST_BUS_UART1>;
+ status = "disabled";
+ };
+
+ uart2: serial@1c28800 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x01c28800 0x400>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART2>;
+ dmas = <&dma 8>, <&dma 8>;
+ dma-names = "tx", "rx";
+ resets = <&ccu RST_BUS_UART2>;
+ pinctrl-0 = <&uart2_pins>;
+ pinctrl-names = "default";
+ status = "disabled";
+ };
+
+ i2c0: i2c@1c2ac00 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C0>;
+ resets = <&ccu RST_BUS_I2C0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@1c2b000 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C1>;
+ resets = <&ccu RST_BUS_I2C1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ emac: ethernet@1c30000 {
+ compatible = "allwinner,sun8i-v3s-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x10000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ };
+
+ mdio_mux: mdio-mux {
+ compatible = "allwinner,sun8i-h3-mdio-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-parent-bus = <&mdio>;
+ /* Only one MDIO is usable at the time */
+ internal_mdio: mdio@1 {
+ compatible = "allwinner,sun8i-h3-mdio-internal";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ int_mii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+ };
+ };
+
+ spi0: spi@1c68000 {
+ compatible = "allwinner,sun8i-h3-spi";
+ reg = <0x01c68000 0x1000>;
+ interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma 23>, <&dma 23>;
+ dma-names = "rx", "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ resets = <&ccu RST_BUS_SPI0>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ gic: interrupt-controller@1c81000 {
+ compatible = "arm,gic-400";
+ reg = <0x01c81000 0x1000>,
+ <0x01c82000 0x2000>,
+ <0x01c84000 0x2000>,
+ <0x01c86000 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ csi1: camera@1cb4000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb4000 0x3000>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI1_SCLK>,
+ <&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts b/arch/arm/boot/dts/allwinner/sun8i-v40-bananapi-m2-berry.dts
similarity index 100%
rename from arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
rename to arch/arm/boot/dts/allwinner/sun8i-v40-bananapi-m2-berry.dts
diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts b/arch/arm/boot/dts/allwinner/sun9i-a80-cubieboard4.dts
similarity index 100%
rename from arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
rename to arch/arm/boot/dts/allwinner/sun9i-a80-cubieboard4.dts
diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/allwinner/sun9i-a80-optimus.dts
similarity index 100%
rename from arch/arm/boot/dts/sun9i-a80-optimus.dts
rename to arch/arm/boot/dts/allwinner/sun9i-a80-optimus.dts
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/allwinner/sun9i-a80.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sun9i-a80.dtsi
rename to arch/arm/boot/dts/allwinner/sun9i-a80.dtsi
diff --git a/arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts b/arch/arm/boot/dts/allwinner/suniv-f1c100s-licheepi-nano.dts
similarity index 100%
rename from arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts
rename to arch/arm/boot/dts/allwinner/suniv-f1c100s-licheepi-nano.dts
diff --git a/arch/arm/boot/dts/suniv-f1c100s.dtsi b/arch/arm/boot/dts/allwinner/suniv-f1c100s.dtsi
similarity index 100%
rename from arch/arm/boot/dts/suniv-f1c100s.dtsi
rename to arch/arm/boot/dts/allwinner/suniv-f1c100s.dtsi
diff --git a/arch/arm/boot/dts/suniv-f1c200s-lctech-pi.dts b/arch/arm/boot/dts/allwinner/suniv-f1c200s-lctech-pi.dts
similarity index 100%
rename from arch/arm/boot/dts/suniv-f1c200s-lctech-pi.dts
rename to arch/arm/boot/dts/allwinner/suniv-f1c200s-lctech-pi.dts
diff --git a/arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts b/arch/arm/boot/dts/allwinner/suniv-f1c200s-popstick-v1.1.dts
similarity index 100%
rename from arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts
rename to arch/arm/boot/dts/allwinner/suniv-f1c200s-popstick-v1.1.dts
diff --git a/arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi b/arch/arm/boot/dts/allwinner/sunxi-bananapi-m2-plus-v1.2.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-bananapi-m2-plus-v1.2.dtsi
diff --git a/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi b/arch/arm/boot/dts/allwinner/sunxi-bananapi-m2-plus.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-bananapi-m2-plus.dtsi
diff --git a/arch/arm/boot/dts/sunxi-common-regulators.dtsi b/arch/arm/boot/dts/allwinner/sunxi-common-regulators.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-common-regulators.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-common-regulators.dtsi
diff --git a/arch/arm/boot/dts/sunxi-d1s-t113-mangopi-mq-r.dtsi b/arch/arm/boot/dts/allwinner/sunxi-d1s-t113-mangopi-mq-r.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-d1s-t113-mangopi-mq-r.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-d1s-t113-mangopi-mq-r.dtsi
diff --git a/arch/arm/boot/dts/sunxi-h3-h5-emlid-neutis.dtsi b/arch/arm/boot/dts/allwinner/sunxi-h3-h5-emlid-neutis.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-h3-h5-emlid-neutis.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-h3-h5-emlid-neutis.dtsi
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-h3-h5.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi
diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi b/arch/arm/boot/dts/allwinner/sunxi-itead-core-common.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-itead-core-common.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-itead-core-common.dtsi
diff --git a/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi b/arch/arm/boot/dts/allwinner/sunxi-libretech-all-h3-cc.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-libretech-all-h3-cc.dtsi
diff --git a/arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi b/arch/arm/boot/dts/allwinner/sunxi-libretech-all-h3-it.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-libretech-all-h3-it.dtsi
diff --git a/arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi b/arch/arm/boot/dts/allwinner/sunxi-reference-design-tablet.dtsi
similarity index 100%
rename from arch/arm/boot/dts/sunxi-reference-design-tablet.dtsi
rename to arch/arm/boot/dts/allwinner/sunxi-reference-design-tablet.dtsi
diff --git a/arch/arm/boot/dts/alphascale/Makefile b/arch/arm/boot/dts/alphascale/Makefile
new file mode 100644
index 0000000..8d1314f
--- /dev/null
+++ b/arch/arm/boot/dts/alphascale/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_MACH_ASM9260) += \
+ alphascale-asm9260-devkit.dtb
+dtb-$(CONFIG_MACH_ASM9260) += \
+ alphascale-asm9260-devkit.dtb
diff --git a/arch/arm/boot/dts/alphascale-asm9260-devkit.dts b/arch/arm/boot/dts/alphascale/alphascale-asm9260-devkit.dts
similarity index 100%
rename from arch/arm/boot/dts/alphascale-asm9260-devkit.dts
rename to arch/arm/boot/dts/alphascale/alphascale-asm9260-devkit.dts
diff --git a/arch/arm/boot/dts/alphascale-asm9260.dtsi b/arch/arm/boot/dts/alphascale/alphascale-asm9260.dtsi
similarity index 100%
rename from arch/arm/boot/dts/alphascale-asm9260.dtsi
rename to arch/arm/boot/dts/alphascale/alphascale-asm9260.dtsi
diff --git a/arch/arm/boot/dts/am335x-baltos-ir2110.dts b/arch/arm/boot/dts/am335x-baltos-ir2110.dts
deleted file mode 100644
index 75992ee..0000000
--- a/arch/arm/boot/dts/am335x-baltos-ir2110.dts
+++ /dev/null
@@ -1,227 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-/*
- * VScom OnRISC
- * http://www.vscom.de
- */
-
-/dts-v1/;
-
-#include "am335x-baltos.dtsi"
-#include "am335x-baltos-leds.dtsi"
-
-/ {
- model = "OnRISC Baltos iR 2110";
-};
-
-&am33xx_pinmux {
- uart1_pins: pinmux_uart1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART1_RXD, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_TXD, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_CTSN, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_RTSN, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_VSYNC, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* lcd_vsync.gpio2[22] DTR */
- AM33XX_PADCONF(AM335X_PIN_LCD_HSYNC, PIN_INPUT_PULLDOWN, MUX_MODE7) /* lcd_hsync.gpio2[23] DSR */
- AM33XX_PADCONF(AM335X_PIN_LCD_PCLK, PIN_INPUT_PULLDOWN, MUX_MODE7) /* lcd_pclk.gpio2[24] DCD */
- AM33XX_PADCONF(AM335X_PIN_LCD_AC_BIAS_EN, PIN_INPUT_PULLDOWN, MUX_MODE7) /* lcd_ac_bias_en.gpio2[25] RI */
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD15, PIN_INPUT, MUX_MODE7) /* MMC1 CD */
- >;
- };
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins>;
- dtr-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>;
- dsr-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
- dcd-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;
- rng-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>;
-
- status = "okay";
-};
-
-&usb0_phy {
- status = "okay";
-};
-
-&usb0 {
- status = "okay";
- dr_mode = "host";
-};
-
-&davinci_mdio_sw {
- phy0: ethernet-phy@0 {
- reg = <1>;
- };
-};
-
-&cpsw_port1 {
- phy-mode = "rmii";
- ti,dual-emac-pvid = <1>;
- phy-handle = <&phy0>;
-};
-
-&cpsw_port2 {
- phy-mode = "rgmii-id";
- ti,dual-emac-pvid = <2>;
- phy-handle = <&phy1>;
-};
-
-&mmc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins>;
- cd-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
-};
-
-&gpio0 {
- gpio-line-names =
- "MDIO",
- "MDC",
- "NC",
- "NC",
- "I2C1_SDA",
- "I2C1_SCL",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "UART1_CTSN",
- "UART1_RTSN",
- "UART1_RX",
- "UART1_TX",
- "onrisc:blue:wlan",
- "onrisc:green:app",
- "USB0_DRVVBUS",
- "ETH2_INT",
- "NC",
- "RMII1_TXD1",
- "MMC1_DAT0",
- "MMC1_DAT1",
- "NC",
- "NC",
- "MMC1_DAT2",
- "MMC1_DAT3",
- "RMII1_TXD0",
- "NC",
- "GPMC_WAIT0",
- "GPMC_WP_N";
-};
-
-&gpio1 {
- gpio-line-names =
- "GPMC_AD0",
- "GPMC_AD1",
- "GPMC_AD2",
- "GPMC_AD3",
- "GPMC_AD4",
- "GPMC_AD5",
- "GPMC_AD6",
- "GPMC_AD7",
- "NC",
- "NC",
- "CONSOLE_RX",
- "CONSOLE_TX",
- "NC",
- "NC",
- "NC",
- "SD_CD",
- "RGMII2_TCTL",
- "RGMII2_RCTL",
- "RGMII2_TD3",
- "RGMII2_TD2",
- "RGMII2_TD1",
- "RGMII2_TD0",
- "RGMII2_TCLK",
- "RGMII2_RCLK",
- "RGMII2_RD3",
- "RGMII2_RD2",
- "RGMII2_RD1",
- "RGMII2_RD0",
- "PMIC_INT1",
- "GPMC_CSN0_Flash",
- "MMC1_CLK",
- "MMC1_CMD";
-};
-
-&gpio2 {
- gpio-line-names =
- "GPMC_CSN3_BUS",
- "GPMC_CLK",
- "GPMC_ADVN_ALE",
- "GPMC_OEN_RE_N",
- "GPMC_WE_N",
- "GPMC_BEN0_CLE",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "SW2_0",
- "SW2_1",
- "RMII1_RXD1",
- "RMII1_RXD0",
- "UART1_DTR",
- "UART1_DSR",
- "UART1_DCD",
- "UART1_RI",
- "MMC0_DAT3",
- "MMC0_DAT2",
- "MMC0_DAT1",
- "MMC0_DAT0",
- "MMC0_CLK",
- "MMC0_CMD";
-};
-
-&gpio3 {
- gpio-line-names =
- "onrisc:red:power",
- "RMII1_CRS_DV",
- "RMII1_RXER",
- "RMII1_TXEN",
- "NC",
- "NC",
- "NC",
- "WLAN_IRQ",
- "WLAN_EN",
- "SW2_2",
- "SW2_3",
- "NC",
- "NC",
- "NC",
- "ModeA0",
- "ModeA1",
- "ModeA2",
- "ModeA3",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC";
-};
diff --git a/arch/arm/boot/dts/am335x-baltos-ir3220.dts b/arch/arm/boot/dts/am335x-baltos-ir3220.dts
deleted file mode 100644
index 087e084..0000000
--- a/arch/arm/boot/dts/am335x-baltos-ir3220.dts
+++ /dev/null
@@ -1,273 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-/*
- * VScom OnRISC
- * http://www.vscom.de
- */
-
-/dts-v1/;
-
-#include "am335x-baltos.dtsi"
-#include "am335x-baltos-leds.dtsi"
-
-/ {
- model = "OnRISC Baltos iR 3220";
-};
-
-&am33xx_pinmux {
- tca6416_pins: pinmux_tca6416_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR1, PIN_INPUT_PULLUP, MUX_MODE7) /* xdma_event_intr1.gpio0[20] tca6416 stuff */
- >;
- };
-
- uart1_pins: pinmux_uart1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART1_RXD, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_TXD, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_CTSN, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_RTSN, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_VSYNC, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* lcd_vsync.gpio2[22] DTR */
- AM33XX_PADCONF(AM335X_PIN_LCD_HSYNC, PIN_INPUT_PULLDOWN, MUX_MODE7) /* lcd_hsync.gpio2[23] DSR */
- AM33XX_PADCONF(AM335X_PIN_LCD_PCLK, PIN_INPUT_PULLDOWN, MUX_MODE7) /* lcd_pclk.gpio2[24] DCD */
- AM33XX_PADCONF(AM335X_PIN_LCD_AC_BIAS_EN, PIN_INPUT_PULLDOWN, MUX_MODE7) /* lcd_ac_bias_en.gpio2[25] RI */
- >;
- };
-
- uart2_pins: pinmux_uart2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT, MUX_MODE1) /* spi0_sclk.uart2_rxd_mux3 */
- AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_OUTPUT, MUX_MODE1) /* spi0_d0.uart2_txd_mux3 */
- AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLDOWN, MUX_MODE2) /* i2c0_sda.uart2_ctsn_mux0 */
- AM33XX_PADCONF(AM335X_PIN_I2C0_SCL, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* i2c0_scl.uart2_rtsn_mux0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad12.gpio1[12] DTR */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad13.gpio1[13] DSR */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD14, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad14.gpio1[14] DCD */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD15, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad15.gpio1[15] RI */
-
- AM33XX_PADCONF(AM335X_PIN_MCASP0_ACLKR, PIN_INPUT_PULLUP, MUX_MODE7) /* mcasp0_aclkr.gpio3[18], INPUT_PULLDOWN | MODE7 */
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT, MUX_MODE7) /* MMC1 CD */
- >;
- };
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins>;
- dtr-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>;
- dsr-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
- dcd-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;
- rng-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>;
-
- status = "okay";
-};
-
-&uart2 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart2_pins>;
- dtr-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
- dsr-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
- dcd-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
- rng-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
-
- status = "okay";
-};
-
-&i2c1 {
- tca6416: gpio@20 {
- compatible = "ti,tca6416";
- reg = <0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-parent = <&gpio0>;
- interrupts = <20 IRQ_TYPE_EDGE_RISING>;
- pinctrl-names = "default";
- pinctrl-0 = <&tca6416_pins>;
- gpio-line-names = "GP_IN0", "GP_IN1", "GP_IN2", "GP_IN3",
- "GP_OUT0", "GP_OUT1", "GP_OUT2", "GP_OUT3",
- "ModeA0", "ModeA1", "ModeA2", "ModeA3",
- "ModeB0", "ModeB1", "ModeB2", "ModeB3";
- };
-};
-
-&usb0_phy {
- status = "okay";
-};
-
-&usb0 {
- status = "okay";
- dr_mode = "host";
-};
-
-&cpsw_port1 {
- phy-mode = "rmii";
- ti,dual-emac-pvid = <1>;
- fixed-link {
- speed = <100>;
- full-duplex;
- };
-};
-
-&cpsw_port2 {
- phy-mode = "rgmii-id";
- ti,dual-emac-pvid = <2>;
- phy-handle = <&phy1>;
-};
-
-&mmc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins>;
- cd-gpios = <&gpio2 18 GPIO_ACTIVE_LOW>;
-};
-
-&gpio0 {
- gpio-line-names =
- "MDIO",
- "MDC",
- "UART2_RX",
- "UART2_TX",
- "I2C1_SDA",
- "I2C1_SCL",
- "WLAN_BTN",
- "W_DISABLE",
- "NC",
- "NC",
- "NC",
- "NC",
- "UART1_CTSN",
- "UART1_RTSN",
- "UART1_RX",
- "UART1_TX",
- "onrisc:blue:wlan",
- "onrisc:green:app",
- "USB0_DRVVBUS",
- "ETH2_INT",
- "TCA6416_INT",
- "RMII1_TXD1",
- "MMC1_DAT0",
- "MMC1_DAT1",
- "NC",
- "NC",
- "MMC1_DAT2",
- "MMC1_DAT3",
- "RMII1_TXD0",
- "NC",
- "GPMC_WAIT0",
- "GPMC_WP_N";
-};
-
-&gpio1 {
- gpio-line-names =
- "GPMC_AD0",
- "GPMC_AD1",
- "GPMC_AD2",
- "GPMC_AD3",
- "GPMC_AD4",
- "GPMC_AD5",
- "GPMC_AD6",
- "GPMC_AD7",
- "NC",
- "NC",
- "CONSOLE_RX",
- "CONSOLE_TX",
- "UART2_DTR",
- "UART2_DSR",
- "UART2_DCD",
- "UART2_RI",
- "RGMII2_TCTL",
- "RGMII2_RCTL",
- "RGMII2_TD3",
- "RGMII2_TD2",
- "RGMII2_TD1",
- "RGMII2_TD0",
- "RGMII2_TCLK",
- "RGMII2_RCLK",
- "RGMII2_RD3",
- "RGMII2_RD2",
- "RGMII2_RD1",
- "RGMII2_RD0",
- "PMIC_INT1",
- "GPMC_CSN0_Flash",
- "MMC1_CLK",
- "MMC1_CMD";
-};
-
-&gpio2 {
- gpio-line-names =
- "GPMC_CSN3_BUS",
- "GPMC_CLK",
- "GPMC_ADVN_ALE",
- "GPMC_OEN_RE_N",
- "GPMC_WE_N",
- "GPMC_BEN0_CLE",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "SD_CD",
- "SD_WP",
- "RMII1_RXD1",
- "RMII1_RXD0",
- "UART1_DTR",
- "UART1_DSR",
- "UART1_DCD",
- "UART1_RI",
- "MMC0_DAT3",
- "MMC0_DAT2",
- "MMC0_DAT1",
- "MMC0_DAT0",
- "MMC0_CLK",
- "MMC0_CMD";
-};
-
-&gpio3 {
- gpio-line-names =
- "onrisc:red:power",
- "RMII1_CRS_DV",
- "RMII1_RXER",
- "RMII1_TXEN",
- "3G_PWR_EN",
- "UART2_CTSN",
- "UART2_RTSN",
- "WLAN_IRQ",
- "WLAN_EN",
- "NC",
- "NC",
- "NC",
- "NC",
- "USB1_DRVVBUS",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC";
-};
diff --git a/arch/arm/boot/dts/am335x-baltos-ir5221.dts b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
deleted file mode 100644
index faeb39a..0000000
--- a/arch/arm/boot/dts/am335x-baltos-ir5221.dts
+++ /dev/null
@@ -1,297 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-/*
- * VScom OnRISC
- * http://www.vscom.de
- */
-
-/dts-v1/;
-
-#include "am335x-baltos.dtsi"
-#include "am335x-baltos-leds.dtsi"
-
-/ {
- model = "OnRISC Baltos iR 5221";
-};
-
-&am33xx_pinmux {
- tca6416_pins: pinmux_tca6416_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR1, PIN_INPUT_PULLUP, MUX_MODE7) /* xdma_event_intr1.gpio0[20] tca6416 stuff */
- >;
- };
-
-
- dcan1_pins: pinmux_dcan1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_OUTPUT, MUX_MODE2) /* uart0_ctsn.dcan1_tx_mux0 */
- AM33XX_PADCONF(AM335X_PIN_UART0_RTSN, PIN_INPUT, MUX_MODE2) /* uart0_rtsn.dcan1_rx_mux0 */
- >;
- };
-
- uart1_pins: pinmux_uart1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART1_RXD, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_TXD, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_CTSN, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_RTSN, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_VSYNC, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* lcd_vsync.gpio2[22] DTR */
- AM33XX_PADCONF(AM335X_PIN_LCD_HSYNC, PIN_INPUT_PULLDOWN, MUX_MODE7) /* lcd_hsync.gpio2[23] DSR */
- AM33XX_PADCONF(AM335X_PIN_LCD_PCLK, PIN_INPUT_PULLDOWN, MUX_MODE7) /* lcd_pclk.gpio2[24] DCD */
- AM33XX_PADCONF(AM335X_PIN_LCD_AC_BIAS_EN, PIN_INPUT_PULLDOWN, MUX_MODE7) /* lcd_ac_bias_en.gpio2[25] RI */
- >;
- };
-
- uart2_pins: pinmux_uart2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT, MUX_MODE1) /* spi0_sclk.uart2_rxd_mux3 */
- AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_OUTPUT, MUX_MODE1) /* spi0_d0.uart2_txd_mux3 */
- AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLDOWN, MUX_MODE2) /* i2c0_sda.uart2_ctsn_mux0 */
- AM33XX_PADCONF(AM335X_PIN_I2C0_SCL, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* i2c0_scl.uart2_rtsn_mux0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad12.gpio1[12] DTR */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad13.gpio1[13] DSR */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD14, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad14.gpio1[14] DCD */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD15, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad15.gpio1[15] RI */
-
- AM33XX_PADCONF(AM335X_PIN_MCASP0_ACLKR, PIN_INPUT_PULLUP, MUX_MODE7) /* mcasp0_aclkr.gpio3[18], INPUT_PULLDOWN | MODE7 */
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT, MUX_MODE7) /* MMC1 CD */
- >;
- };
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins>;
- dtr-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>;
- dsr-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
- dcd-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;
- rng-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>;
-
- status = "okay";
-};
-
-&uart2 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart2_pins>;
- dtr-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
- dsr-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
- dcd-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
- rng-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
-
- status = "okay";
-};
-
-&i2c1 {
- tca6416: gpio@20 {
- compatible = "ti,tca6416";
- reg = <0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-parent = <&gpio0>;
- interrupts = <20 IRQ_TYPE_EDGE_RISING>;
- pinctrl-names = "default";
- pinctrl-0 = <&tca6416_pins>;
- gpio-line-names = "GP_IN0", "GP_IN1", "GP_IN2", "GP_IN3",
- "GP_OUT0", "GP_OUT1", "GP_OUT2", "GP_OUT3",
- "ModeA0", "ModeA1", "ModeA2", "ModeA3",
- "ModeB0", "ModeB1", "ModeB2", "ModeB3";
- };
-};
-
-&usb0_phy {
- status = "okay";
-};
-
-&usb1_phy {
- status = "okay";
-};
-
-&usb0 {
- status = "okay";
- dr_mode = "host";
-};
-
-&usb1 {
- status = "okay";
- dr_mode = "host";
-};
-
-&cpsw_port1 {
- phy-mode = "rmii";
- ti,dual-emac-pvid = <1>;
- fixed-link {
- speed = <100>;
- full-duplex;
- };
-};
-
-&cpsw_port2 {
- phy-mode = "rgmii-id";
- ti,dual-emac-pvid = <2>;
- phy-handle = <&phy1>;
-};
-
-&dcan1 {
- pinctrl-names = "default";
- pinctrl-0 = <&dcan1_pins>;
-
- status = "okay";
-};
-
-&mmc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins>;
- cd-gpios = <&gpio2 18 GPIO_ACTIVE_LOW>;
-};
-
-&gpio0 {
- gpio-line-names =
- "MDIO",
- "MDC",
- "UART2_RX",
- "UART2_TX",
- "I2C1_SDA",
- "I2C1_SCL",
- "WLAN_BTN",
- "W_DISABLE",
- "NC",
- "NC",
- "NC",
- "NC",
- "UART1_CTSN",
- "UART1_RTSN",
- "UART1_RX",
- "UART1_TX",
- "onrisc:blue:wlan",
- "onrisc:green:app",
- "USB0_DRVVBUS",
- "ETH2_INT",
- "TCA6416_INT",
- "RMII1_TXD1",
- "MMC1_DAT0",
- "MMC1_DAT1",
- "NC",
- "NC",
- "MMC1_DAT2",
- "MMC1_DAT3",
- "RMII1_TXD0",
- "NC",
- "GPMC_WAIT0",
- "GPMC_WP_N";
-};
-
-&gpio1 {
- gpio-line-names =
- "GPMC_AD0",
- "GPMC_AD1",
- "GPMC_AD2",
- "GPMC_AD3",
- "GPMC_AD4",
- "GPMC_AD5",
- "GPMC_AD6",
- "GPMC_AD7",
- "DCAN1_TX",
- "DCAN1_RX",
- "CONSOLE_RX",
- "CONSOLE_TX",
- "UART2_DTR",
- "UART2_DSR",
- "UART2_DCD",
- "UART2_RI",
- "RGMII2_TCTL",
- "RGMII2_RCTL",
- "RGMII2_TD3",
- "RGMII2_TD2",
- "RGMII2_TD1",
- "RGMII2_TD0",
- "RGMII2_TCLK",
- "RGMII2_RCLK",
- "RGMII2_RD3",
- "RGMII2_RD2",
- "RGMII2_RD1",
- "RGMII2_RD0",
- "PMIC_INT1",
- "GPMC_CSN0_Flash",
- "MMC1_CLK",
- "MMC1_CMD";
-};
-
-&gpio2 {
- gpio-line-names =
- "GPMC_CSN3_BUS",
- "GPMC_CLK",
- "GPMC_ADVN_ALE",
- "GPMC_OEN_RE_N",
- "GPMC_WE_N",
- "GPMC_BEN0_CLE",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "SD_CD",
- "SD_WP",
- "RMII1_RXD1",
- "RMII1_RXD0",
- "UART1_DTR",
- "UART1_DSR",
- "UART1_DCD",
- "UART1_RI",
- "MMC0_DAT3",
- "MMC0_DAT2",
- "MMC0_DAT1",
- "MMC0_DAT0",
- "MMC0_CLK",
- "MMC0_CMD";
-};
-
-&gpio3 {
- gpio-line-names =
- "onrisc:red:power",
- "RMII1_CRS_DV",
- "RMII1_RXER",
- "RMII1_TXEN",
- "3G_PWR_EN",
- "UART2_CTSN",
- "UART2_RTSN",
- "WLAN_IRQ",
- "WLAN_EN",
- "NC",
- "NC",
- "NC",
- "NC",
- "USB1_DRVVBUS",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC",
- "NC";
-};
diff --git a/arch/arm/boot/dts/am335x-baltos-leds.dtsi b/arch/arm/boot/dts/am335x-baltos-leds.dtsi
deleted file mode 100644
index 0250146..0000000
--- a/arch/arm/boot/dts/am335x-baltos-leds.dtsi
+++ /dev/null
@@ -1,47 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-/*
- * VScom OnRISC
- * http://www.vscom.de
- */
-
-/*#include "am33xx.dtsi"*/
-
-/ {
- leds {
- pinctrl-names = "default";
- pinctrl-0 = <&user_leds>;
-
- compatible = "gpio-leds";
-
- led-power {
- label = "onrisc:red:power";
- linux,default-trigger = "default-on";
- gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
- default-state = "on";
- };
- led-wlan {
- label = "onrisc:blue:wlan";
- gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
- led-app {
- label = "onrisc:green:app";
- gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
- };
-};
-
-&am33xx_pinmux {
- user_leds: pinmux_user_leds {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_COL, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* mii1_col.gpio3_0 PWR LED */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* mii1_txd3.gpio0_16 WLAN LED */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* mii1_txd2.gpio0_17 APP LED */
- >;
- };
-};
diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
deleted file mode 100644
index 6161c892..0000000
--- a/arch/arm/boot/dts/am335x-baltos.dtsi
+++ /dev/null
@@ -1,401 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-/*
- * VScom OnRISC
- * http://www.vscom.de
- */
-
-#include "am33xx.dtsi"
-#include <dt-bindings/pwm/pwm.h>
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- compatible = "vscom,onrisc", "ti,am33xx";
-
- cpus {
- cpu@0 {
- cpu0-supply = <&vdd1_reg>;
- };
- };
-
- memory@80000000 {
- device_type = "memory";
- reg = <0x80000000 0x10000000>; /* 256 MB */
- };
-
- vbat: fixedregulator0 {
- compatible = "regulator-fixed";
- regulator-name = "vbat";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-boot-on;
- };
-
- wl12xx_vmmc: fixedregulator2 {
- pinctrl-names = "default";
- pinctrl-0 = <&wl12xx_gpio>;
- compatible = "regulator-fixed";
- regulator-name = "vwl1271";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- gpio = <&gpio3 8 0>;
- startup-delay-us = <70000>;
- enable-active-high;
- };
-};
-
-&am33xx_pinmux {
- mmc2_pins: pinmux_mmc2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD8, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_ad8.mmc1_dat0_mux0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD9, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_ad9.mmc1_dat1_mux0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD10, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_ad10.mmc1_dat2_mux0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD11, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_ad11.mmc1_dat3_mux0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN1, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_csn1.mmc1_clk_mux0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN2, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_csn2.mmc1_cmd_mux0 */
- AM33XX_PADCONF(AM335X_PIN_EMU0, PIN_INPUT_PULLUP, MUX_MODE7) /* emu0.gpio3[7] */
- >;
- };
-
- wl12xx_gpio: pinmux_wl12xx_gpio {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_EMU1, PIN_OUTPUT_PULLUP, MUX_MODE7) /* emu1.gpio3[8] */
- >;
- };
-
- tps65910_pins: pinmux_tps65910_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_BEN1, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_ben1.gpio1[28] */
- >;
- };
-
- i2c1_pins: pinmux_i2c1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_D1, PIN_INPUT, MUX_MODE2) /* spi0_d1.i2c1_sda_mux3 */
- AM33XX_PADCONF(AM335X_PIN_SPI0_CS0, PIN_INPUT, MUX_MODE2) /* spi0_cs0.i2c1_scl_mux3 */
- >;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins = <
- /* Slave 1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_CRS, PIN_INPUT_PULLDOWN, MUX_MODE1) /* mii1_crs.rmii1_crs_dv */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_OUTPUT_PULLDOWN, MUX_MODE1) /* mii1_tx_en.rmii1_txen */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_OUTPUT_PULLDOWN, MUX_MODE1) /* mii1_txd1.rmii1_txd1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLDOWN, MUX_MODE1) /* mii1_txd0.rmii1_txd0 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE1) /* mii1_rxd1.rmii1_rxd1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE1) /* mii1_rxd0.rmii1_rxd0 */
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE0) /* rmii1_ref_clk.rmii1_refclk */
-
-
- /* Slave 2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A0, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a0.rgmii2_tctl */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A1, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a1.rgmii2_rctl */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A2, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a2.rgmii2_td3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A3, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a3.rgmii2_td2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A4, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a4.rgmii2_td1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a5.rgmii2_td0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A6, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a6.rgmii2_tclk */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A7, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a7.rgmii2_rclk */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A8, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a8.rgmii2_rd3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A9, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a9.rgmii2_rd2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A10, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a10.rgmii2_rd1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A11, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a11.rgmii2_rd0 */
- >;
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins = <
- /* Slave 1 reset value */
- AM33XX_PADCONF(AM335X_PIN_MII1_CRS, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
-
- /* Slave 2 reset value*/
- AM33XX_PADCONF(AM335X_PIN_GPMC_A0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A4, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A6, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A7, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A8, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A9, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A10, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A11, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- davinci_mdio_default: davinci_mdio_default {
- pinctrl-single,pins = <
- /* MDIO */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLUP | SLEWCTRL_FAST, MUX_MODE0) /* mdio_data.mdio_data */
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLUP, MUX_MODE0) /* mdio_clk.mdio_clk */
- >;
- };
-
- davinci_mdio_sleep: davinci_mdio_sleep {
- pinctrl-single,pins = <
- /* MDIO reset value */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- nandflash_pins_s0: nandflash_pins_s0 {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD0, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD1, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD2, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD3, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD4, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_wait0.gpmc_wait0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_wpn.gpio0_31 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT, MUX_MODE0) /* gpmc_csn0.gpmc_csn0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_OUTPUT, MUX_MODE0) /* gpmc_advn_ale.gpmc_advn_ale */
- AM33XX_PADCONF(AM335X_PIN_GPMC_OEN_REN, PIN_OUTPUT, MUX_MODE0) /* gpmc_oen_ren.gpmc_oen_ren */
- AM33XX_PADCONF(AM335X_PIN_GPMC_WEN, PIN_OUTPUT, MUX_MODE0) /* gpmc_wen.gpmc_wen */
- AM33XX_PADCONF(AM335X_PIN_GPMC_BEN0_CLE, PIN_OUTPUT, MUX_MODE0) /* gpmc_be0n_cle.gpmc_be0n_cle */
- >;
- };
-};
-
-&elm {
- status = "okay";
-};
-
-&gpmc {
- pinctrl-names = "default";
- pinctrl-0 = <&nandflash_pins_s0>;
- ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
- status = "okay";
-
- nand@0,0 {
- compatible = "ti,omap2-nand";
- reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
- interrupt-parent = <&gpmc>;
- interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
- <1 IRQ_TYPE_NONE>; /* termcount */
- rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
- nand-bus-width = <8>;
- ti,nand-ecc-opt = "bch8";
- ti,nand-xfer-type = "prefetch-dma";
-
- gpmc,device-nand = "true";
- gpmc,device-width = <1>;
- gpmc,sync-clk-ps = <0>;
- gpmc,cs-on-ns = <0>;
- gpmc,cs-rd-off-ns = <44>;
- gpmc,cs-wr-off-ns = <44>;
- gpmc,adv-on-ns = <6>;
- gpmc,adv-rd-off-ns = <34>;
- gpmc,adv-wr-off-ns = <44>;
- gpmc,we-on-ns = <0>;
- gpmc,we-off-ns = <40>;
- gpmc,oe-on-ns = <0>;
- gpmc,oe-off-ns = <54>;
- gpmc,access-ns = <64>;
- gpmc,rd-cycle-ns = <82>;
- gpmc,wr-cycle-ns = <82>;
- gpmc,bus-turnaround-ns = <0>;
- gpmc,cycle2cycle-delay-ns = <0>;
- gpmc,clk-activation-ns = <0>;
- gpmc,wr-access-ns = <40>;
- gpmc,wr-data-mux-bus-ns = <0>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ti,elm-id = <&elm>;
- };
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-
- status = "okay";
-};
-
-&i2c1 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c1_pins>;
-
- status = "okay";
- clock-frequency = <400000>;
-
- tps: tps@2d {
- reg = <0x2d>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-parent = <&gpio1>;
- interrupts = <28 IRQ_TYPE_EDGE_RISING>;
- pinctrl-names = "default";
- pinctrl-0 = <&tps65910_pins>;
- };
-
- at24@50 {
- compatible = "atmel,24c02";
- pagesize = <8>;
- reg = <0x50>;
- };
-};
-
-#include "tps65910.dtsi"
-
-&tps {
- vcc1-supply = <&vbat>;
- vcc2-supply = <&vbat>;
- vcc3-supply = <&vbat>;
- vcc4-supply = <&vbat>;
- vcc5-supply = <&vbat>;
- vcc6-supply = <&vbat>;
- vcc7-supply = <&vbat>;
- vccio-supply = <&vbat>;
-
- ti,en-ck32k-xtal = <1>;
-
- regulators {
- vrtc_reg: regulator@0 {
- regulator-always-on;
- };
-
- vio_reg: regulator@1 {
- regulator-always-on;
- };
-
- vdd1_reg: regulator@2 {
- /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
- regulator-name = "vdd_mpu";
- regulator-min-microvolt = <912500>;
- regulator-max-microvolt = <1351500>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vdd2_reg: regulator@3 {
- /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
- regulator-name = "vdd_core";
- regulator-min-microvolt = <912500>;
- regulator-max-microvolt = <1150000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vdd3_reg: regulator@4 {
- regulator-always-on;
- };
-
- vdig1_reg: regulator@5 {
- regulator-always-on;
- };
-
- vdig2_reg: regulator@6 {
- regulator-always-on;
- };
-
- vpll_reg: regulator@7 {
- regulator-always-on;
- };
-
- vdac_reg: regulator@8 {
- regulator-always-on;
- };
-
- vaux1_reg: regulator@9 {
- regulator-always-on;
- };
-
- vaux2_reg: regulator@10 {
- regulator-always-on;
- };
-
- vaux33_reg: regulator@11 {
- regulator-always-on;
- };
-
- vmmc_reg: regulator@12 {
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
- };
-};
-
-&mac_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&cpsw_default>;
- pinctrl-1 = <&cpsw_sleep>;
-
- status = "okay";
-};
-
-&davinci_mdio_sw {
- status = "okay";
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&davinci_mdio_default>;
- pinctrl-1 = <&davinci_mdio_sleep>;
-
- phy1: ethernet-phy@1 {
- reg = <7>;
- eee-broken-100tx;
- eee-broken-1000t;
- };
-};
-
-&mmc1 {
- vmmc-supply = <&vmmc_reg>;
- status = "okay";
-};
-
-&mmc2 {
- status = "okay";
- vmmc-supply = <&wl12xx_vmmc>;
- non-removable;
- bus-width = <4>;
- cap-power-off-card;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc2_pins>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- wlcore: wlcore@2 {
- compatible = "ti,wl1835";
- reg = <2>;
- interrupt-parent = <&gpio3>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- };
-};
-
-&sham {
- status = "okay";
-};
-
-&aes {
- status = "okay";
-};
-
-&gpio0_target {
- ti,no-reset-on-init;
-};
-
-&gpio3_target {
- ti,no-reset-on-init;
-};
diff --git a/arch/arm/boot/dts/am335x-base0033.dts b/arch/arm/boot/dts/am335x-base0033.dts
deleted file mode 100644
index 89c00ce..0000000
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ /dev/null
@@ -1,92 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * am335x-base0033.dts - Device Tree file for IGEP AQUILA EXPANSION
- *
- * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz
- */
-
-#include "am335x-igep0033.dtsi"
-
-/ {
- model = "IGEP COM AM335x on AQUILA Expansion";
- compatible = "isee,am335x-base0033", "isee,am335x-igep0033", "ti,am33xx";
-
- hdmi {
- compatible = "ti,tilcdc,slave";
- i2c = <&i2c0>;
- pinctrl-names = "default", "off";
- pinctrl-0 = <&nxp_hdmi_pins>;
- pinctrl-1 = <&nxp_hdmi_off_pins>;
- status = "okay";
- };
-
- leds_base {
- pinctrl-names = "default";
- pinctrl-0 = <&leds_base_pins>;
-
- compatible = "gpio-leds";
-
- led0 {
- label = "base:red:user";
- gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>; /* gpio1_21 */
- default-state = "off";
- };
-
- led1 {
- label = "base:green:user";
- gpios = <&gpio2 0 GPIO_ACTIVE_HIGH>; /* gpio2_0 */
- default-state = "off";
- };
- };
-};
-
-&am33xx_pinmux {
- nxp_hdmi_pins: pinmux_nxp_hdmi_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR0, PIN_OUTPUT, MUX_MODE3) /* xdma_event_intr0.clkout1 */
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA0, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA1, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA2, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA3, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA4, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA5, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA6, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA7, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA8, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA9, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA10, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA11, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA12, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA13, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA14, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA15, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_VSYNC, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_HSYNC, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_PCLK, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_AC_BIAS_EN, PIN_OUTPUT, MUX_MODE0)
- >;
- };
- nxp_hdmi_off_pins: pinmux_nxp_hdmi_off_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR0, PIN_OUTPUT, MUX_MODE3) /* xdma_event_intr0.clkout1 */
- >;
- };
-
- leds_base_pins: pinmux_leds_base_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_a5.gpio1_21 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN3, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_csn3.gpio2_0 */
- >;
- };
-};
-
-&lcdc {
- status = "okay";
-};
-
-&i2c0 {
- eeprom: eeprom@50 {
- compatible = "atmel,24c256";
- reg = <0x50>;
- };
-};
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
deleted file mode 100644
index 02e04a1..0000000
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ /dev/null
@@ -1,411 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-/ {
- cpus {
- cpu@0 {
- cpu0-supply = <&dcdc2_reg>;
- };
- };
-
- memory@80000000 {
- device_type = "memory";
- reg = <0x80000000 0x10000000>; /* 256 MB */
- };
-
- chosen {
- stdout-path = &uart0;
- };
-
- leds {
- pinctrl-names = "default";
- pinctrl-0 = <&user_leds_s0>;
-
- compatible = "gpio-leds";
-
- led2 {
- label = "beaglebone:green:heartbeat";
- gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- default-state = "off";
- };
-
- led3 {
- label = "beaglebone:green:mmc0";
- gpios = <&gpio1 22 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "mmc0";
- default-state = "off";
- };
-
- led4 {
- label = "beaglebone:green:usr2";
- gpios = <&gpio1 23 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "cpu0";
- default-state = "off";
- };
-
- led5 {
- label = "beaglebone:green:usr3";
- gpios = <&gpio1 24 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "mmc1";
- default-state = "off";
- };
- };
-
- vmmcsd_fixed: fixedregulator0 {
- compatible = "regulator-fixed";
- regulator-name = "vmmcsd_fixed";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-};
-
-&am33xx_pinmux {
- pinctrl-names = "default";
- pinctrl-0 = <&clkout2_pin>;
-
- user_leds_s0: user_leds_s0 {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_a5.gpio1_21 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A6, PIN_OUTPUT_PULLUP, MUX_MODE7) /* gpmc_a6.gpio1_22 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A7, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_a7.gpio1_23 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A8, PIN_OUTPUT_PULLUP, MUX_MODE7) /* gpmc_a8.gpio1_24 */
- >;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLUP, MUX_MODE0) /* i2c0_sda.i2c0_sda */
- AM33XX_PADCONF(AM335X_PIN_I2C0_SCL, PIN_INPUT_PULLUP, MUX_MODE0) /* i2c0_scl.i2c0_scl */
- >;
- };
-
- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART1_CTSN, PIN_INPUT_PULLUP, MUX_MODE3) /* uart1_ctsn.i2c2_sda */
- AM33XX_PADCONF(AM335X_PIN_UART1_RTSN, PIN_INPUT_PULLUP, MUX_MODE3) /* uart1_rtsn.i2c2_scl */
- >;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR1, PIN_OUTPUT_PULLDOWN, MUX_MODE3) /* xdma_event_intr1.clkout2 */
- >;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins = <
- /* Slave 1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins = <
- /* Slave 1 reset value */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- davinci_mdio_default: davinci_mdio_default {
- pinctrl-single,pins = <
- /* MDIO */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLUP | SLEWCTRL_FAST, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- davinci_mdio_sleep: davinci_mdio_sleep {
- pinctrl-single,pins = <
- /* MDIO reset value */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_CS1, PIN_INPUT, MUX_MODE7) /* spio0_cs1.gpio0_6 */
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT1, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT2, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT3, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CMD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CLK, PIN_INPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- emmc_pins: pinmux_emmc_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN1, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_csn1.mmc1_clk */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN2, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_csn2.mmc1_cmd */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD0, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad0.mmc1_dat0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD1, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad1.mmc1_dat1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD2, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad2.mmc1_dat2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD3, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad3.mmc1_dat3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD4, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad4.mmc1_dat4 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad5.mmc1_dat5 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad6.mmc1_dat6 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad7.mmc1_dat7 */
- >;
- };
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-
- status = "okay";
-};
-
-&usb0 {
- dr_mode = "peripheral";
- interrupts-extended = <&intc 18 &tps 0>;
- interrupt-names = "mc", "vbus";
-};
-
-&usb1 {
- dr_mode = "host";
-};
-
-&i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
-
- status = "okay";
- clock-frequency = <400000>;
-
- tps: tps@24 {
- reg = <0x24>;
- };
-
- baseboard_eeprom: baseboard_eeprom@50 {
- compatible = "atmel,24c256";
- reg = <0x50>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- baseboard_data: baseboard_data@0 {
- reg = <0 0x100>;
- };
- };
-};
-
-&i2c2 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c2_pins>;
-
- status = "okay";
- clock-frequency = <100000>;
-
- cape_eeprom0: cape_eeprom0@54 {
- compatible = "atmel,24c256";
- reg = <0x54>;
- #address-cells = <1>;
- #size-cells = <1>;
- cape0_data: cape_data@0 {
- reg = <0 0x100>;
- };
- };
-
- cape_eeprom1: cape_eeprom1@55 {
- compatible = "atmel,24c256";
- reg = <0x55>;
- #address-cells = <1>;
- #size-cells = <1>;
- cape1_data: cape_data@0 {
- reg = <0 0x100>;
- };
- };
-
- cape_eeprom2: cape_eeprom2@56 {
- compatible = "atmel,24c256";
- reg = <0x56>;
- #address-cells = <1>;
- #size-cells = <1>;
- cape2_data: cape_data@0 {
- reg = <0 0x100>;
- };
- };
-
- cape_eeprom3: cape_eeprom3@57 {
- compatible = "atmel,24c256";
- reg = <0x57>;
- #address-cells = <1>;
- #size-cells = <1>;
- cape3_data: cape_data@0 {
- reg = <0 0x100>;
- };
- };
-};
-
-
-/include/ "tps65217.dtsi"
-
-&tps {
- /*
- * Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
- * mode") at poweroff. Most BeagleBone versions do not support RTC-only
- * mode and risk hardware damage if this mode is entered.
- *
- * For details, see linux-omap mailing list May 2015 thread
- * [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
- * In particular, messages:
- * http://www.spinics.net/lists/linux-omap/msg118585.html
- * http://www.spinics.net/lists/linux-omap/msg118615.html
- *
- * You can override this later with
- * &tps { /delete-property/ ti,pmic-shutdown-controller; }
- * if you want to use RTC-only mode and made sure you are not affected
- * by the hardware problems. (Tip: double-check by performing a current
- * measurement after shutdown: it should be less than 1 mA.)
- */
-
- interrupts = <7>; /* NMI */
- interrupt-parent = <&intc>;
-
- ti,pmic-shutdown-controller;
-
- charger {
- status = "okay";
- };
-
- pwrbutton {
- status = "okay";
- };
-
- regulators {
- dcdc1_reg: regulator@0 {
- regulator-name = "vdds_dpr";
- regulator-always-on;
- };
-
- dcdc2_reg: regulator@1 {
- /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
- regulator-name = "vdd_mpu";
- regulator-min-microvolt = <925000>;
- regulator-max-microvolt = <1351500>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- dcdc3_reg: regulator@2 {
- /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
- regulator-name = "vdd_core";
- regulator-min-microvolt = <925000>;
- regulator-max-microvolt = <1150000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo1_reg: regulator@3 {
- regulator-name = "vio,vrtc,vdds";
- regulator-always-on;
- };
-
- ldo2_reg: regulator@4 {
- regulator-name = "vdd_3v3aux";
- regulator-always-on;
- };
-
- ldo3_reg: regulator@5 {
- regulator-name = "vdd_1v8";
- regulator-always-on;
- };
-
- ldo4_reg: regulator@6 {
- regulator-name = "vdd_3v3a";
- regulator-always-on;
- };
- };
-};
-
-&cpsw_port1 {
- phy-handle = <ðphy0>;
- phy-mode = "mii";
- ti,dual-emac-pvid = <1>;
-};
-
-&cpsw_port2 {
- status = "disabled";
-};
-
-&mac_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&cpsw_default>;
- pinctrl-1 = <&cpsw_sleep>;
- status = "okay";
-};
-
-&davinci_mdio_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&davinci_mdio_default>;
- pinctrl-1 = <&davinci_mdio_sleep>;
-
- ethphy0: ethernet-phy@0 {
- reg = <0>;
- };
-};
-
-&mmc1 {
- status = "okay";
- bus-width = <0x4>;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins>;
- cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
-};
-
-&aes {
- status = "okay";
-};
-
-&sham {
- status = "okay";
-};
-
-&rtc {
- clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
- clock-names = "ext-clk", "int-clk";
- system-power-controller;
-};
-
-&pruss_tm {
- status = "okay";
-};
-
-&wkup_m3_ipc {
- firmware-name = "am335x-bone-scale-data.bin";
-};
diff --git a/arch/arm/boot/dts/am335x-boneblack-hdmi.dtsi b/arch/arm/boot/dts/am335x-boneblack-hdmi.dtsi
deleted file mode 100644
index 486f24d..0000000
--- a/arch/arm/boot/dts/am335x-boneblack-hdmi.dtsi
+++ /dev/null
@@ -1,146 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-#include <dt-bindings/display/tda998x.h>
-#include <dt-bindings/interrupt-controller/irq.h>
-
-&am33xx_pinmux {
- nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR0, PIN_OUTPUT_PULLDOWN, MUX_MODE3)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA0, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA1, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA2, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA3, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA4, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA5, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA6, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA7, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA8, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA9, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA10, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA11, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA12, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA13, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA14, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA15, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_VSYNC, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_HSYNC, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_PCLK, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_AC_BIAS_EN, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- nxp_hdmi_bonelt_off_pins: nxp_hdmi_bonelt_off_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR0, PIN_OUTPUT_PULLDOWN, MUX_MODE3)
- >;
- };
-
- mcasp0_pins: mcasp0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MCASP0_AHCLKX, PIN_INPUT_PULLUP, MUX_MODE0) /* mcasp0_ahcklx.mcasp0_ahclkx */
- AM33XX_PADCONF(AM335X_PIN_MCASP0_AHCLKR, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2*/
- AM33XX_PADCONF(AM335X_PIN_MCASP0_FSX, PIN_OUTPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MCASP0_ACLKX, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A11, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_a11.GPIO1_27 */
- >;
- };
-};
-
-&lcdc {
- status = "okay";
-
- /* If you want to get 24 bit RGB and 16 BGR mode instead of
- * current 16 bit RGB and 24 BGR modes, set the propety
- * below to "crossed" and uncomment the video-ports -property
- * in tda19988 node.
- */
- blue-and-red-wiring = "straight";
-
- port {
- lcdc_0: endpoint@0 {
- remote-endpoint = <&hdmi_0>;
- };
- };
-};
-
-&i2c0 {
- tda19988: tda19988@70 {
- compatible = "nxp,tda998x";
- reg = <0x70>;
- nxp,calib-gpios = <&gpio1 25 0>;
- interrupts-extended = <&gpio1 25 IRQ_TYPE_LEVEL_LOW>;
-
- pinctrl-names = "default", "off";
- pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
- pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
-
- /* Convert 24bit BGR to RGB, e.g. cross red and blue wiring */
- /* video-ports = <0x234501>; */
-
- #sound-dai-cells = <0>;
- audio-ports = < TDA998x_I2S 0x03>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- hdmi_0: endpoint {
- remote-endpoint = <&lcdc_0>;
- };
- };
- };
- };
-};
-
-&mcasp0 {
- #sound-dai-cells = <0>;
- pinctrl-names = "default";
- pinctrl-0 = <&mcasp0_pins>;
- status = "okay";
- op-mode = <0>; /* MCASP_IIS_MODE */
- tdm-slots = <2>;
- serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
- 0 0 1 0
- >;
- tx-num-evt = <32>;
- rx-num-evt = <32>;
-};
-
-/ {
- clk_mcasp0_fixed: clk_mcasp0_fixed {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <24576000>;
- };
-
- clk_mcasp0: clk_mcasp0 {
- #clock-cells = <0>;
- compatible = "gpio-gate-clock";
- clocks = <&clk_mcasp0_fixed>;
- enable-gpios = <&gpio1 27 0>; /* BeagleBone Black Clk enable on GPIO1_27 */
- };
-
- sound {
- compatible = "simple-audio-card";
- simple-audio-card,name = "TI BeagleBone Black";
- simple-audio-card,format = "i2s";
- simple-audio-card,bitclock-master = <&dailink0_master>;
- simple-audio-card,frame-master = <&dailink0_master>;
-
- dailink0_master: simple-audio-card,cpu {
- sound-dai = <&mcasp0>;
- clocks = <&clk_mcasp0>;
- };
-
- simple-audio-card,codec {
- sound-dai = <&tda19988>;
- };
- };
-};
diff --git a/arch/arm/boot/dts/am335x-boneblack-wireless.dts b/arch/arm/boot/dts/am335x-boneblack-wireless.dts
deleted file mode 100644
index 207d2b6..0000000
--- a/arch/arm/boot/dts/am335x-boneblack-wireless.dts
+++ /dev/null
@@ -1,111 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-/dts-v1/;
-
-#include "am33xx.dtsi"
-#include "am335x-bone-common.dtsi"
-#include "am335x-boneblack-common.dtsi"
-#include "am335x-boneblack-hdmi.dtsi"
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "TI AM335x BeagleBone Black Wireless";
- compatible = "ti,am335x-bone-black-wireless", "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
-
- wlan_en_reg: fixedregulator@2 {
- compatible = "regulator-fixed";
- regulator-name = "wlan-en-regulator";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- startup-delay-us = <70000>;
-
- /* WL_EN */
- gpio = <&gpio3 9 0>;
- enable-active-high;
- };
-};
-
-&am33xx_pinmux {
- bt_pins: pinmux_bt_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLUP, MUX_MODE7) /* gmii1_txd0.gpio0_28 - BT_EN */
- >;
- };
-
- mmc3_pins: pinmux_mmc3_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLUP, MUX_MODE6 ) /* (L15) gmii1_rxd1.mmc2_clk */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_INPUT_PULLUP, MUX_MODE6 ) /* (J16) gmii1_txen.mmc2_cmd */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLUP, MUX_MODE5 ) /* (J17) gmii1_rxdv.mmc2_dat0 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_INPUT_PULLUP, MUX_MODE5 ) /* (J18) gmii1_txd3.mmc2_dat1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_INPUT_PULLUP, MUX_MODE5 ) /* (K15) gmii1_txd2.mmc2_dat2 */
- AM33XX_PADCONF(AM335X_PIN_MII1_COL, PIN_INPUT_PULLUP, MUX_MODE5 ) /* (H16) gmii1_col.mmc2_dat3 */
- >;
- };
-
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLUP, MUX_MODE1) /* gmii1_rxd3.uart3_rxd */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE1) /* gmii1_rxd2.uart3_txd */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT, MUX_MODE3) /* mdio_data.uart3_ctsn */
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLDOWN, MUX_MODE3) /* mdio_clk.uart3_rtsn */
- >;
- };
-
- wl18xx_pins: pinmux_wl18xx_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gmii1_txclk.gpio3_9 WL_EN */
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7) /* rmii1_refclk.gpio0_29 WL_IRQ */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_OUTPUT_PULLUP, MUX_MODE7) /* gmii1_rxclk.gpio3_10 LS_BUF_EN */
- >;
- };
-};
-
-&mac_sw {
- status = "disabled";
-};
-
-&mmc3 {
- dmas = <&edma_xbar 12 0 1
- &edma_xbar 13 0 2>;
- dma-names = "tx", "rx";
- status = "okay";
- vmmc-supply = <&wlan_en_reg>;
- bus-width = <4>;
- non-removable;
- cap-power-off-card;
- keep-power-in-suspend;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc3_pins &wl18xx_pins>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- wlcore: wlcore@2 {
- compatible = "ti,wl1835";
- reg = <2>;
- interrupt-parent = <&gpio0>;
- interrupts = <29 IRQ_TYPE_EDGE_RISING>;
- };
-};
-
-&uart3 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart3_pins &bt_pins>;
- status = "okay";
-
- bluetooth {
- compatible = "ti,wl1835-st";
- enable-gpios = <&gpio0 28 GPIO_ACTIVE_HIGH>;
- };
-};
-
-&gpio3 {
- ls-buf-en-hog {
- gpio-hog;
- gpios = <10 GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "LS_BUF_EN";
- };
-};
diff --git a/arch/arm/boot/dts/am335x-boneblue.dts b/arch/arm/boot/dts/am335x-boneblue.dts
deleted file mode 100644
index 34579e9..0000000
--- a/arch/arm/boot/dts/am335x-boneblue.dts
+++ /dev/null
@@ -1,616 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-/dts-v1/;
-
-#include "am33xx.dtsi"
-#include "am335x-osd335x-common.dtsi"
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "TI AM335x BeagleBone Blue";
- compatible = "ti,am335x-bone-blue", "ti,am33xx";
-
- chosen {
- stdout-path = &uart0;
- };
-
- leds {
- pinctrl-names = "default";
- pinctrl-0 = <&user_leds_s0>;
-
- compatible = "gpio-leds";
-
- usr_0_led {
- label = "beaglebone:green:usr0";
- gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- default-state = "off";
- };
-
- usr_1_led {
- label = "beaglebone:green:usr1";
- gpios = <&gpio1 22 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "mmc0";
- default-state = "off";
- };
-
- usr_2_led {
- label = "beaglebone:green:usr2";
- gpios = <&gpio1 23 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "cpu0";
- default-state = "off";
- };
-
- usr_3_led {
- label = "beaglebone:green:usr3";
- gpios = <&gpio1 24 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "mmc1";
- default-state = "off";
- };
-
- wifi_led {
- label = "wifi";
- gpios = <&gpio0 19 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- linux,default-trigger = "phy0assoc";
- };
-
- red_led {
- label = "red";
- gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
-
- green_led {
- label = "green";
- gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
-
- batt_1_led {
- label = "bat25";
- gpios = <&gpio0 27 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
-
- batt_2_led {
- label = "bat50";
- gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
-
- batt_3_led {
- label = "bat75";
- gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
-
- batt_4_led {
- label = "bat100";
- gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
- };
-
- vmmcsd_fixed: fixedregulator0 {
- compatible = "regulator-fixed";
- regulator-name = "vmmcsd_fixed";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- wlan_en_reg: fixedregulator@2 {
- compatible = "regulator-fixed";
- regulator-name = "wlan-en-regulator";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- startup-delay-us = <70000>;
-
- /* WL_EN */
- gpio = <&gpio3 9 0>;
- enable-active-high;
- };
-};
-
-&am33xx_pinmux {
- user_leds_s0: user_leds_s0 {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_OUTPUT, MUX_MODE7) /* (V15) gpmc_a5.gpio1[21] - USR_LED_0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A6, PIN_OUTPUT, MUX_MODE7) /* (U15) gpmc_a6.gpio1[22] - USR_LED_1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A7, PIN_OUTPUT, MUX_MODE7) /* (T15) gpmc_a7.gpio1[23] - USR_LED_2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A8, PIN_OUTPUT, MUX_MODE7) /* (V16) gpmc_a8.gpio1[24] - USR_LED_3 */
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR0, PIN_OUTPUT, MUX_MODE7) /* (A15) xdma_event_intr0.gpio0[19] - WIFI_LED */
- AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_OUTPUT, MUX_MODE7) /* (R7) gpmc_advn_ale.gpio2[2] - P8.7, LED_RED, GP1_PIN_5 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_OEN_REN, PIN_OUTPUT, MUX_MODE7) /* (T7) gpmc_oen_ren.gpio2[3] - P8.8, LED_GREEN, GP1_PIN_6 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD11, PIN_OUTPUT, MUX_MODE7) /* (U12) gpmc_ad11.gpio0[27] - P8.17, BATT_LED_1 */
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA15, PIN_OUTPUT, MUX_MODE7) /* (T5) lcd_data15.gpio0[11] - P8.32, BATT_LED_2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT, MUX_MODE7) /* (V6) gpmc_csn0.gpio1[29] - P8.26, BATT_LED_3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD10, PIN_OUTPUT, MUX_MODE7) /* (T11) gpmc_ad10.gpio0[26] - P8.14, BATT_LED_4 */
-
- >;
- };
-
- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART1_CTSN, PIN_INPUT_PULLUP, MUX_MODE3) /* (D18) uart1_ctsn.I2C2_SDA */
- AM33XX_PADCONF(AM335X_PIN_UART1_RTSN, PIN_INPUT_PULLUP, MUX_MODE3) /* (D17) uart1_rtsn.I2C2_SCL */
- >;
- };
-
- /* UT0 */
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- /* UT1 */
- uart1_pins: pinmux_uart1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART1_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- /* GPS */
- uart2_pins: pinmux_uart2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT_PULLUP, MUX_MODE1) /* (A17) spi0_sclk.uart2_rxd */
- AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_OUTPUT_PULLDOWN, MUX_MODE1) /* (B17) spi0_d0.uart2_txd */
- >;
- };
-
- /* DSM2 */
- uart4_pins: pinmux_uart4_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE6) /* (T17) gpmc_wait0.uart4_rxd */
- >;
- };
-
- /* UT5 */
- uart5_pins: pinmux_uart5_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA9, PIN_INPUT_PULLUP, MUX_MODE4) /* (U2) lcd_data9.uart5_rxd */
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA8, PIN_OUTPUT_PULLDOWN, MUX_MODE4) /* (U1) lcd_data8.uart5_txd */
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_CS1, PIN_INPUT, MUX_MODE7) /* (C15) spi0_cs1.gpio0[6] */
- >;
- };
-
- mmc2_pins: pinmux_mmc2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN1, PIN_INPUT_PULLUP, MUX_MODE2) /* (U9) gpmc_csn1.mmc1_clk */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN2, PIN_INPUT_PULLUP, MUX_MODE2) /* (V9) gpmc_csn2.mmc1_cmd */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD0, PIN_INPUT_PULLUP, MUX_MODE1) /* (U7) gpmc_ad0.mmc1_dat0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD1, PIN_INPUT_PULLUP, MUX_MODE1) /* (V7) gpmc_ad1.mmc1_dat1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD2, PIN_INPUT_PULLUP, MUX_MODE1) /* (R8) gpmc_ad2.mmc1_dat2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD3, PIN_INPUT_PULLUP, MUX_MODE1) /* (T8) gpmc_ad3.mmc1_dat3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD4, PIN_INPUT_PULLUP, MUX_MODE1) /* (U8) gpmc_ad4.mmc1_dat4 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE1) /* (V8) gpmc_ad5.mmc1_dat5 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLUP, MUX_MODE1) /* (R9) gpmc_ad6.mmc1_dat6 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLUP, MUX_MODE1) /* (T9) gpmc_ad7.mmc1_dat7 */
- >;
- };
-
- mmc3_pins: pinmux_mmc3_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLUP, MUX_MODE6) /* (L15) gmii1_rxd1.mmc2_clk */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_INPUT_PULLUP, MUX_MODE6) /* (J16) gmii1_txen.mmc2_cmd */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLUP, MUX_MODE5) /* (J17) gmii1_rxdv.mmc2_dat0 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_INPUT_PULLUP, MUX_MODE5) /* (J18) gmii1_txd3.mmc2_dat1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_INPUT_PULLUP, MUX_MODE5) /* (K15) gmii1_txd2.mmc2_dat2 */
- AM33XX_PADCONF(AM335X_PIN_MII1_COL, PIN_INPUT_PULLUP, MUX_MODE5) /* (H16) gmii1_col.mmc2_dat3 */
- >;
- };
-
- bt_pins: pinmux_bt_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLUP, MUX_MODE7) /* (K17) gmii1_txd0.gpio0[28] - BT_EN */
- >;
- };
-
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLUP, MUX_MODE1) /* (L17) gmii1_rxd3.uart3_rxd */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE1) /* (L16) gmii1_rxd2.uart3_txd */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT, MUX_MODE3) /* (M17) mdio_data.uart3_ctsn */
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLDOWN, MUX_MODE3) /* (M18) mdio_clk.uart3_rtsn */
- >;
- };
-
- wl18xx_pins: pinmux_wl18xx_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* (K18) gmii1_txclk.gpio3[9] - WL_EN */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_INPUT_PULLDOWN, MUX_MODE7) /* (K16) gmii1_txd1.gpio0[21] - WL_IRQ */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_OUTPUT_PULLUP, MUX_MODE7) /* (L18) gmii1_rxclk.gpio3[10] - LS_BUF_EN */
- >;
- };
-
- /* DCAN */
- dcan1_pins: pinmux_dcan1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_RTSN, PIN_INPUT, MUX_MODE2) /* (E17) uart0_rtsn.dcan1_rx */
- AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_OUTPUT, MUX_MODE2) /* (E18) uart0_ctsn.dcan1_tx */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_OUTPUT, MUX_MODE7) /* (M16) gmii1_rxd0.gpio2[21] */
- >;
- };
-
- /* E1 */
- eqep0_pins: pinmux_eqep0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MCASP0_AXR0, PIN_INPUT, MUX_MODE1) /* (B12) mcasp0_aclkr.eQEP0A_in */
- AM33XX_PADCONF(AM335X_PIN_MCASP0_FSR, PIN_INPUT, MUX_MODE1) /* (C13) mcasp0_fsr.eQEP0B_in */
- >;
- };
-
- /* E2 */
- eqep1_pins: pinmux_eqep1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA12, PIN_INPUT, MUX_MODE2) /* (V2) lcd_data12.eQEP1A_in */
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA13, PIN_INPUT, MUX_MODE2) /* (V3) lcd_data13.eQEP1B_in */
- >;
- };
-
- /* E3 */
- eqep2_pins: pinmux_eqep2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_INPUT, MUX_MODE4) /* (T12) gpmc_ad12.eQEP2A_in */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_INPUT, MUX_MODE4) /* (R12) gpmc_ad13.eQEP2B_in */
- >;
- };
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-
- status = "okay";
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins>;
-
- status = "okay";
-};
-
-&uart2 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart2_pins>;
-
- status = "okay";
-};
-
-&uart4 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart4_pins>;
-
- status = "okay";
-};
-
-&uart5 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart5_pins>;
-
- status = "okay";
-};
-
-&usb0 {
- dr_mode = "peripheral";
- interrupts-extended = <&intc 18 &tps 0>;
- interrupt-names = "mc", "vbus";
-};
-
-&usb1 {
- dr_mode = "host";
-};
-
-&i2c0 {
- baseboard_eeprom: baseboard_eeprom@50 {
- compatible = "atmel,24c256";
- reg = <0x50>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- baseboard_data: baseboard_data@0 {
- reg = <0 0x100>;
- };
- };
-};
-
-&i2c2 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c2_pins>;
-
- status = "okay";
- clock-frequency = <400000>;
-
- mpu9250@68 {
- compatible = "invensense,mpu9250";
- reg = <0x68>;
- interrupt-parent = <&gpio3>;
- interrupts = <21 IRQ_TYPE_EDGE_RISING>;
- i2c-gate {
- #address-cells = <1>;
- #size-cells = <0>;
- ax8975@c {
- compatible = "asahi-kasei,ak8975";
- reg = <0x0c>;
- };
- };
- };
-
- pressure@76 {
- compatible = "bosch,bmp280";
- reg = <0x76>;
- };
-};
-
-/include/ "tps65217.dtsi"
-
-&tps {
- /delete-property/ ti,pmic-shutdown-controller;
-
- charger {
- interrupts = <0>, <1>;
- interrupt-names = "USB", "AC";
- status = "okay";
- };
-};
-
-&mmc1 {
- status = "okay";
- vmmc-supply = <&vmmcsd_fixed>;
- bus-width = <4>;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins>;
- cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
-};
-
-&mmc2 {
- status = "okay";
- vmmc-supply = <&vmmcsd_fixed>;
- bus-width = <8>;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc2_pins>;
-};
-
-&mmc3 {
- dmas = <&edma_xbar 12 0 1
- &edma_xbar 13 0 2>;
- dma-names = "tx", "rx";
- status = "okay";
- vmmc-supply = <&wlan_en_reg>;
- bus-width = <4>;
- non-removable;
- cap-power-off-card;
- keep-power-in-suspend;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc3_pins &wl18xx_pins>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- wlcore: wlcore@2 {
- compatible = "ti,wl1835";
- reg = <2>;
- interrupt-parent = <&gpio0>;
- interrupts = <21 IRQ_TYPE_EDGE_RISING>;
- };
-};
-
-&tscadc {
- status = "okay";
- adc {
- ti,adc-channels = <0 1 2 3 4 5 6 7>;
- };
-};
-
-&uart3 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart3_pins &bt_pins>;
- status = "okay";
-
- bluetooth {
- compatible = "ti,wl1835-st";
- enable-gpios = <&gpio0 28 GPIO_ACTIVE_HIGH>;
- };
-};
-
-&rtc {
- system-power-controller;
- clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
- clock-names = "ext-clk", "int-clk";
-};
-
-&dcan1 {
- pinctrl-names = "default";
- pinctrl-0 = <&dcan1_pins>;
- status = "okay";
-};
-
-&gpio0 {
- gpio-line-names =
- "UART3_CTS", /* M17 */
- "UART3_RTS", /* M18 */
- "UART2_RX", /* A17 */
- "UART2_TX", /* B17 */
- "I2C1_SDA", /* B16 */
- "I2C1_SCL", /* A16 */
- "MMC0_CD", /* C15 */
- "SPI1_SS2", /* C18 */
- "EQEP_1A", /* V2 */
- "EQEP_1B", /* V3 */
- "MDIR_2B", /* V4 */
- "BATT_LED_2", /* T5 */
- "I2C2_SDA", /* D18 */
- "I2C2_SCL", /* D17 */
- "UART1_RX", /* D16 */
- "UART1_TX", /* D15 */
- "MMC2_DAT1", /* J18 */
- "MMC2_DAT2", /* K15 */
- "NC", /* F16 */
- "WIFI_LED", /* A15 */
- "MOT_STBY", /* D14 */
- "WLAN_IRQ", /* K16 */
- "PWM_2A", /* U10 */
- "PWM_2B", /* T10 */
- "",
- "",
- "BATT_LED_4", /* T11 */
- "BATT_LED_1", /* U12 */
- "BT_EN", /* K17 */
- "SPI1_SS1", /* H18 */
- "UART4_RX", /* T17 */
- "MDIR_1B"; /* U17 */
-};
-
-&gpio1 {
- gpio-line-names =
- "MMC1_DAT0", /* U7 */
- "MMC1_DAT1", /* V7 */
- "MMC1_DAT2", /* R8 */
- "MMC1_DAT3", /* T8 */
- "MMC1_DAT4", /* U8 */
- "MMC1_DAT5", /* V8 */
- "MMC1_DAT6", /* R9 */
- "MMC1_DAT7", /* T9 */
- "DCAN1_TX", /* E18 */
- "DCAN1_RX", /* E17 */
- "UART0_RX", /* E15 */
- "UART0_TX", /* E16 */
- "EQEP_2A", /* T12 */
- "EQEP_2B", /* R12 */
- "PRU_E_A", /* V13 */
- "PRU_E_B", /* U13 */
- "MDIR_2A", /* R13 */
- "GPIO1_17", /* V14 */
- "PWM_1A", /* U14 */
- "PWM_1B", /* T14 */
- "EMMC_RST", /* R14 */
- "USR_LED_0", /* V15 */
- "USR_LED_1", /* U15 */
- "USR_LED_2", /* T15 */
- "USR_LED_3", /* V16 */
- "GPIO1_25", /* U16 */
- "MCASP0_AXR0", /* T16 */
- "MCASP0_AXR1", /* V17 */
- "MCASP0_ACLKR", /* U18 */
- "BATT_LED_3", /* V6 */
- "MMC1_CLK", /* U9 */
- "MMC1_CMD"; /* V9 */
-};
-
-&gpio2 {
- gpio-line-names =
- "MDIR_1A", /* T13 */
- "MCASP0_FSR", /* V12 */
- "LED_RED", /* R7 */
- "LED_GREEN", /* T7 */
- "MODE_BTN", /* U6 */
- "PAUSE_BTN", /* T6 */
- "MDIR_4A", /* R1 */
- "MDIR_4B", /* R2 */
- "MDIR_3B", /* R3 */
- "MDIR_3A", /* R4 */
- "SVO7", /* T1 */
- "SVO8", /* T2 */
- "SVO5", /* T3 */
- "SVO6", /* T4 */
- "UART5_TX", /* U1 */
- "UART5_RX", /* U2 */
- "SERVO_EN", /* U3 */
- "NC", /* U4 */
- "UART3_RX", /* L17 */
- "UART3_TX", /* L16 */
- "MMC2_CLK", /* L15 */
- "DCAN1_SILENT", /* M16 */
- "SVO1", /* U5 */
- "SVO3", /* R5 */
- "SVO2", /* V5 */
- "SVO4", /* R6 */
- "MMC0_DAT3", /* F17 */
- "MMC0_DAT2", /* F18 */
- "MMC0_DAT1", /* G15 */
- "MMC0_DAT0", /* G16 */
- "MMC0_CLK", /* G17 */
- "MMC0_CMD"; /* G18 */
-};
-
-&gpio3 {
- gpio-line-names =
- "MMC2_DAT3", /* H16 */
- "GPIO3_1", /* H17 */
- "GPIO3_2", /* J15 */
- "MMC2_CMD", /* J16 */
- "MMC2_DAT0", /* J17 */
- "I2C0_SDA", /* C17 */
- "I2C0_SCL", /* C16 */
- "EMU1", /* C14 */
- "EMU0", /* B14 */
- "WL_EN", /* K18 */
- "WL_BT_OE", /* L18 */
- "",
- "",
- "NC", /* F15 */
- "SPI1_SCK", /* A13 */
- "SPI1_MISO", /* B13 */
- "SPI1_MOSI", /* D12 */
- "GPIO3_17", /* C12 */
- "EQEP_0A", /* B12 */
- "EQEP_0B", /* C13 */
- "GPIO3_20", /* D13 */
- "IMU_INT", /* A14 */
- "",
- "",
- "",
- "",
- "",
- "",
- "",
- "",
- "",
- "";
-
- ls-buf-en-hog {
- gpio-hog;
- gpios = <10 GPIO_ACTIVE_HIGH>;
- output-high;
- };
-};
-
-&epwmss0 {
- status = "okay";
-};
-
-&eqep0 {
- pinctrl-names = "default";
- pinctrl-0 = <&eqep0_pins>;
- status = "okay";
-};
-
-&epwmss1 {
- status = "okay";
-};
-
-&eqep1 {
- pinctrl-names = "default";
- pinctrl-0 = <&eqep1_pins>;
- status = "okay";
-};
-
-&epwmss2 {
- status = "okay";
-};
-
-&eqep2 {
- pinctrl-names = "default";
- pinctrl-0 = <&eqep2_pins>;
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/am335x-bonegreen-common.dtsi b/arch/arm/boot/dts/am335x-bonegreen-common.dtsi
deleted file mode 100644
index 9f7fb63..0000000
--- a/arch/arm/boot/dts/am335x-bonegreen-common.dtsi
+++ /dev/null
@@ -1,41 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-&ldo3_reg {
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
-};
-
-&mmc1 {
- vmmc-supply = <&vmmcsd_fixed>;
-};
-
-&mmc2 {
- vmmc-supply = <&vmmcsd_fixed>;
- pinctrl-names = "default";
- pinctrl-0 = <&emmc_pins>;
- bus-width = <8>;
- status = "okay";
-};
-
-&am33xx_pinmux {
- uart2_pins: uart2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT, MUX_MODE1) /* spi0_sclk.uart2_rxd */
- AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_OUTPUT, MUX_MODE1) /* spi0_d0.uart2_txd */
- >;
- };
-};
-
-&uart2 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart2_pins>;
- status = "okay";
-};
-
-&rtc {
- system-power-controller;
-};
diff --git a/arch/arm/boot/dts/am335x-bonegreen-wireless.dts b/arch/arm/boot/dts/am335x-bonegreen-wireless.dts
deleted file mode 100644
index d388cff..0000000
--- a/arch/arm/boot/dts/am335x-bonegreen-wireless.dts
+++ /dev/null
@@ -1,127 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-/dts-v1/;
-
-#include "am33xx.dtsi"
-#include "am335x-bone-common.dtsi"
-#include "am335x-bonegreen-common.dtsi"
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "TI AM335x BeagleBone Green Wireless";
- compatible = "ti,am335x-bone-green-wireless", "ti,am335x-bone-green", "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
-
- wlan_en_reg: fixedregulator@2 {
- compatible = "regulator-fixed";
- regulator-name = "wlan-en-regulator";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- startup-delay-us = <70000>;
-
- /* WL_EN */
- gpio = <&gpio0 26 0>;
- enable-active-high;
- };
-};
-
-&am33xx_pinmux {
- bt_pins: pinmux_bt_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_BEN1, PIN_OUTPUT_PULLUP, MUX_MODE7) /* gpmc_ad12.gpio1_28 BT_EN */
- >;
- };
-
- mmc3_pins: pinmux_mmc3_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_ad12.mmc2_dat0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_ad13.mmc2_dat1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD14, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_ad14.mmc2_dat2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD15, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_ad15.mmc2_dat3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN3, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_csn3.mmc2_cmd */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CLK, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_clk.mmc2_clk */
- >;
- };
-
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLUP, MUX_MODE1) /* gmii1_rxd3.uart3_rxd */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE1) /* gmii1_rxd2.uart3_txd */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT, MUX_MODE3) /* mdio_data.uart3_ctsn */
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLDOWN, MUX_MODE3) /* mdio_clk.uart3_rtsn */
- >;
- };
-
- wl18xx_pins: pinmux_wl18xx_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD10, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad10.gpio0_26 WL_EN */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD11, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad11.gpio0_27 WL_IRQ */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT_PULLUP, MUX_MODE7) /* gpmc_csn0.gpio1_29 LS_BUF_EN */
- >;
- };
-};
-
-&mac_sw {
- status = "disabled";
-};
-
-&mmc3 {
- dmas = <&edma_xbar 12 0 1
- &edma_xbar 13 0 2>;
- dma-names = "tx", "rx";
- status = "okay";
- vmmc-supply = <&wlan_en_reg>;
- bus-width = <4>;
- non-removable;
- cap-power-off-card;
- keep-power-in-suspend;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc3_pins &wl18xx_pins>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- wlcore: wlcore@2 {
- compatible = "ti,wl1835";
- reg = <2>;
- interrupt-parent = <&gpio0>;
- interrupts = <27 IRQ_TYPE_EDGE_RISING>;
- };
-};
-
-&uart3 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart3_pins &bt_pins>;
- status = "okay";
-
- bluetooth {
- compatible = "ti,wl1835-st";
- enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
- };
-};
-
-&gpio1 {
- ls-buf-en-hog {
- gpio-hog;
- gpios = <29 GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "LS_BUF_EN";
- };
-};
-
-/* BT_AUD_OUT from wl1835 has to be pulled low when WL_EN is activated.*/
-/* in case it isn't, wilink8 ends up in one of the test modes that */
-/* intruces various issues (elp wkaeup timeouts etc.) */
-/* On the BBGW this pin is routed through the level shifter (U21) that */
-/* introduces a pullup on the line and wilink8 ends up in a bad state. */
-/* use a gpio hog to force this pin low. An alternative may be adding */
-/* an external pulldown on U21 pin 4. */
-
-&gpio3 {
- bt-aud-in-hog {
- gpio-hog;
- gpios = <16 GPIO_ACTIVE_HIGH>;
- output-low;
- line-name = "MCASP0_AHCLKR";
- };
-};
diff --git a/arch/arm/boot/dts/am335x-chiliboard.dts b/arch/arm/boot/dts/am335x-chiliboard.dts
deleted file mode 100644
index a223cdd..0000000
--- a/arch/arm/boot/dts/am335x-chiliboard.dts
+++ /dev/null
@@ -1,186 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2015 Jablotron s.r.o. -- https://www.jablotron.com/
- * Author: Rostislav Lisovy <lisovy@jablotron.cz>
- */
-/dts-v1/;
-#include "am335x-chilisom.dtsi"
-
-/ {
- model = "AM335x Chiliboard";
- compatible = "grinn,am335x-chiliboard", "grinn,am335x-chilisom",
- "ti,am33xx";
-
- chosen {
- stdout-path = &uart0;
- };
-
- leds {
- compatible = "gpio-leds";
- pinctrl-names = "default";
- pinctrl-0 = <&led_gpio_pins>;
-
- led0 {
- label = "led0";
- gpios = <&gpio3 7 GPIO_ACTIVE_LOW>;
- default-state = "keep";
- linux,default-trigger = "heartbeat";
- };
-
- led1 {
- label = "led1";
- gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
- default-state = "keep";
- };
- };
-};
-
-&am33xx_pinmux {
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins = <
- /* Slave 1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_CRS, PIN_INPUT_PULLDOWN, MUX_MODE1)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_INPUT_PULLUP, MUX_MODE1)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_OUTPUT_PULLDOWN, MUX_MODE1)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_OUTPUT_PULLDOWN, MUX_MODE1)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLDOWN, MUX_MODE1)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLUP, MUX_MODE1)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLUP, MUX_MODE1)
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins = <
- /* Slave 1 reset value */
- AM33XX_PADCONF(AM335X_PIN_MII1_CRS, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- davinci_mdio_default: davinci_mdio_default {
- pinctrl-single,pins = <
- /* mdio_data.mdio_data */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLUP | SLEWCTRL_FAST, MUX_MODE0)
- /* mdio_clk.mdio_clk */
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- davinci_mdio_sleep: davinci_mdio_sleep {
- pinctrl-single,pins = <
- /* MDIO reset value */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- usb1_drvvbus: usb1_drvvbus {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_USB1_DRVVBUS, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- sd_pins: pinmux_sd_card {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT3, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT2, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT1, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT0, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CLK, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CMD, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_SPI0_CS1, PIN_INPUT, MUX_MODE7) /* spi0_cs1.gpio0_6 */
- >;
- };
-
- led_gpio_pins: led_gpio_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_EMU0, PIN_OUTPUT, MUX_MODE7) /* emu0.gpio3_7 */
- AM33XX_PADCONF(AM335X_PIN_EMU1, PIN_OUTPUT, MUX_MODE7) /* emu1.gpio3_8 */
- >;
- };
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-
- status = "okay";
-};
-
-&ldo4_reg {
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-};
-
-/* Ethernet */
-&mac_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&cpsw_default>;
- pinctrl-1 = <&cpsw_sleep>;
- status = "okay";
-};
-
-&davinci_mdio_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&davinci_mdio_default>;
- pinctrl-1 = <&davinci_mdio_sleep>;
-
- ethphy0: ethernet-phy@0 {
- reg = <0>;
- };
-};
-
-&cpsw_port1 {
- phy-handle = <ðphy0>;
- phy-mode = "rmii";
- ti,dual-emac-pvid = <1>;
-};
-
-&cpsw_port2 {
- status = "disabled";
-};
-
-/* USB */
-&usb1 {
- pinctrl-names = "default";
- pinctrl-0 = <&usb1_drvvbus>;
- dr_mode = "host";
-};
-
-/* microSD */
-&mmc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&sd_pins>;
- vmmc-supply = <&ldo4_reg>;
- bus-width = <0x4>;
- cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
- status = "okay";
-};
-
-&tps {
- interrupt-parent = <&intc>;
- interrupts = <7>; /* NNMI */
-
- charger {
- status = "okay";
- };
-
- pwrbutton {
- status = "okay";
- };
-};
diff --git a/arch/arm/boot/dts/am335x-chilisom.dtsi b/arch/arm/boot/dts/am335x-chilisom.dtsi
deleted file mode 100644
index 43b61e4..0000000
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ /dev/null
@@ -1,175 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2015 Jablotron s.r.o. -- https://www.jablotron.com/
- * Author: Rostislav Lisovy <lisovy@jablotron.cz>
- */
-#include "am33xx.dtsi"
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "Grinn AM335x ChiliSOM";
- compatible = "grinn,am335x-chilisom", "ti,am33xx";
-
- cpus {
- cpu@0 {
- cpu0-supply = <&dcdc2_reg>;
- };
- };
-
- memory@80000000 {
- device_type = "memory";
- reg = <0x80000000 0x20000000>; /* 512 MB */
- };
-};
-
-&am33xx_pinmux {
- pinctrl-names = "default";
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_I2C0_SCL, PIN_INPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- nandflash_pins: nandflash_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD0, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD1, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD2, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD3, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD4, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLDOWN, MUX_MODE0)
-
- AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_OUTPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_OEN_REN, PIN_OUTPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_WEN, PIN_OUTPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_BEN0_CLE, PIN_OUTPUT_PULLUP, MUX_MODE0)
- >;
- };
-};
-
-&i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
-
- status = "okay";
- clock-frequency = <400000>;
-
- tps: tps@24 {
- reg = <0x24>;
- };
-
-};
-
-/include/ "tps65217.dtsi"
-
-&tps {
- regulators {
- dcdc1_reg: regulator@0 {
- regulator-name = "vdds_dpr";
- regulator-always-on;
- };
-
- dcdc2_reg: regulator@1 {
- /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
- regulator-name = "vdd_mpu";
- regulator-min-microvolt = <925000>;
- regulator-max-microvolt = <1325000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- dcdc3_reg: regulator@2 {
- /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
- regulator-name = "vdd_core";
- regulator-min-microvolt = <925000>;
- regulator-max-microvolt = <1150000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo1_reg: regulator@3 {
- regulator-name = "vio,vrtc,vdds";
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo2_reg: regulator@4 {
- regulator-name = "vdd_3v3aux";
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo3_reg: regulator@5 {
- regulator-name = "vdd_1v8";
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo4_reg: regulator@6 {
- regulator-name = "vdd_3v3d";
- regulator-boot-on;
- regulator-always-on;
- };
- };
-};
-
-&rtc {
- system-power-controller;
-
- pinctrl-0 = <&ext_wakeup>;
- pinctrl-names = "default";
-
- ext_wakeup: ext-wakeup {
- pins = "ext_wakeup0";
- input-enable;
- };
-};
-
-/* NAND Flash */
-&elm {
- status = "okay";
-};
-
-&gpmc {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&nandflash_pins>;
- ranges = <0 0 0x08000000 0x01000000>; /* CS0 0 @addr 0x08000000, size 0x01000000 */
- nand@0,0 {
- compatible = "ti,omap2-nand";
- reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
- interrupt-parent = <&gpmc>;
- interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
- <1 IRQ_TYPE_NONE>; /* termcount */
- rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
- ti,nand-ecc-opt = "bch8";
- ti,elm-id = <&elm>;
- nand-bus-width = <8>;
- gpmc,device-width = <1>;
- gpmc,sync-clk-ps = <0>;
- gpmc,cs-on-ns = <0>;
- gpmc,cs-rd-off-ns = <44>;
- gpmc,cs-wr-off-ns = <44>;
- gpmc,adv-on-ns = <6>;
- gpmc,adv-rd-off-ns = <34>;
- gpmc,adv-wr-off-ns = <44>;
- gpmc,we-on-ns = <0>;
- gpmc,we-off-ns = <40>;
- gpmc,oe-on-ns = <0>;
- gpmc,oe-off-ns = <54>;
- gpmc,access-ns = <64>;
- gpmc,rd-cycle-ns = <82>;
- gpmc,wr-cycle-ns = <82>;
- gpmc,bus-turnaround-ns = <0>;
- gpmc,cycle2cycle-delay-ns = <0>;
- gpmc,clk-activation-ns = <0>;
- gpmc,wr-access-ns = <40>;
- gpmc,wr-data-mux-bus-ns = <0>;
- };
-};
diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts b/arch/arm/boot/dts/am335x-cm-t335.dts
deleted file mode 100644
index 993b134..0000000
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ /dev/null
@@ -1,516 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * am335x-cm-t335.dts - Device Tree file for Compulab CM-T335
- *
- * Copyright (C) 2014 - 2015 CompuLab Ltd. - http://www.compulab.co.il/
- */
-
-/dts-v1/;
-
-#include "am33xx.dtsi"
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "CompuLab CM-T335";
- compatible = "compulab,cm-t335", "ti,am33xx";
-
- memory@80000000 {
- device_type = "memory";
- reg = <0x80000000 0x8000000>; /* 128 MB */
- };
-
- leds {
- compatible = "gpio-leds";
- pinctrl-names = "default";
- pinctrl-0 = <&gpio_led_pins>;
- led0 {
- label = "cm_t335:green";
- gpios = <&gpio2 0 GPIO_ACTIVE_LOW>; /* gpio2_0 */
- linux,default-trigger = "heartbeat";
- };
- };
-
- /* regulator for mmc */
- vmmc_fixed: fixedregulator0 {
- compatible = "regulator-fixed";
- regulator-name = "vmmc_fixed";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- /* Regulator for WiFi */
- vwlan_fixed: fixedregulator2 {
- compatible = "regulator-fixed";
- regulator-name = "vwlan_fixed";
- gpio = <&gpio0 20 GPIO_ACTIVE_HIGH>; /* gpio0_20 */
- enable-active-high;
- };
-
- backlight {
- compatible = "pwm-backlight";
- pwms = <&ecap0 0 50000 0>;
- brightness-levels = <0 51 53 56 62 75 101 152 255>;
- default-brightness-level = <8>;
- };
-
- sound {
- compatible = "simple-audio-card";
- simple-audio-card,name = "cm-t335";
-
- simple-audio-card,widgets =
- "Microphone", "Mic Jack",
- "Line", "Line In",
- "Headphone", "Headphone Jack";
-
- simple-audio-card,routing =
- "Headphone Jack", "LHPOUT",
- "Headphone Jack", "RHPOUT",
- "LLINEIN", "Line In",
- "RLINEIN", "Line In",
- "MICIN", "Mic Jack";
-
- simple-audio-card,format = "i2s";
- simple-audio-card,bitclock-master = <&sound_master>;
- simple-audio-card,frame-master = <&sound_master>;
-
- simple-audio-card,cpu {
- sound-dai = <&mcasp1>;
- };
-
- sound_master: simple-audio-card,codec {
- sound-dai = <&tlv320aic23>;
- system-clock-frequency = <12000000>;
- };
- };
-};
-
-&am33xx_pinmux {
- pinctrl-names = "default";
- pinctrl-0 = <&bluetooth_pins>;
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_I2C0_SCL, PIN_INPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- i2c1_pins: pinmux_i2c1_pins {
- pinctrl-single,pins = <
- /* uart0_ctsn.i2c1_sda */
- AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_INPUT_PULLUP, MUX_MODE2)
- /* uart0_rtsn.i2c1_scl */
- AM33XX_PADCONF(AM335X_PIN_UART0_RTSN, PIN_INPUT_PULLUP, MUX_MODE2)
- >;
- };
-
- gpio_led_pins: pinmux_gpio_led_pins {
- pinctrl-single,pins = <
- /* gpmc_csn3.gpio2_0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN3, PIN_OUTPUT, MUX_MODE7)
- >;
- };
-
- nandflash_pins: pinmux_nandflash_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD1, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD2, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD3, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD4, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE0)
- /* gpmc_wpn.gpio0_31 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_OEN_REN, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_WEN, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_BEN0_CLE, PIN_OUTPUT, MUX_MODE0)
- >;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- uart1_pins: pinmux_uart1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART1_CTSN, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_RTSN, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- dcan0_pins: pinmux_dcan0_pins {
- pinctrl-single,pins = <
- /* uart1_ctsn.dcan0_tx */
- AM33XX_PADCONF(AM335X_PIN_UART1_CTSN, PIN_OUTPUT, MUX_MODE2)
- /* uart1_rtsn.dcan0_rx */
- AM33XX_PADCONF(AM335X_PIN_UART1_RTSN, PIN_INPUT, MUX_MODE2)
- >;
- };
-
- dcan1_pins: pinmux_dcan1_pins {
- pinctrl-single,pins = <
- /* uart1_rxd.dcan1_tx */
- AM33XX_PADCONF(AM335X_PIN_UART1_RXD, PIN_OUTPUT, MUX_MODE2)
- /* uart1_txd.dcan1_rx */
- AM33XX_PADCONF(AM335X_PIN_UART1_TXD, PIN_INPUT, MUX_MODE2)
- >;
- };
-
- ecap0_pins: pinmux_ecap0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_ECAP0_IN_PWM0_OUT, 0x0, MUX_MODE0)
- >;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins = <
- /* Slave 1 */
- /* mii1_tx_en.rgmii1_tctl */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
- /* mii1_rxdv.rgmii1_rctl */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE2)
- /* mii1_txd3.rgmii1_td3 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
- /* mii1_txd2.rgmii1_td2 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
- /* mii1_txd1.rgmii1_td1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
- /* mii1_txd0.rgmii1_td0 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
- /* mii1_txclk.rgmii1_tclk */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
- /* mii1_rxclk.rgmii1_rclk */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE2)
- /* mii1_rxd3.rgmii1_rd3 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLDOWN, MUX_MODE2)
- /* mii1_rxd2.rgmii1_rd2 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLDOWN, MUX_MODE2)
- /* mii1_rxd1.rgmii1_rd1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE2)
- /* mii1_rxd0.rgmii1_rd0 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE2)
- >;
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins = <
- /* Slave 1 reset value */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- davinci_mdio_default: davinci_mdio_default {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLUP | SLEWCTRL_FAST, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- davinci_mdio_sleep: davinci_mdio_sleep {
- pinctrl-single,pins = <
- /* MDIO reset value */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT3, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT2, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT1, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CLK, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CMD, PIN_INPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- spi0_pins: pinmux_spi0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_OUTPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_SPI0_D1, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_SPI0_CS0, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_SPI0_CS1, PIN_OUTPUT, MUX_MODE0)
- >;
- };
-
- /* wl1271 bluetooth */
- bluetooth_pins: pinmux_bluetooth_pins {
- pinctrl-single,pins = <
- /* XDMA_EVENT_INTR0.gpio0_19 - bluetooth enable */
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR0, PIN_OUTPUT_PULLUP, MUX_MODE7)
- >;
- };
-
- /* TLV320AIC23B codec */
- mcasp1_pins: pinmux_mcasp1_pins {
- pinctrl-single,pins = <
- /* MII1_CRS.mcasp1_aclkx */
- AM33XX_PADCONF(AM335X_PIN_MII1_CRS, PIN_INPUT_PULLDOWN, MUX_MODE4)
- /* MII1_RX_ER.mcasp1_fsx */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_INPUT_PULLDOWN, MUX_MODE4)
- /* MII1_COL.mcasp1_axr2 */
- AM33XX_PADCONF(AM335X_PIN_MII1_COL, PIN_INPUT_PULLDOWN, MUX_MODE4)
- /* RMII1_REF_CLK.mcasp1_axr3 */
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE4)
- >;
- };
-
- /* wl1271 WiFi */
- wifi_pins: pinmux_wifi_pins {
- pinctrl-single,pins = <
- /* EMU1.gpio3_8 - WiFi IRQ */
- AM33XX_PADCONF(AM335X_PIN_EMU1, PIN_INPUT_PULLUP, MUX_MODE7)
- /* XDMA_EVENT_INTR1.gpio0_20 - WiFi enable */
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR1, PIN_OUTPUT, MUX_MODE7)
- >;
- };
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-
- status = "okay";
-};
-
-/* WLS1271 bluetooth */
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins>;
-
-status = "okay";
-};
-
-&i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
-
- status = "okay";
- clock-frequency = <400000>;
- /* CM-T335 board EEPROM */
- eeprom: 24c02@50 {
- compatible = "atmel,24c02";
- reg = <0x50>;
- pagesize = <16>;
- };
- /* Real Time Clock */
- ext_rtc: em3027@56 {
- compatible = "emmicro,em3027";
- reg = <0x56>;
- };
- /* Audio codec */
- tlv320aic23: codec@1a {
- compatible = "ti,tlv320aic23";
- reg = <0x1a>;
- #sound-dai-cells = <0>;
- status = "okay";
- };
-};
-
-&epwmss0 {
- status = "okay";
-
- ecap0: pwm@100 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&ecap0_pins>;
- };
-};
-
-&gpmc {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&nandflash_pins>;
- ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
- nand@0,0 {
- compatible = "ti,omap2-nand";
- reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
- interrupt-parent = <&gpmc>;
- interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
- <1 IRQ_TYPE_NONE>; /* termcount */
- rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
- ti,nand-ecc-opt = "bch8";
- ti,elm-id = <&elm>;
- nand-bus-width = <8>;
- gpmc,device-width = <1>;
- gpmc,sync-clk-ps = <0>;
- gpmc,cs-on-ns = <0>;
- gpmc,cs-rd-off-ns = <44>;
- gpmc,cs-wr-off-ns = <44>;
- gpmc,adv-on-ns = <6>;
- gpmc,adv-rd-off-ns = <34>;
- gpmc,adv-wr-off-ns = <44>;
- gpmc,we-on-ns = <0>;
- gpmc,we-off-ns = <40>;
- gpmc,oe-on-ns = <0>;
- gpmc,oe-off-ns = <54>;
- gpmc,access-ns = <64>;
- gpmc,rd-cycle-ns = <82>;
- gpmc,wr-cycle-ns = <82>;
- gpmc,bus-turnaround-ns = <0>;
- gpmc,cycle2cycle-delay-ns = <0>;
- gpmc,clk-activation-ns = <0>;
- gpmc,wr-access-ns = <40>;
- gpmc,wr-data-mux-bus-ns = <0>;
- /* MTD partition table */
- #address-cells = <1>;
- #size-cells = <1>;
- partition@0 {
- label = "spl";
- reg = <0x00000000 0x00200000>;
- };
- partition@1 {
- label = "uboot";
- reg = <0x00200000 0x00100000>;
- };
- partition@2 {
- label = "uboot environment";
- reg = <0x00300000 0x00100000>;
- };
- partition@3 {
- label = "dtb";
- reg = <0x00400000 0x00100000>;
- };
- partition@4 {
- label = "splash";
- reg = <0x00500000 0x00400000>;
- };
- partition@5 {
- label = "linux";
- reg = <0x00900000 0x00600000>;
- };
- partition@6 {
- label = "rootfs";
- reg = <0x00F00000 0>;
- };
- };
-};
-
-&elm {
- status = "okay";
-};
-
-&mac_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&cpsw_default>;
- pinctrl-1 = <&cpsw_sleep>;
- status = "okay";
-};
-
-&davinci_mdio_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&davinci_mdio_default>;
- pinctrl-1 = <&davinci_mdio_sleep>;
-
- ethphy0: ethernet-phy@0 {
- reg = <0>;
- };
-};
-
-&cpsw_port1 {
- phy-handle = <ðphy0>;
- phy-mode = "rgmii-txid";
- ti,dual-emac-pvid = <1>;
-};
-
-&cpsw_port2 {
- status = "disabled";
-};
-
-&mmc1 {
- status = "okay";
- vmmc-supply = <&vmmc_fixed>;
- bus-width = <4>;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins>;
-};
-
-&dcan0 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&dcan0_pins>;
-};
-
-&dcan1 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&dcan1_pins>;
-};
-
-/* Touschscreen and analog digital converter */
-&tscadc {
- status = "okay";
- tsc {
- ti,wires = <4>;
- ti,x-plate-resistance = <200>;
- ti,coordinate-readouts = <5>;
- ti,wire-config = <0x01 0x10 0x23 0x32>;
- ti,charge-delay = <0x400>;
- };
-
- adc {
- ti,adc-channels = <4 5 6 7>;
- };
-};
-
-/* CPU audio */
-&mcasp1 {
- pinctrl-names = "default";
- pinctrl-0 = <&mcasp1_pins>;
-
- op-mode = <0>; /* MCASP_IIS_MODE */
- tdm-slots = <2>;
- /* 16 serializers */
- num-serializer = <16>;
- serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
- 0 0 2 1 0 0 0 0 0 0 0 0 0 0 0 0
- >;
- tx-num-evt = <1>;
- rx-num-evt = <1>;
-
- #sound-dai-cells = <0>;
- status = "okay";
-};
-
-&spi0 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&spi0_pins>;
- ti,pindir-d0-out-d1-in;
- /* WLS1271 WiFi */
- wlcore: wlcore@1 {
- compatible = "ti,wl1271";
- pinctrl-names = "default";
- pinctrl-0 = <&wifi_pins>;
- reg = <1>;
- spi-max-frequency = <48000000>;
- clock-xtal;
- ref-clock-frequency = <38400000>;
- interrupt-parent = <&gpio3>;
- interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
- vwlan-supply = <&vwlan_fixed>;
- };
-};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
deleted file mode 100644
index 5beabaa..0000000
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ /dev/null
@@ -1,786 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-/dts-v1/;
-
-#include "am33xx.dtsi"
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "TI AM335x EVM";
- compatible = "ti,am335x-evm", "ti,am33xx";
-
- cpus {
- cpu@0 {
- cpu0-supply = <&vdd1_reg>;
- };
- };
-
- memory@80000000 {
- device_type = "memory";
- reg = <0x80000000 0x10000000>; /* 256 MB */
- };
-
- chosen {
- stdout-path = &uart0;
- };
-
- vbat: fixedregulator0 {
- compatible = "regulator-fixed";
- regulator-name = "vbat";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-boot-on;
- };
-
- lis3_reg: fixedregulator1 {
- compatible = "regulator-fixed";
- regulator-name = "lis3_reg";
- regulator-boot-on;
- };
-
- wlan_en_reg: fixedregulator2 {
- compatible = "regulator-fixed";
- regulator-name = "wlan-en-regulator";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- /* WLAN_EN GPIO for this board - Bank1, pin16 */
- gpio = <&gpio1 16 0>;
-
- /* WLAN card specific delay */
- startup-delay-us = <70000>;
- enable-active-high;
- };
-
- /* TPS79501 */
- v1_8d_reg: fixedregulator-v1_8d {
- compatible = "regulator-fixed";
- regulator-name = "v1_8d";
- vin-supply = <&vbat>;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- /* TPS79501 */
- v3_3d_reg: fixedregulator-v3_3d {
- compatible = "regulator-fixed";
- regulator-name = "v3_3d";
- vin-supply = <&vbat>;
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- matrix_keypad: matrix_keypad0 {
- compatible = "gpio-matrix-keypad";
- debounce-delay-ms = <5>;
- col-scan-delay-us = <2>;
-
- row-gpios = <&gpio1 25 GPIO_ACTIVE_HIGH /* Bank1, pin25 */
- &gpio1 26 GPIO_ACTIVE_HIGH /* Bank1, pin26 */
- &gpio1 27 GPIO_ACTIVE_HIGH>; /* Bank1, pin27 */
-
- col-gpios = <&gpio1 21 GPIO_ACTIVE_HIGH /* Bank1, pin21 */
- &gpio1 22 GPIO_ACTIVE_HIGH>; /* Bank1, pin22 */
-
- linux,keymap = <0x0000008b /* MENU */
- 0x0100009e /* BACK */
- 0x02000069 /* LEFT */
- 0x0001006a /* RIGHT */
- 0x0101001c /* ENTER */
- 0x0201006c>; /* DOWN */
- };
-
- gpio_keys: volume-keys {
- compatible = "gpio-keys";
- autorepeat;
-
- switch-9 {
- label = "volume-up";
- linux,code = <115>;
- gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
- wakeup-source;
- };
-
- switch-10 {
- label = "volume-down";
- linux,code = <114>;
- gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
- wakeup-source;
- };
- };
-
- backlight: backlight {
- compatible = "pwm-backlight";
- pwms = <&ecap0 0 50000 0>;
- brightness-levels = <0 51 53 56 62 75 101 152 255>;
- default-brightness-level = <8>;
- };
-
- panel {
- compatible = "tfc,s9700rtwv43tr-01b";
-
- pinctrl-names = "default";
- pinctrl-0 = <&lcd_pins_s0>;
- backlight = <&backlight>;
-
- port {
- panel_0: endpoint {
- remote-endpoint = <&lcdc_0>;
- };
- };
- };
-
- sound {
- compatible = "simple-audio-card";
- simple-audio-card,name = "AM335x-EVM";
- simple-audio-card,widgets =
- "Headphone", "Headphone Jack",
- "Line", "Line In";
- simple-audio-card,routing =
- "Headphone Jack", "HPLOUT",
- "Headphone Jack", "HPROUT",
- "LINE1L", "Line In",
- "LINE1R", "Line In";
- simple-audio-card,format = "dsp_b";
- simple-audio-card,bitclock-master = <&sound_master>;
- simple-audio-card,frame-master = <&sound_master>;
- simple-audio-card,bitclock-inversion;
-
- simple-audio-card,cpu {
- sound-dai = <&mcasp1>;
- };
-
- sound_master: simple-audio-card,codec {
- sound-dai = <&tlv320aic3106>;
- system-clock-frequency = <12000000>;
- };
- };
-};
-
-&am33xx_pinmux {
- pinctrl-names = "default";
- pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0 &clkout2_pin>;
-
- matrix_keypad_s0: matrix_keypad_s0 {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_a5.gpio1_21 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A6, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_a6.gpio1_22 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A9, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_a9.gpio1_25 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A10, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_a10.gpio1_26 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A11, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_a11.gpio1_27 */
- >;
- };
-
- volume_keys_s0: volume_keys_s0 {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT_PULLDOWN, MUX_MODE7) /* spi0_sclk.gpio0_2 */
- AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_INPUT_PULLDOWN, MUX_MODE7) /* spi0_d0.gpio0_3 */
- >;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLUP, MUX_MODE0) /* i2c0_sda.i2c0_sda */
- AM33XX_PADCONF(AM335X_PIN_I2C0_SCL, PIN_INPUT_PULLUP, MUX_MODE0) /* i2c0_scl.i2c0_scl */
- >;
- };
-
- i2c1_pins: pinmux_i2c1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_D1, PIN_INPUT_PULLUP, MUX_MODE2) /* spi0_d1.i2c1_sda */
- AM33XX_PADCONF(AM335X_PIN_SPI0_CS0, PIN_INPUT_PULLUP, MUX_MODE2) /* spi0_cs0.i2c1_scl */
- >;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- uart1_pins: pinmux_uart1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART1_CTSN, PIN_INPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_RTSN, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART1_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR1, PIN_OUTPUT_PULLDOWN, MUX_MODE3) /* xdma_event_intr1.clkout2 */
- >;
- };
-
- nandflash_pins_s0: nandflash_pins_s0 {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD1, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD2, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD3, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD4, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_wpn.gpio0_31 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_OEN_REN, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_WEN, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_BEN0_CLE, PIN_OUTPUT, MUX_MODE0)
- >;
- };
-
- ecap0_pins: backlight_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_ECAP0_IN_PWM0_OUT, 0x0, MUX_MODE0)
- >;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins = <
- /* Slave 1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txen.rgmii1_tctl */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxdv.rgmii1_rctl */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txd3.rgmii1_td3 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txd2.rgmii1_td2 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txd1.rgmii1_td1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txd0.rgmii1_td0 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txclk.rgmii1_tclk */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxclk.rgmii1_rclk */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxd3.rgmii1_rd3 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxd2.rgmii1_rd2 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxd1.rgmii1_rd1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxd0.rgmii1_rd0 */
- >;
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins = <
- /* Slave 1 reset value */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- davinci_mdio_default: davinci_mdio_default {
- pinctrl-single,pins = <
- /* MDIO */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLUP | SLEWCTRL_FAST, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- davinci_mdio_sleep: davinci_mdio_sleep {
- pinctrl-single,pins = <
- /* MDIO reset value */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_CS1, PIN_INPUT, MUX_MODE7) /* spi0_cs1.gpio0_6 */
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT1, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT2, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT3, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CMD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CLK, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MCASP0_ACLKR, PIN_INPUT, MUX_MODE4) /* mcasp0_aclkr.mmc0_sdwp */
- >;
- };
-
- mmc3_pins: pinmux_mmc3_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_A1, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_a1.mmc2_dat0, INPUT_PULLUP | MODE3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A2, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_a2.mmc2_dat1, INPUT_PULLUP | MODE3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A3, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_a3.mmc2_dat2, INPUT_PULLUP | MODE3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_BEN1, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_ben1.mmc2_dat3, INPUT_PULLUP | MODE3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN3, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_csn3.mmc2_cmd, INPUT_PULLUP | MODE3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CLK, PIN_INPUT_PULLUP, MUX_MODE3) /* gpmc_clk.mmc2_clk, INPUT_PULLUP | MODE3 */
- >;
- };
-
- wlan_pins: pinmux_wlan_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_A0, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_a0.gpio1_16 */
- AM33XX_PADCONF(AM335X_PIN_MCASP0_AHCLKR, PIN_INPUT, MUX_MODE7) /* mcasp0_ahclkr.gpio3_17 */
- AM33XX_PADCONF(AM335X_PIN_MCASP0_AHCLKX, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* mcasp0_ahclkx.gpio3_21 */
- >;
- };
-
- lcd_pins_s0: lcd_pins_s0 {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD8, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad8.lcd_data23 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD9, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad9.lcd_data22 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD10, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad10.lcd_data21 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD11, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad11.lcd_data20 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad12.lcd_data19 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad13.lcd_data18 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD14, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad14.lcd_data17 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD15, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad15.lcd_data16 */
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA0, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA1, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA2, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA3, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA4, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA5, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA6, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA7, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA8, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA9, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA10, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA11, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA12, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA13, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA14, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA15, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_VSYNC, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_HSYNC, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_PCLK, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_AC_BIAS_EN, PIN_OUTPUT, MUX_MODE0)
- >;
- };
-
- mcasp1_pins: mcasp1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_CRS, PIN_INPUT_PULLDOWN, MUX_MODE4) /* mii1_crs.mcasp1_aclkx */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_INPUT_PULLDOWN, MUX_MODE4) /* mii1_rxerr.mcasp1_fsx */
- AM33XX_PADCONF(AM335X_PIN_MII1_COL, PIN_OUTPUT_PULLDOWN, MUX_MODE4) /* mii1_col.mcasp1_axr2 */
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE4) /* rmii1_ref_clk.mcasp1_axr3 */
- >;
- };
-
- mcasp1_pins_sleep: mcasp1_pins_sleep {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_CRS, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_COL, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- dcan1_pins_default: dcan1_pins_default {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_OUTPUT, MUX_MODE2) /* uart0_ctsn.d_can1_tx */
- AM33XX_PADCONF(AM335X_PIN_UART0_RTSN, PIN_INPUT_PULLDOWN, MUX_MODE2) /* uart0_rtsn.d_can1_rx */
- >;
- };
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-
- status = "okay";
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins>;
-
- status = "okay";
-};
-
-&i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
-
- status = "okay";
- clock-frequency = <400000>;
-
- tps: tps@2d {
- reg = <0x2d>;
- };
-};
-
-&usb1 {
- dr_mode = "host";
-};
-
-&i2c1 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c1_pins>;
-
- status = "okay";
- clock-frequency = <100000>;
-
- lis331dlh: lis331dlh@18 {
- compatible = "st,lis331dlh", "st,lis3lv02d";
- reg = <0x18>;
- Vdd-supply = <&lis3_reg>;
- Vdd_IO-supply = <&lis3_reg>;
-
- st,click-single-x;
- st,click-single-y;
- st,click-single-z;
- st,click-thresh-x = <10>;
- st,click-thresh-y = <10>;
- st,click-thresh-z = <10>;
- st,irq1-click;
- st,irq2-click;
- st,wakeup-x-lo;
- st,wakeup-x-hi;
- st,wakeup-y-lo;
- st,wakeup-y-hi;
- st,wakeup-z-lo;
- st,wakeup-z-hi;
- st,min-limit-x = <120>;
- st,min-limit-y = <120>;
- st,min-limit-z = <140>;
- st,max-limit-x = <550>;
- st,max-limit-y = <550>;
- st,max-limit-z = <750>;
- };
-
- tsl2550: tsl2550@39 {
- compatible = "taos,tsl2550";
- reg = <0x39>;
- };
-
- tmp275: tmp275@48 {
- compatible = "ti,tmp275";
- reg = <0x48>;
- };
-
- tlv320aic3106: tlv320aic3106@1b {
- #sound-dai-cells = <0>;
- compatible = "ti,tlv320aic3106";
- reg = <0x1b>;
- status = "okay";
-
- /* Regulators */
- AVDD-supply = <&v3_3d_reg>;
- IOVDD-supply = <&v3_3d_reg>;
- DRVDD-supply = <&v3_3d_reg>;
- DVDD-supply = <&v1_8d_reg>;
- };
-};
-
-&lcdc {
- status = "okay";
-
- blue-and-red-wiring = "crossed";
-
- port {
- lcdc_0: endpoint@0 {
- remote-endpoint = <&panel_0>;
- };
- };
-};
-
-&elm {
- status = "okay";
-};
-
-&epwmss0 {
- status = "okay";
-
- ecap0: pwm@100 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&ecap0_pins>;
- };
-};
-
-&gpmc {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&nandflash_pins_s0>;
- ranges = <0 0 0x08000000 0x1000000>; /* CS0: 16MB for NAND */
- nand@0,0 {
- compatible = "ti,omap2-nand";
- reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
- interrupt-parent = <&gpmc>;
- interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
- <1 IRQ_TYPE_NONE>; /* termcount */
- rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
- ti,nand-xfer-type = "prefetch-dma";
- ti,nand-ecc-opt = "bch8";
- ti,elm-id = <&elm>;
- nand-bus-width = <8>;
- gpmc,device-width = <1>;
- gpmc,sync-clk-ps = <0>;
- gpmc,cs-on-ns = <0>;
- gpmc,cs-rd-off-ns = <44>;
- gpmc,cs-wr-off-ns = <44>;
- gpmc,adv-on-ns = <6>;
- gpmc,adv-rd-off-ns = <34>;
- gpmc,adv-wr-off-ns = <44>;
- gpmc,we-on-ns = <0>;
- gpmc,we-off-ns = <40>;
- gpmc,oe-on-ns = <0>;
- gpmc,oe-off-ns = <54>;
- gpmc,access-ns = <64>;
- gpmc,rd-cycle-ns = <82>;
- gpmc,wr-cycle-ns = <82>;
- gpmc,bus-turnaround-ns = <0>;
- gpmc,cycle2cycle-delay-ns = <0>;
- gpmc,clk-activation-ns = <0>;
- gpmc,wr-access-ns = <40>;
- gpmc,wr-data-mux-bus-ns = <0>;
- /* MTD partition table */
- /* All SPL-* partitions are sized to minimal length
- * which can be independently programmable. For
- * NAND flash this is equal to size of erase-block */
- #address-cells = <1>;
- #size-cells = <1>;
- partition@0 {
- label = "NAND.SPL";
- reg = <0x00000000 0x00020000>;
- };
- partition@1 {
- label = "NAND.SPL.backup1";
- reg = <0x00020000 0x00020000>;
- };
- partition@2 {
- label = "NAND.SPL.backup2";
- reg = <0x00040000 0x00020000>;
- };
- partition@3 {
- label = "NAND.SPL.backup3";
- reg = <0x00060000 0x00020000>;
- };
- partition@4 {
- label = "NAND.u-boot-spl-os";
- reg = <0x00080000 0x00040000>;
- };
- partition@5 {
- label = "NAND.u-boot";
- reg = <0x000C0000 0x00100000>;
- };
- partition@6 {
- label = "NAND.u-boot-env";
- reg = <0x001C0000 0x00020000>;
- };
- partition@7 {
- label = "NAND.u-boot-env.backup1";
- reg = <0x001E0000 0x00020000>;
- };
- partition@8 {
- label = "NAND.kernel";
- reg = <0x00200000 0x00800000>;
- };
- partition@9 {
- label = "NAND.file-system";
- reg = <0x00A00000 0x0F600000>;
- };
- };
-};
-
-#include "tps65910.dtsi"
-
-&mcasp1 {
- #sound-dai-cells = <0>;
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&mcasp1_pins>;
- pinctrl-1 = <&mcasp1_pins_sleep>;
-
- status = "okay";
-
- op-mode = <0>; /* MCASP_IIS_MODE */
- tdm-slots = <2>;
- /* 4 serializers */
- serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
- 0 0 1 2
- >;
- tx-num-evt = <32>;
- rx-num-evt = <32>;
-};
-
-&tps {
- vcc1-supply = <&vbat>;
- vcc2-supply = <&vbat>;
- vcc3-supply = <&vbat>;
- vcc4-supply = <&vbat>;
- vcc5-supply = <&vbat>;
- vcc6-supply = <&vbat>;
- vcc7-supply = <&vbat>;
- vccio-supply = <&vbat>;
-
- regulators {
- vrtc_reg: regulator@0 {
- regulator-always-on;
- };
-
- vio_reg: regulator@1 {
- regulator-always-on;
- };
-
- vdd1_reg: regulator@2 {
- /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
- regulator-name = "vdd_mpu";
- regulator-min-microvolt = <912500>;
- regulator-max-microvolt = <1351500>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vdd2_reg: regulator@3 {
- /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
- regulator-name = "vdd_core";
- regulator-min-microvolt = <912500>;
- regulator-max-microvolt = <1150000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vdd3_reg: regulator@4 {
- regulator-always-on;
- };
-
- vdig1_reg: regulator@5 {
- regulator-always-on;
- };
-
- vdig2_reg: regulator@6 {
- regulator-always-on;
- };
-
- vpll_reg: regulator@7 {
- regulator-always-on;
- };
-
- vdac_reg: regulator@8 {
- regulator-always-on;
- };
-
- vaux1_reg: regulator@9 {
- regulator-always-on;
- };
-
- vaux2_reg: regulator@10 {
- regulator-always-on;
- };
-
- vaux33_reg: regulator@11 {
- regulator-always-on;
- };
-
- vmmc_reg: regulator@12 {
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
- };
-};
-
-&mac_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&cpsw_default>;
- pinctrl-1 = <&cpsw_sleep>;
- status = "okay";
-};
-
-&davinci_mdio_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&davinci_mdio_default>;
- pinctrl-1 = <&davinci_mdio_sleep>;
-
- ethphy0: ethernet-phy@0 {
- reg = <0>;
- };
-};
-
-&cpsw_port1 {
- phy-handle = <ðphy0>;
- phy-mode = "rgmii-id";
- ti,dual-emac-pvid = <1>;
-};
-
-&cpsw_port2 {
- status = "disabled";
-};
-
-&tscadc {
- status = "okay";
- tsc {
- ti,wires = <4>;
- ti,x-plate-resistance = <200>;
- ti,coordinate-readouts = <5>;
- ti,wire-config = <0x00 0x11 0x22 0x33>;
- ti,charge-delay = <0x400>;
- };
-
- adc {
- ti,adc-channels = <4 5 6 7>;
- };
-};
-
-&mmc1 {
- status = "okay";
- vmmc-supply = <&vmmc_reg>;
- bus-width = <4>;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins>;
- cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
-};
-
-&mmc3 {
- /* these are on the crossbar and are outlined in the
- xbar-event-map element */
- dmas = <&edma_xbar 12 0 1
- &edma_xbar 13 0 2>;
- dma-names = "tx", "rx";
- status = "okay";
- vmmc-supply = <&wlan_en_reg>;
- bus-width = <4>;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc3_pins &wlan_pins>;
- non-removable;
- cap-power-off-card;
- keep-power-in-suspend;
-
- #address-cells = <1>;
- #size-cells = <0>;
- wlcore: wlcore@0 {
- compatible = "ti,wl1835";
- reg = <2>;
- interrupt-parent = <&gpio3>;
- interrupts = <17 IRQ_TYPE_EDGE_RISING>;
- };
-};
-
-&sham {
- status = "okay";
-};
-
-&aes {
- status = "okay";
-};
-
-&dcan1 {
- status = "disabled"; /* Enable only if Profile 1 is selected */
- pinctrl-names = "default";
- pinctrl-0 = <&dcan1_pins_default>;
-};
-
-&rtc {
- clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
- clock-names = "ext-clk", "int-clk";
-};
-
-&pruss_tm {
- status = "okay";
-};
-
-&wkup_m3_ipc {
- firmware-name = "am335x-evm-scale-data.bin";
-};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
deleted file mode 100644
index 5b3278c..0000000
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ /dev/null
@@ -1,725 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-/*
- * AM335x Starter Kit
- * http://www.ti.com/tool/tmdssk3358
- */
-
-/dts-v1/;
-
-#include "am33xx.dtsi"
-#include <dt-bindings/pwm/pwm.h>
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "TI AM335x EVM-SK";
- compatible = "ti,am335x-evmsk", "ti,am33xx";
-
- cpus {
- cpu@0 {
- cpu0-supply = <&vdd1_reg>;
- };
- };
-
- memory@80000000 {
- device_type = "memory";
- reg = <0x80000000 0x10000000>; /* 256 MB */
- };
-
- chosen {
- stdout-path = &uart0;
- };
-
- vbat: fixedregulator0 {
- compatible = "regulator-fixed";
- regulator-name = "vbat";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-boot-on;
- };
-
- lis3_reg: fixedregulator1 {
- compatible = "regulator-fixed";
- regulator-name = "lis3_reg";
- regulator-boot-on;
- };
-
- wl12xx_vmmc: fixedregulator2 {
- pinctrl-names = "default";
- pinctrl-0 = <&wl12xx_gpio>;
- compatible = "regulator-fixed";
- regulator-name = "vwl1271";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- gpio = <&gpio1 29 0>;
- startup-delay-us = <70000>;
- enable-active-high;
- };
-
- vtt_fixed: fixedregulator3 {
- compatible = "regulator-fixed";
- regulator-name = "vtt";
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <1500000>;
- gpio = <&gpio0 7 GPIO_ACTIVE_HIGH>;
- regulator-always-on;
- regulator-boot-on;
- enable-active-high;
- };
-
- /* TPS79518 */
- v1_8d_reg: fixedregulator-v1_8d {
- compatible = "regulator-fixed";
- regulator-name = "v1_8d";
- vin-supply = <&vbat>;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- /* TPS78633 */
- v3_3d_reg: fixedregulator-v3_3d {
- compatible = "regulator-fixed";
- regulator-name = "v3_3d";
- vin-supply = <&vbat>;
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- leds {
- pinctrl-names = "default";
- pinctrl-0 = <&user_leds_s0>;
-
- compatible = "gpio-leds";
-
- led1 {
- label = "evmsk:green:usr0";
- gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
-
- led2 {
- label = "evmsk:green:usr1";
- gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
-
- led3 {
- label = "evmsk:green:mmc0";
- gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "mmc0";
- default-state = "off";
- };
-
- led4 {
- label = "evmsk:green:heartbeat";
- gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- default-state = "off";
- };
- };
-
- gpio_buttons: gpio_buttons0 {
- compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
-
- switch1 {
- label = "button0";
- linux,code = <0x100>;
- gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
- };
-
- switch2 {
- label = "button1";
- linux,code = <0x101>;
- gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
- };
-
- switch3 {
- label = "button2";
- linux,code = <0x102>;
- gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>;
- wakeup-source;
- };
-
- switch4 {
- label = "button3";
- linux,code = <0x103>;
- gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
- };
- };
-
- lcd_bl: backlight {
- compatible = "pwm-backlight";
- pwms = <&ecap2 0 50000 PWM_POLARITY_INVERTED>;
- brightness-levels = <0 58 61 66 75 90 125 170 255>;
- default-brightness-level = <8>;
- };
-
- sound {
- compatible = "simple-audio-card";
- simple-audio-card,name = "AM335x-EVMSK";
- simple-audio-card,widgets =
- "Headphone", "Headphone Jack";
- simple-audio-card,routing =
- "Headphone Jack", "HPLOUT",
- "Headphone Jack", "HPROUT";
- simple-audio-card,format = "dsp_b";
- simple-audio-card,bitclock-master = <&sound_master>;
- simple-audio-card,frame-master = <&sound_master>;
- simple-audio-card,bitclock-inversion;
-
- simple-audio-card,cpu {
- sound-dai = <&mcasp1>;
- };
-
- sound_master: simple-audio-card,codec {
- sound-dai = <&tlv320aic3106>;
- system-clock-frequency = <24000000>;
- };
- };
-
- panel {
- compatible = "newhaven,nhd-4.3-480272ef-atxl";
-
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&lcd_pins_default>;
- pinctrl-1 = <&lcd_pins_sleep>;
- backlight = <&lcd_bl>;
-
- port {
- panel_0: endpoint {
- remote-endpoint = <&lcdc_0>;
- };
- };
- };
-};
-
-&am33xx_pinmux {
- pinctrl-names = "default";
- pinctrl-0 = <&gpio_keys_s0 &clkout2_pin>;
-
- lcd_pins_default: lcd_pins_default {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD8, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad8.lcd_data23 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD9, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad9.lcd_data22 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD10, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad10.lcd_data21 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD11, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad11.lcd_data20 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad12.lcd_data19 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad13.lcd_data18 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD14, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad14.lcd_data17 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD15, PIN_OUTPUT, MUX_MODE1) /* gpmc_ad15.lcd_data16 */
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA0, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA1, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA2, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA3, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA4, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA5, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA6, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA7, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA8, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA9, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA10, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA11, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA12, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA13, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA14, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA15, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_VSYNC, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_HSYNC, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_PCLK, PIN_OUTPUT, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_LCD_AC_BIAS_EN, PIN_OUTPUT, MUX_MODE0)
- >;
- };
-
- lcd_pins_sleep: lcd_pins_sleep {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD8, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad8.lcd_data23 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD9, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad9.lcd_data22 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD10, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad10.lcd_data21 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD11, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad11.lcd_data20 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad12.lcd_data19 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad13.lcd_data18 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD14, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad14.lcd_data17 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD15, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad15.lcd_data16 */
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA0, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA1, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA2, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA3, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA4, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA5, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA6, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA7, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA8, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA9, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA10, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA11, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA12, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA13, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA14, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_DATA15, PULL_DISABLE, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_VSYNC, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_HSYNC, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_PCLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_LCD_AC_BIAS_EN, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
-
- user_leds_s0: user_leds_s0 {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD4, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad4.gpio1_4 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad5.gpio1_5 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad6.gpio1_6 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* gpmc_ad7.gpio1_7 */
- >;
- };
-
- gpio_keys_s0: gpio_keys_s0 {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_OEN_REN, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_oen_ren.gpio2_3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_advn_ale.gpio2_2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_wait0.gpio0_30 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_BEN0_CLE, PIN_INPUT_PULLDOWN, MUX_MODE7) /* gpmc_ben0_cle.gpio2_5 */
- >;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_I2C0_SCL, PIN_INPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_UART0_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
- >;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR1, PIN_OUTPUT_PULLDOWN, MUX_MODE3) /* xdma_event_intr1.clkout2 */
- >;
- };
-
- ecap2_pins: backlight_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MCASP0_AHCLKR, 0x0, MUX_MODE4) /* mcasp0_ahclkr.ecap2_in_pwm2_out */
- >;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins = <
- /* Slave 1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txen.rgmii1_tctl */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxdv.rgmii1_rctl */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txd3.rgmii1_td3 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txd2.rgmii1_td2 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txd1.rgmii1_td1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txd0.rgmii1_td0 */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* mii1_txclk.rgmii1_tclk */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxclk.rgmii1_rclk */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxd3.rgmii1_rd3 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxd2.rgmii1_rd2 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxd1.rgmii1_rd1 */
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE2) /* mii1_rxd0.rgmii1_rd0 */
-
- /* Slave 2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A0, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a0.rgmii2_tctl */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A1, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a1.rgmii2_rctl */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A2, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a2.rgmii2_td3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A3, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a3.rgmii2_td2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A4, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a4.rgmii2_td1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a5.rgmii2_td0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A6, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* gpmc_a6.rgmii2_tclk */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A7, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a7.rgmii2_rclk */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A8, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a8.rgmii2_rd3 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A9, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a9.rgmii2_rd2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A10, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a10.rgmii2_rd1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_A11, PIN_INPUT_PULLDOWN, MUX_MODE2) /* gpmc_a11.rgmii2_rd0 */
- >;
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins = <
- /* Slave 1 reset value */
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
-
- /* Slave 2 reset value*/
- AM33XX_PADCONF(AM335X_PIN_GPMC_A0, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A1, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A2, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A3, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A4, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A6, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A7, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A8, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A9, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A10, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_GPMC_A11, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- davinci_mdio_default: davinci_mdio_default {
- pinctrl-single,pins = <
- /* MDIO */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLUP | SLEWCTRL_FAST, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLUP, MUX_MODE0)
- >;
- };
-
- davinci_mdio_sleep: davinci_mdio_sleep {
- pinctrl-single,pins = <
- /* MDIO reset value */
- AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MDC, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- mmc1_pins: pinmux_mmc1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_SPI0_CS1, PIN_INPUT, MUX_MODE7) /* spi0_cs1.gpio0_6 */
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT1, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT2, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_DAT3, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CMD, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MMC0_CLK, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_MCASP0_ACLKR, PIN_INPUT, MUX_MODE4) /* mcasp0_aclkr.mmc0_sdwp */
- >;
- };
-
- mcasp1_pins: mcasp1_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_CRS, PIN_INPUT_PULLDOWN, MUX_MODE4) /* mii1_crs.mcasp1_aclkx */
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_INPUT_PULLDOWN, MUX_MODE4) /* mii1_rxerr.mcasp1_fsx */
- AM33XX_PADCONF(AM335X_PIN_MII1_COL, PIN_OUTPUT_PULLDOWN, MUX_MODE4) /* mii1_col.mcasp1_axr2 */
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE4) /* rmii1_ref_clk.mcasp1_axr3 */
- >;
- };
-
- mcasp1_pins_sleep: mcasp1_pins_sleep {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_MII1_CRS, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_MII1_COL, PIN_INPUT_PULLDOWN, MUX_MODE7)
- AM33XX_PADCONF(AM335X_PIN_RMII1_REF_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
- >;
- };
-
- mmc2_pins: pinmux_mmc2_pins {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_wpn.gpio0_31 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN1, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_csn1.mmc1_clk */
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN2, PIN_INPUT_PULLUP, MUX_MODE2) /* gpmc_csn2.mmc1_cmd */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD0, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad0.mmc1_dat0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD1, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad1.mmc1_dat1 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD2, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad2.mmc1_dat2 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_AD3, PIN_INPUT_PULLUP, MUX_MODE1) /* gpmc_ad3.mmc1_dat3 */
- >;
- };
-
- wl12xx_gpio: pinmux_wl12xx_gpio {
- pinctrl-single,pins = <
- AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT_PULLUP, MUX_MODE7) /* gpmc_csn0.gpio1_29 */
- >;
- };
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-
- status = "okay";
-};
-
-&i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
-
- status = "okay";
- clock-frequency = <400000>;
-
- tps: tps@2d {
- reg = <0x2d>;
- };
-
- lis331dlh: lis331dlh@18 {
- compatible = "st,lis331dlh", "st,lis3lv02d";
- reg = <0x18>;
- Vdd-supply = <&lis3_reg>;
- Vdd_IO-supply = <&lis3_reg>;
-
- st,click-single-x;
- st,click-single-y;
- st,click-single-z;
- st,click-thresh-x = <10>;
- st,click-thresh-y = <10>;
- st,click-thresh-z = <10>;
- st,irq1-click;
- st,irq2-click;
- st,wakeup-x-lo;
- st,wakeup-x-hi;
- st,wakeup-y-lo;
- st,wakeup-y-hi;
- st,wakeup-z-lo;
- st,wakeup-z-hi;
- st,min-limit-x = <120>;
- st,min-limit-y = <120>;
- st,min-limit-z = <140>;
- st,max-limit-x = <550>;
- st,max-limit-y = <550>;
- st,max-limit-z = <750>;
- };
-
- tlv320aic3106: tlv320aic3106@1b {
- #sound-dai-cells = <0>;
- compatible = "ti,tlv320aic3106";
- reg = <0x1b>;
- status = "okay";
-
- /* Regulators */
- AVDD-supply = <&v3_3d_reg>;
- IOVDD-supply = <&v3_3d_reg>;
- DRVDD-supply = <&v3_3d_reg>;
- DVDD-supply = <&v1_8d_reg>;
- };
-};
-
-&usb1 {
- dr_mode = "host";
-};
-
-&epwmss2 {
- status = "okay";
-
- ecap2: pwm@100 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&ecap2_pins>;
- };
-};
-
-#include "tps65910.dtsi"
-
-&tps {
- vcc1-supply = <&vbat>;
- vcc2-supply = <&vbat>;
- vcc3-supply = <&vbat>;
- vcc4-supply = <&vbat>;
- vcc5-supply = <&vbat>;
- vcc6-supply = <&vbat>;
- vcc7-supply = <&vbat>;
- vccio-supply = <&vbat>;
-
- regulators {
- vrtc_reg: regulator@0 {
- regulator-always-on;
- };
-
- vio_reg: regulator@1 {
- regulator-always-on;
- };
-
- vdd1_reg: regulator@2 {
- /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
- regulator-name = "vdd_mpu";
- regulator-min-microvolt = <912500>;
- regulator-max-microvolt = <1351500>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vdd2_reg: regulator@3 {
- /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
- regulator-name = "vdd_core";
- regulator-min-microvolt = <912500>;
- regulator-max-microvolt = <1150000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vdd3_reg: regulator@4 {
- regulator-always-on;
- };
-
- vdig1_reg: regulator@5 {
- regulator-always-on;
- };
-
- vdig2_reg: regulator@6 {
- regulator-always-on;
- };
-
- vpll_reg: regulator@7 {
- regulator-always-on;
- };
-
- vdac_reg: regulator@8 {
- regulator-always-on;
- };
-
- vaux1_reg: regulator@9 {
- regulator-always-on;
- };
-
- vaux2_reg: regulator@10 {
- regulator-always-on;
- };
-
- vaux33_reg: regulator@11 {
- regulator-always-on;
- };
-
- vmmc_reg: regulator@12 {
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
- };
-};
-
-&mac_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&cpsw_default>;
- pinctrl-1 = <&cpsw_sleep>;
- status = "okay";
-};
-
-&davinci_mdio_sw {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&davinci_mdio_default>;
- pinctrl-1 = <&davinci_mdio_sleep>;
-
- ethphy0: ethernet-phy@0 {
- reg = <0>;
- };
-
- ethphy1: ethernet-phy@1 {
- reg = <1>;
- };
-};
-
-&cpsw_port1 {
- phy-handle = <ðphy0>;
- phy-mode = "rgmii-id";
- ti,dual-emac-pvid = <1>;
-};
-
-&cpsw_port2 {
- phy-handle = <ðphy1>;
- phy-mode = "rgmii-id";
- ti,dual-emac-pvid = <2>;
-};
-
-&mmc1 {
- status = "okay";
- vmmc-supply = <&vmmc_reg>;
- bus-width = <4>;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins>;
- cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
-};
-
-&sham {
- status = "okay";
-};
-
-&aes {
- status = "okay";
-};
-
-&gpio0_target {
- ti,no-reset-on-init;
-};
-
-&mmc2 {
- status = "okay";
- vmmc-supply = <&wl12xx_vmmc>;
- non-removable;
- bus-width = <4>;
- cap-power-off-card;
- keep-power-in-suspend;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc2_pins>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- wlcore: wlcore@2 {
- compatible = "ti,wl1271";
- reg = <2>;
- interrupt-parent = <&gpio0>;
- interrupts = <31 IRQ_TYPE_EDGE_RISING>; /* gpio 31 */
- ref-clock-frequency = <38400000>;
- };
-};
-
-&mcasp1 {
- #sound-dai-cells = <0>;
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&mcasp1_pins>;
- pinctrl-1 = <&mcasp1_pins_sleep>;
-
- status = "okay";
-
- op-mode = <0>; /* MCASP_IIS_MODE */
- tdm-slots = <2>;
- /* 4 serializers */
- serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
- 0 0 1 2
- >;
- tx-num-evt = <32>;
- rx-num-evt = <32>;
-};
-
-&tscadc {
- status = "okay";
- tsc {
- ti,wires = <4>;
- ti,x-plate-resistance = <200>;
- ti,coordinate-readouts = <5>;
- ti,wire-config = <0x00 0x11 0x22 0x33>;
- };
-};
-
-&lcdc {
- status = "okay";
-
- blue-and-red-wiring = "crossed";
-
- port {
- lcdc_0: endpoint@0 {
- remote-endpoint = <&panel_0>;
- };
- };
-};
-
-&rtc {
- clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
- clock-names = "ext-clk", "int-clk";
-};
-
-&pruss_tm {
- status = "okay";
-};
-
-&wkup_m3_ipc {
- firmware-name = "am335x-evm-scale-data.bin";
-};
diff --git a/arch/arm/boot/dts/am335x-guardian.dts b/arch/arm/boot/dts/am335x-guardian.dts
deleted file mode 100644
index b357364..0000000
--- a/arch/arm/boot/dts/am335x-guardian.dts
+++ /dev/null
@@ -1,745 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- * Copyright (C) 2018 Robert Bosch Power Tools GmbH
- */
-/dts-v1/;
-
-#include "am33xx.dtsi"
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "Bosch AM335x Guardian";
- compatible = "bosch,am335x-guardian", "ti,am33xx";
-
- chosen {
- stdout-path = &uart0;
- tick-timer = &timer2;
- };
-
- cpus {
- cpu@0 {
- cpu0-supply = <&dcdc2_reg>;
- };
- };
-
- memory@80000000 {
- device_type = "memory";
- reg = <0x80000000 0x10000000>; /* 256 MB */
- };
-
- guardian_buttons: gpio-keys {
- pinctrl-names = "default";
- pinctrl-0 = <&guardian_button_pins>;
- compatible = "gpio-keys";
-
- select-button {
- label = "guardian-select-button";
- linux,code = <KEY_5>;
- gpios = <&gpio1 31 GPIO_ACTIVE_LOW>;
- wakeup-source;
- };
-
- power-button {
- label = "guardian-power-button";
- linux,code = <KEY_POWER>;
- gpios = <&gpio2 21 GPIO_ACTIVE_LOW>;
- wakeup-source;
- };
- };
-
- guardian_leds: gpio-leds {
- pinctrl-names = "default";
- pinctrl-0 = <&guardian_led_pins>;
- compatible = "gpio-leds";
-
- life-led {
- label = "guardian:life-led";
- gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- default-state = "off";
- };
- };
-
- gpio-poweroff {
- compatible = "gpio-poweroff";
- gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
- };
-
- panel {
- compatible = "ti,tilcdc,panel";
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&lcd_pins_default &lcd_disen_pins>;
- pinctrl-1 = <&lcd_pins_sleep>;
-
- display-timings {
- 320x240 {
- hactive = <320>;
- vactive = <240>;
- hback-porch = <68>;
- hfront-porch = <20>;
- hsync-len = <1>;
- vback-porch = <18>;
- vfront-porch = <4>;
- vsync-len = <1>;
- clock-frequency = <9000000>;
- hsync-active = <0>;
- vsync-active = <0>;
- };
- };
- panel-info {
- ac-bias = <255>;
- ac-bias-intrpt = <0>;
- dma-burst-sz = <16>;
- bpp = <24>;
- bus-width = <16>;
- fdd = <0x80>;
- sync-edge = <0>;
- sync-ctrl = <1>;
- raster-order = <0>;
- fifo-th = <0>;
- };
-
- };
-
- guardian_beeper: pwm-7 {
- compatible = "ti,omap-dmtimer-pwm";
- #pwm-cells = <3>;
- ti,timers = <&timer7>;
- pinctrl-names = "default";
- pinctrl-0 = <&guardian_beeper_pins>;
- ti,clock-source = <0x01>;
- };
-
- vmmcsd_fixed: fixedregulator0 {
- compatible = "regulator-fixed";
- regulator-name = "vmmcsd_fixed";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- mt_keypad: mt_keypad@0 {
- compatible = "gpio-mt-keypad";
- debounce-delay-ms = <10>;
- col-scan-delay-us = <2>;
- keypad,num-lines = <5>;
- linux,no-autorepeat;
- gpio-activelow;
- line-gpios = <
- &gpio1 24 GPIO_ACTIVE_LOW /*gpio_56*/
- &gpio1 23 GPIO_ACTIVE_LOW /*gpio_55*/
- &gpio1 22 GPIO_ACTIVE_LOW /*gpio_54*/
- &gpio1 20 GPIO_ACTIVE_LOW /*gpio_52*/
- &gpio1 16 GPIO_ACTIVE_LOW /*gpio_48*/
- >;
- };
-};
-
-&elm {
- status = "okay";
-};
-
-&gpmc {
- pinctrl-names = "default";
- pinctrl-0 = <&nandflash_pins>;
- ranges = <0 0 0x08000000 0x1000000>; /* CS0: 16MB for NAND */
- status = "okay";
-
- nand@0,0 {
- compatible = "ti,omap2-nand";
- reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
- interrupt-parent = <&gpmc>;
- interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
- <1 IRQ_TYPE_NONE>; /* termcount */
- rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
- ti,nand-xfer-type = "prefetch-dma";
- ti,nand-ecc-opt = "bch16";
- ti,elm-id = <&elm>;
- nand-bus-width = <8>;
- gpmc,device-width = <1>;
- gpmc,sync-clk-ps = <0>;
- gpmc,cs-on-ns = <0>;
- gpmc,cs-rd-off-ns = <30>;
- gpmc,cs-wr-off-ns = <30>;
- gpmc,adv-on-ns = <0>;
- gpmc,adv-rd-off-ns = <30>;
- gpmc,adv-wr-off-ns = <30>;
- gpmc,we-on-ns = <0>;
- gpmc,we-off-ns = <15>;
- gpmc,oe-on-ns = <1>;
- gpmc,oe-off-ns = <15>;
- gpmc,access-ns = <30>;
- gpmc,rd-cycle-ns = <30>;
- gpmc,wr-cycle-ns = <30>;
- gpmc,bus-turnaround-ns = <0>;
- gpmc,cycle2cycle-delay-ns = <0>;
- gpmc,clk-activation-ns = <0>;
- gpmc,wr-access-ns = <0>;
- gpmc,wr-data-mux-bus-ns = <0>;
-
- /*
- * MTD partition table
- *
- * All SPL-* partitions are sized to minimal length which can
- * be independently programmable. For NAND flash this is equal
- * to size of erase-block.
- */
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "SPL";
- reg = <0x0 0x40000>;
- };
-
- partition@1 {
- label = "SPL.backup1";
- reg = <0x40000 0x40000>;
- };
-
- partition@2 {
- label = "SPL.backup2";
- reg = <0x80000 0x40000>;
- };
-
- partition@3 {
- label = "SPL.backup3";
- reg = <0xc0000 0x40000>;
- };
-
- partition@4 {
- label = "u-boot";
- reg = <0x100000 0x100000>;
- };
-
- partition@5 {
- label = "u-boot.backup1";
- reg = <0x200000 0x100000>;
- };
-
- partition@6 {
- label = "u-boot-2";
- reg = <0x300000 0x100000>;
- };
-
- partition@7 {
- label = "u-boot-2.backup1";
- reg = <0x400000 0x100000>;
- };
-
- partition@8 {
- label = "u-boot-env";
- reg = <0x500000 0x40000>;
- };
-
- partition@9 {
- label = "u-boot-env.backup1";
- reg = <0x540000 0x40000>;
- };
-
- partition@10 {
- label = "splash-screen";
- reg = <0x580000 0x40000>;
- };
-
- partition@11 {
- label = "UBI";
- reg = <0x5c0000 0x1fa40000>;
- };
- };
-};
-
-&i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
- clock-frequency = <400000>;
- status = "okay";
-
- tps: tps@24 {
- reg = <0x24>;
- };
-};
-
-&lcdc {
- blue-and-red-wiring = "crossed";
- status = "okay";
- port {
- lcdc_0: endpoint@0 {
- remote-endpoint = <0>;
- };
- };
-};
-
-&mmc1 {
- bus-width = <0x4>;
- pinctrl-names = "default";
- pinctrl-0 = <&mmc1_pins>;
- cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
- vmmc-supply = <&vmmcsd_fixed>;
- status = "okay";
-};
-
-&rtc {
- clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
- clock-names = "ext-clk", "int-clk";
-};
-
-&spi0 {
- ti,pindir-d0-out-d1-in;
- pinctrl-names = "default";
- pinctrl-0 = <&spi0_pins>;
- status = "okay";
-};
-
-#include "tps65217.dtsi"
-
-&tps {
- /*
- * Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
- * mode") at poweroff. Most BeagleBone versions do not support RTC-only
- * mode and risk hardware damage if this mode is entered.
- *
- * For details, see linux-omap mailing list May 2015 thread
- * [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
- * In particular, messages:
- * http://www.spinics.net/lists/linux-omap/msg118585.html
- * http://www.spinics.net/lists/linux-omap/msg118615.html
- *
- * You can override this later with
- * &tps { /delete-property/ ti,pmic-shutdown-controller; }
- * if you want to use RTC-only mode and made sure you are not affected
- * by the hardware problems. (Tip: double-check by performing a current
- * measurement after shutdown: it should be less than 1 mA.)
- */
- ti,pmic-shutdown-controller;
- interrupt-parent = <&intc>;
- interrupts = <7>; /* NMI */
-
- backlight {
- isel = <1>; /* 1 - ISET1, 2 ISET2 */
- fdim = <500>; /* TPS65217_BL_FDIM_500HZ */
- default-brightness = <50>;
- /* 1(on) - enable current sink, while initialization */
- /* 0(off) - disable current sink, while initialization */
- isink-en = <1>;
- };
-
- regulators {
- dcdc1_reg: regulator@0 {
- regulator-name = "vdds_dpr";
- regulator-always-on;
- };
-
- dcdc2_reg: regulator@1 {
- /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4