Merge branch 'for-5.10/core' into for-linus

- nonblocking read semantics fix for hid-debug
This commit is contained in:
Jiri Kosina 2020-10-15 20:37:01 +02:00
commit 62b31a0457
3576 changed files with 53480 additions and 24956 deletions

132
.mailmap
View File

@ -2,38 +2,44 @@
# This list is used by git-shortlog to fix a few botched name translations
# in the git archive, either because the author's full name was messed up
# and/or not always written the same way, making contributions from the
# same person appearing not to be so or badly displayed.
# 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".
#
# Please keep this list dictionary sorted.
#
# This comment is parsed by git-shortlog:
# repo-abbrev: /pub/scm/linux/kernel/git/
#
Aaron Durbin <adurbin@google.com>
Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.com>
Adrian Bunk <bunk@stusta.de>
Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com>
Adrian Bunk <bunk@stusta.de>
Alan Cox <alan@lxorguk.ukuu.org.uk>
Alan Cox <root@hraefn.swansea.linux.org.uk>
Aleksey Gorelov <aleksey_gorelov@phoenix.com>
Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@intel.com>
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@linaro.org>
Aleksey Gorelov <aleksey_gorelov@phoenix.com>
Alexander Lobakin <alobakin@pm.me> <alobakin@dlink.ru>
Alexander Lobakin <alobakin@pm.me> <alobakin@marvell.com>
Alexander Lobakin <alobakin@pm.me> <bloodyreaper@yandex.ru>
Alexandre Belloni <alexandre.belloni@bootlin.com> <alexandre.belloni@free-electrons.com>
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
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>
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@intel.com>
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@linaro.org>
Al Viro <viro@ftp.linux.org.uk>
Al Viro <viro@zenIV.linux.org.uk>
Andi Kleen <ak@linux.intel.com> <ak@suse.de>
Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>
Andreas Herrmann <aherrman@de.ibm.com>
Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
Andrew Morton <akpm@linux-foundation.org>
Andrew Murray <amurray@thegoodpenguin.co.uk> <andrew.murray@arm.com>
Andrew Murray <amurray@thegoodpenguin.co.uk> <amurray@embedded-bits.co.uk>
Andrew Murray <amurray@thegoodpenguin.co.uk> <andrew.murray@arm.com>
Andrew Vasquez <andrew.vasquez@qlogic.com>
Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
Andy Adamson <andros@citi.umich.edu>
Antoine Tenart <antoine.tenart@free-electrons.com>
Antonio Ospite <ao2@ao2.it> <ao2@amarulasolutions.com>
@ -43,40 +49,42 @@ Arnaud Patard <arnaud.patard@rtp-net.org>
Arnd Bergmann <arnd@arndb.de>
Axel Dyks <xl@xlsigned.net>
Axel Lin <axel.lin@gmail.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
Ben Gardner <bgardner@wabtec.com>
Ben M Cahill <ben.m.cahill@intel.com>
Björn Steinbrink <B.Steinbrink@gmx.de>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@free-electrons.com>
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon.dev@gmail.com>
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon@overkiz.com>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@free-electrons.com>
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
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>
Christoph Hellwig <hch@lst.de>
Christophe Ricard <christophe.ricard@gmail.com>
Christoph Hellwig <hch@lst.de>
Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp>
Daniel Borkmann <daniel@iogearbox.net> <dborkman@redhat.com>
Daniel Borkmann <daniel@iogearbox.net> <dborkmann@redhat.com>
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> <daniel.borkmann@tik.ee.ethz.ch>
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
Daniel Borkmann <daniel@iogearbox.net> <dborkmann@redhat.com>
Daniel Borkmann <daniel@iogearbox.net> <dborkman@redhat.com>
Daniel Borkmann <daniel@iogearbox.net> <dxchgb@gmail.com>
David Brownell <david-b@pacbell.net>
David Woodhouse <dwmw2@shinybook.infradead.org>
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@mips.com>
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@imgtec.com>
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>
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@mips.com>
<dev.kurt@vandijck-laurijssen.be> <kurt.van.dijck@eia.be>
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
Dmitry Safonov <0x7f454c46@gmail.com> <dima@arista.com>
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
Domen Puncer <domen@coderock.org>
Douglas Gilbert <dougg@torque.net>
Ed L. Cashin <ecashin@coraid.com>
@ -87,19 +95,22 @@ Felix Kuhling <fxkuehl@gmx.de>
Felix Moeller <felix@derklecks.de>
Filipe Lautert <filipe@icewall.org>
Franck Bui-Huu <vagabon.xyz@gmail.com>
Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sonymobile.com>
Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
Frank Zago <fzago@systemfabricworks.com>
Gao Xiang <xiang@kernel.org> <gaoxiang25@huawei.com>
Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <gerald.schaefer@de.ibm.com>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@de.ibm.com>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <gerald.schaefer@de.ibm.com>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@linux.vnet.ibm.com>
Greg Kroah-Hartman <greg@echidna.(none)>
Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman <greg@kroah.com>
Greg Kurz <groug@kaod.org> <gkurz@linux.vnet.ibm.com>
Gregory CLEMENT <gregory.clement@bootlin.com> <gregory.clement@free-electrons.com>
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>
@ -109,32 +120,33 @@ Henrik Rydberg <rydberg@bitmath.org>
Herbert Xu <herbert@gondor.apana.org.au>
Jacob Shin <Jacob.Shin@amd.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@google.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk.kim@samsung.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
Jakub Kicinski <kuba@kernel.org> <jakub.kicinski@netronome.com>
James Bottomley <jejb@mulgrave.(none)>
James Bottomley <jejb@titanic.il.steeleye.com>
James E Wilson <wilson@specifix.com>
James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
James Hogan <jhogan@kernel.org> <james@albanarts.com>
James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
James Ketrenos <jketreno@io.(none)>
Jan Glauber <jan.glauber@gmail.com> <jang@de.ibm.com>
Jan Glauber <jan.glauber@gmail.com> <jang@linux.vnet.ibm.com>
Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
Jayachandran C <c.jayachandran@gmail.com> <jayachandranc@netlogicmicro.com>
Jayachandran C <c.jayachandran@gmail.com> <jchandra@broadcom.com>
Jayachandran C <c.jayachandran@gmail.com> <jchandra@digeo.com>
Jayachandran C <c.jayachandran@gmail.com> <jnair@caviumnetworks.com>
Jean Tourrilhes <jt@hpl.hp.com>
<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>
Jean Tourrilhes <jt@hpl.hp.com>
Jeff Garzik <jgarzik@pretzel.yyz.us>
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
Jens Axboe <axboe@suse.de>
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Jiri Slaby <jirislaby@kernel.org> <jirislaby@gmail.com>
@ -158,30 +170,31 @@ Julien Thierry <julien.thierry.kdev@gmail.com> <julien.thierry@arm.com>
Kamil Konieczny <k.konieczny@samsung.com> <k.konieczny@partner.samsung.com>
Kay Sievers <kay.sievers@vrfy.org>
Kenneth W Chen <kenneth.w.chen@intel.com>
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
Koushik <raghavendra.koushik@neterion.com>
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com>
Leonid I Ananiev <leonid.i.ananiev@intel.com>
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
Leon Romanovsky <leon@kernel.org> <leonro@nvidia.com>
Linas Vepstas <linas@austin.ibm.com>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
Mark Brown <broonie@sirena.org.uk>
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@puri.sm>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
Mathieu Othacehe <m.othacehe@gmail.com>
Matthew Wilcox <willy@infradead.org> <matthew.r.wilcox@intel.com>
Matthew Wilcox <willy@infradead.org> <matthew@wil.cx>
@ -191,17 +204,17 @@ Matthew Wilcox <willy@infradead.org> <willy@debian.org>
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
Matthieu CASTET <castet.matthieu@free.fr>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@infradead.org>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@redhat.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <m.chehab@samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@osg.samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
Matt Ranostay <mranostay@gmail.com> Matthew Ranostay <mranostay@embeddedalley.com>
Matt Ranostay <mranostay@gmail.com> <matt.ranostay@intel.com>
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
Matt Redfearn <matt.redfearn@mips.com> <matt.redfearn@imgtec.com>
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>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@osg.samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@redhat.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <m.chehab@samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
Maxime Ripard <mripard@kernel.org> <maxime.ripard@bootlin.com>
Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
Mayuresh Janorkar <mayur@ti.com>
@ -233,13 +246,13 @@ Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Patrick Mochel <mochel@digitalimplant.org>
Paul Burton <paulburton@kernel.org> <paul.burton@imgtec.com>
Paul Burton <paulburton@kernel.org> <paul.burton@mips.com>
Paul E. McKenney <paulmck@kernel.org> <paul.mckenney@linaro.org>
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.ibm.com>
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.vnet.ibm.com>
Paul E. McKenney <paulmck@kernel.org> <paul.mckenney@linaro.org>
Paul E. McKenney <paulmck@kernel.org> <paulmck@us.ibm.com>
Peter A Jonsson <pj@ludd.ltu.se>
Peter Oruba <peter@oruba.de>
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>
Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
@ -252,23 +265,23 @@ Ralf Baechle <ralf@linux-mips.org>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
Rémi Denis-Courmont <rdenis@simphalempin.com>
Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com>
Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com>
Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org>
Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com>
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
Rudolf Marek <R.Marek@sh.cvut.cz>
Rui Saraiva <rmps@joel.ist.utl.pt>
Sachin P Sant <ssant@in.ibm.com>
Sarangdhar Joshi <spjoshi@codeaurora.org>
Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi>
Sam Ravnborg <sam@mars.ravnborg.org>
Santosh Shilimkar <ssantosh@kernel.org>
Santosh Shilimkar <santosh.shilimkar@oracle.org>
Santosh Shilimkar <ssantosh@kernel.org>
Sarangdhar Joshi <spjoshi@codeaurora.org>
Sascha Hauer <s.hauer@pengutronix.de>
S.Çağlar Onur <caglar@pardus.org.tr>
Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi>
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
Sebastian Reichel <sre@kernel.org> <sre@debian.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>
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com>
@ -279,18 +292,21 @@ Simon Arlott <simon@octiron.net> <simon@fire.lp0.eu>
Simon Kelley <simon@thekelleys.org.uk>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
Stephen Hemminger <shemminger@osdl.org>
Steve Wise <larrystevenwise@gmail.com> <swise@chelsio.com>
Steve Wise <larrystevenwise@gmail.com> <swise@opengridcomputing.com>
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Subhash Jadavani <subhashj@codeaurora.org>
Sudeep Holla <sudeep.holla@arm.com> Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Sumit Semwal <sumit.semwal@ti.com>
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Tejun Heo <htejun@gmail.com>
Thomas Graf <tgraf@suug.ch>
Thomas Pedersen <twp@codeaurora.org>
Tiezhu Yang <yangtiezhu@loongson.cn> <kernelpatch@126.com>
Todor Tomov <todor.too@gmail.com> <todor.tomov@linaro.org>
Tony Luck <tony.luck@intel.com>
TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
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>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Uwe Kleine-König <ukl@pengutronix.de>
@ -299,22 +315,16 @@ Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Vinod Koul <vkoul@kernel.org> <vinod.koul@intel.com>
Vinod Koul <vkoul@kernel.org> <vinod.koul@linux.intel.com>
Vinod Koul <vkoul@kernel.org> <vkoul@infradead.org>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
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@virtuozzo.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
WeiXiong Liao <gmpy.liaowx@gmail.com> <liaoweixiong@allwinnertech.com>
Will Deacon <will@kernel.org> <will.deacon@arm.com>
Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>
Wolfram Sang <wsa@kernel.org> <w.sang@pengutronix.de>
Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>
Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
Yusuke Goda <goda.yusuke@renesas.com>
Gustavo Padovan <gustavo@las.ic.unicamp.br>
Gustavo Padovan <padovan@profusion.mobi>
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
Steve Wise <larrystevenwise@gmail.com> <swise@chelsio.com>
Steve Wise <larrystevenwise@gmail.com> <swise@opengridcomputing.com>

View File

@ -43,7 +43,7 @@ Description: read only
This sysfs interface exposes the number of cores per chip
present in the system.
What: /sys/devices/hv_24x7/interface/cpumask
What: /sys/devices/hv_24x7/cpumask
Date: July 2020
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description: read only

View File

@ -202,6 +202,25 @@ Description:
functions. See the section named 'NVDIMM Root Device _DSMs' in
the ACPI specification.
What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle
Date: Apr, 2020
KernelVersion: v5.8
Contact: linux-nvdimm@lists.01.org
Description:
(RW) The Intel platform implementation of firmware activate
support exposes an option let the platform force idle devices in
the system over the activation event, or trust that the OS will
do it. The safe default is to let the platform force idle
devices since the kernel is already in a suspend state, and on
the chance that a driver does not properly quiesce bus-mastering
after a suspend callback the platform will handle it. However,
the activation might abort if, for example, platform firmware
determines that the activation time exceeds the max PCI-E
completion timeout. Since the platform does not know whether the
OS is running the activation from a suspend context it aborts,
but if the system owner trusts driver suspend callback to be
sufficient then 'firmware_activation_noidle' can be
enabled to bypass the activation abort.
What: /sys/bus/nd/devices/regionX/nfit/range_index
Date: Jun, 2015

View File

@ -0,0 +1,2 @@
The libnvdimm sub-system implements a common sysfs interface for
platform nvdimm resources. See Documentation/driver-api/nvdimm/.

View File

@ -0,0 +1,15 @@
What: /sys/bus/i2c/devices/xxx/fw_version
Date: Aug 2020
Contact: linux-input@vger.kernel.org
Description: Reports the firmware version provided by the touchscreen, for example "00_T6" on a EXC80H60
Access: Read
Valid values: Represented as string
What: /sys/bus/i2c/devices/xxx/model
Date: Aug 2020
Contact: linux-input@vger.kernel.org
Description: Reports the model identification provided by the touchscreen, for example "Orion_1320" on a EXC80H60
Access: Read
Valid values: Represented as string

View File

@ -229,7 +229,9 @@ Date: August 2017
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Do background GC agressively when set. When gc_urgent = 1,
background thread starts to do GC by given gc_urgent_sleep_time
interval. It is set to 0 by default.
interval. When gc_urgent = 2, F2FS will lower the bar of
checking idle in order to process outstanding discard commands
and GC a little bit aggressively. It is set to 0 by default.
What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time
Date: August 2017

View File

@ -49,7 +49,7 @@ checking of rcu_dereference() primitives:
is invoked by both RCU-sched readers and updaters.
srcu_dereference_check(p, c):
Use explicit check expression "c" along with
srcu_read_lock_held()(). This is useful in code that
srcu_read_lock_held(). This is useful in code that
is invoked by both SRCU readers and updaters.
rcu_dereference_raw(p):
Don't check. (Use sparingly, if at all.)

View File

@ -1274,6 +1274,10 @@ PAGE_SIZE multiple when read back.
Amount of memory used for storing in-kernel data
structures.
percpu
Amount of memory used for storing per-cpu kernel
data structures.
sock
Amount of memory used in network transmission buffers

View File

@ -1662,7 +1662,7 @@
98 block User-mode virtual block device
0 = /dev/ubda First user-mode block device
16 = /dev/udbb Second user-mode block device
16 = /dev/ubdb Second user-mode block device
...
Partitions are handled in the same way as for IDE

View File

@ -489,6 +489,9 @@ Files in /sys/fs/ext4/<devname>:
multiple of this tuning parameter if the stripe size is not set in the
ext4 superblock
mb_max_inode_prealloc
The maximum length of per-inode ext4_prealloc_space list.
mb_max_to_scan
The maximum number of extents the multiblock allocator will search to
find the best extent.
@ -529,21 +532,21 @@ Files in /sys/fs/ext4/<devname>:
Ioctls
======
There is some Ext4 specific functionality which can be accessed by applications
through the system call interfaces. The list of all Ext4 specific ioctls are
shown in the table below.
Ext4 implements various ioctls which can be used by applications to access
ext4-specific functionality. An incomplete list of these ioctls is shown in the
table below. This list includes truly ext4-specific ioctls (``EXT4_IOC_*``) as
well as ioctls that may have been ext4-specific originally but are now supported
by some other filesystem(s) too (``FS_IOC_*``).
Table of Ext4 specific ioctls
Table of Ext4 ioctls
EXT4_IOC_GETFLAGS
FS_IOC_GETFLAGS
Get additional attributes associated with inode. The ioctl argument is
an integer bitfield, with bit values described in ext4.h. This ioctl is
an alias for FS_IOC_GETFLAGS.
an integer bitfield, with bit values described in ext4.h.
EXT4_IOC_SETFLAGS
FS_IOC_SETFLAGS
Set additional attributes associated with inode. The ioctl argument is
an integer bitfield, with bit values described in ext4.h. This ioctl is
an alias for FS_IOC_SETFLAGS.
an integer bitfield, with bit values described in ext4.h.
EXT4_IOC_GETVERSION, EXT4_IOC_GETVERSION_OLD
Get the inode i_generation number stored for each inode. The

View File

@ -80,6 +80,10 @@ The possible values in this file are:
- The processor is not vulnerable.
* - KVM: Mitigation: Split huge pages
- Software changes mitigate this issue.
* - KVM: Mitigation: VMX unsupported
- KVM is not vulnerable because Virtual Machine Extensions (VMX) is not supported.
* - KVM: Mitigation: VMX disabled
- KVM is not vulnerable because Virtual Machine Extensions (VMX) is disabled.
* - KVM: Vulnerable
- The processor is vulnerable, but no mitigation enabled

View File

@ -724,7 +724,7 @@
memory region [offset, offset + size] for that kernel
image. If '@offset' is omitted, then a suitable offset
is selected automatically.
[KNL, x86_64] select a region under 4G first, and
[KNL, X86-64] Select a region under 4G first, and
fall back to reserve region above 4G when '@offset'
hasn't been specified.
See Documentation/admin-guide/kdump/kdump.rst for further details.
@ -737,14 +737,14 @@
Documentation/admin-guide/kdump/kdump.rst for an example.
crashkernel=size[KMG],high
[KNL, x86_64] range could be above 4G. Allow kernel
[KNL, X86-64] range could be above 4G. Allow kernel
to allocate physical memory region from top, so could
be above 4G if system have more than 4G ram installed.
Otherwise memory region will be allocated below 4G, if
available.
It will be ignored if crashkernel=X is specified.
crashkernel=size[KMG],low
[KNL, x86_64] range under 4G. When crashkernel=X,high
[KNL, X86-64] range under 4G. When crashkernel=X,high
is passed, kernel could allocate physical memory region
above 4G, that cause second kernel crash on system
that require some amount of low memory, e.g. swiotlb
@ -1233,8 +1233,7 @@
efi= [EFI]
Format: { "debug", "disable_early_pci_dma",
"nochunk", "noruntime", "nosoftreserve",
"novamap", "no_disable_early_pci_dma",
"old_map" }
"novamap", "no_disable_early_pci_dma" }
debug: enable misc debug output.
disable_early_pci_dma: disable the busmaster bit on all
PCI bridges while in the EFI boot stub.
@ -1251,8 +1250,6 @@
novamap: do not call SetVirtualAddressMap().
no_disable_early_pci_dma: Leave the busmaster bit set
on all PCI bridges while in the EFI boot stub
old_map [X86-64]: switch to the old ioremap-based EFI
runtime services mapping. [Needs CONFIG_X86_UV=y]
efi_no_storage_paranoia [EFI; X86]
Using this parameter you can use more than 50% of
@ -1427,7 +1424,7 @@
gamma= [HW,DRM]
gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
gart_fix_e820= [X86-64] disable the fix e820 for K8 GART
Format: off | on
default: on
@ -1814,7 +1811,7 @@
Format: 0 | 1
Default set by CONFIG_INIT_ON_FREE_DEFAULT_ON.
init_pkru= [x86] Specify the default memory protection keys rights
init_pkru= [X86] Specify the default memory protection keys rights
register contents for all processes. 0x55555554 by
default (disallow access to all but pkey 0). Can
override in debugfs after boot.
@ -1822,7 +1819,7 @@
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
Format: <irq>
int_pln_enable [x86] Enable power limit notification interrupt
int_pln_enable [X86] Enable power limit notification interrupt
integrity_audit=[IMA]
Format: { "0" | "1" }
@ -1840,7 +1837,7 @@
bypassed by not enabling DMAR with this option. In
this case, gfx device will use physical address for
DMA.
forcedac [x86_64]
forcedac [X86-64]
With this option iommu will not optimize to look
for io virtual address below 32-bit forcing dual
address cycle on pci bus for cards supporting greater
@ -1925,7 +1922,7 @@
strict regions from userspace.
relaxed
iommu= [x86]
iommu= [X86]
off
force
noforce
@ -1935,8 +1932,8 @@
merge
nomerge
soft
pt [x86]
nopt [x86]
pt [X86]
nopt [X86]
nobypass [PPC/POWERNV]
Disable IOMMU bypass, using IOMMU for PCI devices.
@ -2079,21 +2076,21 @@
iucv= [HW,NET]
ivrs_ioapic [HW,X86_64]
ivrs_ioapic [HW,X86-64]
Provide an override to the IOAPIC-ID<->DEVICE-ID
mapping provided in the IVRS ACPI table. For
example, to map IOAPIC-ID decimal 10 to
PCI device 00:14.0 write the parameter as:
ivrs_ioapic[10]=00:14.0
ivrs_hpet [HW,X86_64]
ivrs_hpet [HW,X86-64]
Provide an override to the HPET-ID<->DEVICE-ID
mapping provided in the IVRS ACPI table. For
example, to map HPET-ID decimal 0 to
PCI device 00:14.0 write the parameter as:
ivrs_hpet[0]=00:14.0
ivrs_acpihid [HW,X86_64]
ivrs_acpihid [HW,X86-64]
Provide an override to the ACPI-HID:UID<->DEVICE-ID
mapping provided in the IVRS ACPI table. For
example, to map UART-HID:UID AMD0020:0 to
@ -2370,7 +2367,7 @@
lapic [X86-32,APIC] Enable the local APIC even if BIOS
disabled it.
lapic= [x86,APIC] "notscdeadline" Do not use TSC deadline
lapic= [X86,APIC] "notscdeadline" Do not use TSC deadline
value for LAPIC timer one-shot implementation. Default
back to the programmable timer unit in the LAPIC.
@ -3188,12 +3185,12 @@
register save and restore. The kernel will only save
legacy floating-point registers on task switch.
nohugeiomap [KNL,x86,PPC] Disable kernel huge I/O mappings.
nohugeiomap [KNL,X86,PPC] Disable kernel huge I/O mappings.
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
[KNL,x86] Disable symmetric multithreading (SMT).
[KNL,X86] Disable symmetric multithreading (SMT).
nosmt=force: Force disable SMT, cannot be undone
via the sysfs control file.
@ -3955,7 +3952,7 @@
pt. [PARIDE]
See Documentation/admin-guide/blockdev/paride.rst.
pti= [X86_64] Control Page Table Isolation of user and
pti= [X86-64] Control Page Table Isolation of user and
kernel address spaces. Disabling this feature
removes hardening, but improves performance of
system calls and interrupts.
@ -3967,7 +3964,7 @@
Not specifying this option is equivalent to pti=auto.
nopti [X86_64]
nopti [X86-64]
Equivalent to pti=off
pty.legacy_count=

View File

@ -1434,7 +1434,7 @@ on the feature, restricting the viewing angles.
DYTC Lapmode sensor
------------------
-------------------
sysfs: dytc_lapmode

View File

@ -54,10 +54,13 @@ registered (see `below <status_attr_>`_).
Operation Modes
===============
``intel_pstate`` can operate in three different modes: in the active mode with
or without hardware-managed P-states support and in the passive mode. Which of
them will be in effect depends on what kernel command line options are used and
on the capabilities of the processor.
``intel_pstate`` can operate in two different modes, active or passive. In the
active mode, it uses its own internal performance scaling governor algorithm or
allows the hardware to do preformance scaling by itself, while in the passive
mode it responds to requests made by a generic ``CPUFreq`` governor implementing
a certain performance scaling algorithm. Which of them will be in effect
depends on what kernel command line options are used and on the capabilities of
the processor.
Active Mode
-----------
@ -194,10 +197,11 @@ This is the default operation mode of ``intel_pstate`` for processors without
hardware-managed P-states (HWP) support. It is always used if the
``intel_pstate=passive`` argument is passed to the kernel in the command line
regardless of whether or not the given processor supports HWP. [Note that the
``intel_pstate=no_hwp`` setting implies ``intel_pstate=passive`` if it is used
without ``intel_pstate=active``.] Like in the active mode without HWP support,
in this mode ``intel_pstate`` may refuse to work with processors that are not
recognized by it.
``intel_pstate=no_hwp`` setting causes the driver to start in the passive mode
if it is not combined with ``intel_pstate=active``.] Like in the active mode
without HWP support, in this mode ``intel_pstate`` may refuse to work with
processors that are not recognized by it if HWP is prevented from being enabled
through the kernel command line.
If the driver works in this mode, the ``scaling_driver`` policy attribute in
``sysfs`` for all ``CPUFreq`` policies contains the string "intel_cpufreq".
@ -318,10 +322,9 @@ manuals need to be consulted to get to it too.
For this reason, there is a list of supported processors in ``intel_pstate`` and
the driver initialization will fail if the detected processor is not in that
list, unless it supports the `HWP feature <Active Mode_>`_. [The interface to
obtain all of the information listed above is the same for all of the processors
supporting the HWP feature, which is why they all are supported by
``intel_pstate``.]
list, unless it supports the HWP feature. [The interface to obtain all of the
information listed above is the same for all of the processors supporting the
HWP feature, which is why ``intel_pstate`` works with all of them.]
User Space Interface in ``sysfs``
@ -425,22 +428,16 @@ argument is passed to the kernel in the command line.
as well as the per-policy ones) are then reset to their default
values, possibly depending on the target operation mode.]
That only is supported in some configurations, though (for example, if
the `HWP feature is enabled in the processor <Active Mode With HWP_>`_,
the operation mode of the driver cannot be changed), and if it is not
supported in the current configuration, writes to this attribute will
fail with an appropriate error.
``energy_efficiency``
This attribute is only present on platforms, which have CPUs matching
Kaby Lake or Coffee Lake desktop CPU model. By default
energy efficiency optimizations are disabled on these CPU models in HWP
mode by this driver. Enabling energy efficiency may limit maximum
operating frequency in both HWP and non HWP mode. In non HWP mode,
optimizations are done only in the turbo frequency range. In HWP mode,
optimizations are done in the entire frequency range. Setting this
attribute to "1" enables energy efficiency optimizations and setting
to "0" disables energy efficiency optimizations.
This attribute is only present on platforms with CPUs matching the Kaby
Lake or Coffee Lake desktop CPU model. By default, energy-efficiency
optimizations are disabled on these CPU models if HWP is enabled.
Enabling energy-efficiency optimizations may limit maximum operating
frequency with or without the HWP feature. With HWP enabled, the
optimizations are done only in the turbo frequency range. Without it,
they are done in the entire available frequency range. Setting this
attribute to "1" enables the energy-efficiency optimizations and setting
to "0" disables them.
Interpretation of Policy Attributes
-----------------------------------
@ -484,8 +481,8 @@ Next, the following policy attributes have special meaning if
policy for the time interval between the last two invocations of the
driver's utilization update callback by the CPU scheduler for that CPU.
One more policy attribute is present if the `HWP feature is enabled in the
processor <Active Mode With HWP_>`_:
One more policy attribute is present if the HWP feature is enabled in the
processor:
``base_frequency``
Shows the base frequency of the CPU. Any frequency above this will be
@ -526,11 +523,11 @@ on the following rules, regardless of the current operation mode of the driver:
3. The global and per-policy limits can be set independently.
If the `HWP feature is enabled in the processor <Active Mode With HWP_>`_, the
resulting effective values are written into its registers whenever the limits
change in order to request its internal P-state selection logic to always set
P-states within these limits. Otherwise, the limits are taken into account by
scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
In the `active mode with the HWP feature enabled <Active Mode With HWP_>`_, the
resulting effective values are written into hardware registers whenever the
limits change in order to request its internal P-state selection logic to always
set P-states within these limits. Otherwise, the limits are taken into account
by scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
every time before setting a new P-state for a CPU.
Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument
@ -541,12 +538,11 @@ at all and the only way to set the limits is by using the policy attributes.
Energy vs Performance Hints
---------------------------
If ``intel_pstate`` works in the `active mode with the HWP feature enabled
<Active Mode With HWP_>`_ in the processor, additional attributes are present
in every ``CPUFreq`` policy directory in ``sysfs``. They are intended to allow
user space to help ``intel_pstate`` to adjust the processor's internal P-state
selection logic by focusing it on performance or on energy-efficiency, or
somewhere between the two extremes:
If the hardware-managed P-states (HWP) is enabled in the processor, additional
attributes, intended to allow user space to help ``intel_pstate`` to adjust the
processor's internal P-state selection logic by focusing it on performance or on
energy-efficiency, or somewhere between the two extremes, are present in every
``CPUFreq`` policy directory in ``sysfs``. They are :
``energy_performance_preference``
Current value of the energy vs performance hint for the given policy
@ -568,8 +564,8 @@ Energy-Performance Preference (EPP) knob (if supported) or its
Energy-Performance Bias (EPB) knob. It is also possible to write a positive
integer value between 0 to 255, if the EPP feature is present. If the EPP
feature is not present, writing integer value to this attribute is not
supported. In this case, user can use
"/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface.
supported. In this case, user can use the
"/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface.
[Note that tasks may by migrated from one CPU to another by the scheduler's
load-balancing algorithm and if different energy vs performance hints are
@ -650,12 +646,14 @@ of them have to be prepended with the ``intel_pstate=`` prefix.
Do not register ``intel_pstate`` as the scaling driver even if the
processor is supported by it.
``active``
Register ``intel_pstate`` in the `active mode <Active Mode_>`_ to start
with.
``passive``
Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to
start with.
This option implies the ``no_hwp`` one described below.
``force``
Register ``intel_pstate`` as the scaling driver instead of
``acpi-cpufreq`` even if the latter is preferred on the given system.
@ -670,13 +668,12 @@ of them have to be prepended with the ``intel_pstate=`` prefix.
driver is used instead of ``acpi-cpufreq``.
``no_hwp``
Do not enable the `hardware-managed P-states (HWP) feature
<Active Mode With HWP_>`_ even if it is supported by the processor.
Do not enable the hardware-managed P-states (HWP) feature even if it is
supported by the processor.
``hwp_only``
Register ``intel_pstate`` as the scaling driver only if the
`hardware-managed P-states (HWP) feature <Active Mode With HWP_>`_ is
supported by the processor.
hardware-managed P-states (HWP) feature is supported by the processor.
``support_acpi_ppc``
Take ACPI ``_PPC`` performance limits into account.

View File

@ -164,7 +164,8 @@ core_pattern
%s signal number
%t UNIX time of dump
%h hostname
%e executable filename (may be shortened)
%e executable filename (may be shortened, could be changed by prctl etc)
%f executable filename
%E executable path
%c maximum size of core file by resource limit RLIMIT_CORE
%<OTHER> both are dropped

View File

@ -119,6 +119,21 @@ all zones are compacted such that free memory is available in contiguous
blocks where possible. This can be important for example in the allocation of
huge pages although processes will also directly compact memory as required.
compaction_proactiveness
========================
This tunable takes a value in the range [0, 100] with a default value of
20. This tunable determines how aggressively compaction is done in the
background. Setting it to 0 disables proactive compaction.
Note that compaction has a non-trivial system-wide impact as pages
belonging to different processes are moved around, which could also lead
to latency spikes in unsuspecting applications. The kernel employs
various heuristics to avoid wasting CPU cycles if it detects that
proactive compaction is not being effective.
Be careful when setting it to extreme values like 100, as that may
cause excessive background compaction activity.
compact_unevictable_allowed
===========================

View File

@ -125,6 +125,9 @@ stable kernels.
| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Marvell | ARM-MMU-500 | #582743 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+

View File

@ -246,17 +246,6 @@ program is loaded the kernel will print warning message, so
this helper is only useful for experiments and prototypes.
Tracing BPF programs are root only.
Q: bpf_trace_printk() helper warning
------------------------------------
Q: When bpf_trace_printk() helper is used the kernel prints nasty
warning message. Why is that?
A: This is done to nudge program authors into better interfaces when
programs need to pass data to user space. Like bpf_perf_event_output()
can be used to efficiently stream data via perf ring buffer.
BPF maps can be used for asynchronous data sharing between kernel
and user space. bpf_trace_printk() should only be used for debugging.
Q: New functionality via kernel modules?
----------------------------------------
Q: Can BPF functionality such as new program or map types, new

View File

@ -36,6 +36,12 @@ Two sets of Questions and Answers (Q&A) are maintained.
bpf_devel_QA
Helper functions
================
* `bpf-helpers(7)`_ maintains a list of helpers available to eBPF programs.
Program types
=============
@ -79,4 +85,5 @@ Other
.. _networking-filter: ../networking/filter.rst
.. _man-pages: https://www.kernel.org/doc/man-pages/
.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
.. _bpf-helpers(7): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
.. _BPF and XDP Reference Guide: https://docs.cilium.io/en/latest/bpf/

View File

@ -557,7 +557,7 @@ phase. Currently, the capabilities are any of::
CDC_DRIVE_STATUS /* driver implements drive status */
The capability flag is declared *const*, to prevent drivers from
accidentally tampering with the contents. The capability fags actually
accidentally tampering with the contents. The capability flags actually
inform `cdrom.c` of what the driver can do. If the drive found
by the driver does not have the capability, is can be masked out by
the *cdrom_device_info* variable *mask*. For instance, the SCSI CD-ROM
@ -736,7 +736,7 @@ Description of routines in `cdrom.c`
Only a few routines in `cdrom.c` are exported to the drivers. In this
new section we will discuss these, as well as the functions that `take
over' the CD-ROM interface to the kernel. The header file belonging
over` the CD-ROM interface to the kernel. The header file belonging
to `cdrom.c` is called `cdrom.h`. Formerly, some of the contents of this
file were placed in the file `ucdrom.h`, but this file has now been
merged back into `cdrom.h`.

View File

@ -20,48 +20,48 @@ only ID allocation, and as a result is much more memory-efficient.
IDR usage
=========
Start by initialising an IDR, either with :c:func:`DEFINE_IDR`
for statically allocated IDRs or :c:func:`idr_init` for dynamically
Start by initialising an IDR, either with DEFINE_IDR()
for statically allocated IDRs or idr_init() for dynamically
allocated IDRs.
You can call :c:func:`idr_alloc` to allocate an unused ID. Look up
the pointer you associated with the ID by calling :c:func:`idr_find`
and free the ID by calling :c:func:`idr_remove`.
You can call idr_alloc() to allocate an unused ID. Look up
the pointer you associated with the ID by calling idr_find()
and free the ID by calling idr_remove().
If you need to change the pointer associated with an ID, you can call
:c:func:`idr_replace`. One common reason to do this is to reserve an
idr_replace(). One common reason to do this is to reserve an
ID by passing a ``NULL`` pointer to the allocation function; initialise the
object with the reserved ID and finally insert the initialised object
into the IDR.
Some users need to allocate IDs larger than ``INT_MAX``. So far all of
these users have been content with a ``UINT_MAX`` limit, and they use
:c:func:`idr_alloc_u32`. If you need IDs that will not fit in a u32,
idr_alloc_u32(). If you need IDs that will not fit in a u32,
we will work with you to address your needs.
If you need to allocate IDs sequentially, you can use
:c:func:`idr_alloc_cyclic`. The IDR becomes less efficient when dealing
idr_alloc_cyclic(). The IDR becomes less efficient when dealing
with larger IDs, so using this function comes at a slight cost.
To perform an action on all pointers used by the IDR, you can
either use the callback-based :c:func:`idr_for_each` or the
iterator-style :c:func:`idr_for_each_entry`. You may need to use
:c:func:`idr_for_each_entry_continue` to continue an iteration. You can
also use :c:func:`idr_get_next` if the iterator doesn't fit your needs.
either use the callback-based idr_for_each() or the
iterator-style idr_for_each_entry(). You may need to use
idr_for_each_entry_continue() to continue an iteration. You can
also use idr_get_next() if the iterator doesn't fit your needs.
When you have finished using an IDR, you can call :c:func:`idr_destroy`
When you have finished using an IDR, you can call idr_destroy()
to release the memory used by the IDR. This will not free the objects
pointed to from the IDR; if you want to do that, use one of the iterators
to do it.
You can use :c:func:`idr_is_empty` to find out whether there are any
You can use idr_is_empty() to find out whether there are any
IDs currently allocated.
If you need to take a lock while allocating a new ID from the IDR,
you may need to pass a restrictive set of GFP flags, which can lead
to the IDR being unable to allocate memory. To work around this,
you can call :c:func:`idr_preload` before taking the lock, and then
:c:func:`idr_preload_end` after the allocation.
you can call idr_preload() before taking the lock, and then
idr_preload_end() after the allocation.
.. kernel-doc:: include/linux/idr.h
:doc: idr sync

View File

@ -175,13 +175,20 @@ For example, to check drivers/net/wireless/ one may write::
make coccicheck M=drivers/net/wireless/
To apply Coccinelle on a file basis, instead of a directory basis, the
following command may be used::
C variable is used by the makefile to select which files to work with.
This variable can be used to run scripts for the entire kernel, a
specific directory, or for a single file.
make C=1 CHECK="scripts/coccicheck"
For example, to check drivers/bluetooth/bfusb.c, the value 1 is
passed to the C variable to check files that make considers
need to be compiled.::
To check only newly edited code, use the value 2 for the C flag, i.e.::
make C=1 CHECK=scripts/coccicheck drivers/bluetooth/bfusb.o
make C=2 CHECK="scripts/coccicheck"
The value 2 is passed to the C variable to check files regardless of
whether they need to be compiled or not.::
make C=2 CHECK=scripts/coccicheck drivers/bluetooth/bfusb.o
In these modes, which work on a file basis, there is no information
about semantic patches displayed, and no commit message proposed.

View File

@ -316,7 +316,7 @@ driver as a loadable kernel module kgdbwait will not do anything.
Kernel parameter: ``kgdbcon``
-----------------------------
The ``kgdbcon`` feature allows you to see :c:func:`printk` messages inside gdb
The ``kgdbcon`` feature allows you to see printk() messages inside gdb
while gdb is connected to the kernel. Kdb does not make use of the kgdbcon
feature.
@ -432,7 +432,7 @@ This is a quick example of how to use kdb.
``ps`` Displays only the active processes
``ps A`` Shows all the processes
``summary`` Shows kernel version info and memory usage
``bt`` Get a backtrace of the current process using :c:func:`dump_stack`
``bt`` Get a backtrace of the current process using dump_stack()
``dmesg`` View the kernel syslog buffer
``go`` Continue the system
=========== =================================================================
@ -724,7 +724,7 @@ The kernel debugger is organized into a number of components:
The arch-specific portion implements:
- contains an arch-specific trap catcher which invokes
:c:func:`kgdb_handle_exception` to start kgdb about doing its work
kgdb_handle_exception() to start kgdb about doing its work
- translation to and from gdb specific packet format to :c:type:`pt_regs`
@ -769,7 +769,7 @@ The kernel debugger is organized into a number of components:
config. Later run ``modprobe kdb_hello`` and the next time you
enter the kdb shell, you can run the ``hello`` command.
- The implementation for :c:func:`kdb_printf` which emits messages directly
- The implementation for kdb_printf() which emits messages directly
to I/O drivers, bypassing the kernel log.
- SW / HW breakpoint management for the kdb shell
@ -875,7 +875,7 @@ kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration.
The core polled keyboard driver for PS/2 type keyboards is in
``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core
when kgdboc populates the callback in the array called
:c:type:`kdb_poll_funcs[]`. The :c:func:`kdb_get_kbd_char` is the top-level
:c:type:`kdb_poll_funcs[]`. The kdb_get_kbd_char() is the top-level
function which polls hardware for single character input.
kgdboc and kms
@ -887,10 +887,10 @@ that you have a video driver which has a frame buffer console and atomic
kernel mode setting support.
Every time the kernel debugger is entered it calls
:c:func:`kgdboc_pre_exp_handler` which in turn calls :c:func:`con_debug_enter`
kgdboc_pre_exp_handler() which in turn calls con_debug_enter()
in the virtual console layer. On resuming kernel execution, the kernel
debugger calls :c:func:`kgdboc_post_exp_handler` which in turn calls
:c:func:`con_debug_leave`.
debugger calls kgdboc_post_exp_handler() which in turn calls
con_debug_leave().
Any video driver that wants to be compatible with the kernel debugger
and the atomic kms callbacks must implement the ``mode_set_base_atomic``,

View File

@ -67,9 +67,9 @@ patternProperties:
compatible:
items:
- enum:
- arm,integrator-ap-syscon
- arm,integrator-cp-syscon
- arm,integrator-sp-syscon
- arm,integrator-ap-syscon
- arm,integrator-cp-syscon
- arm,integrator-sp-syscon
- const: syscon
reg:
maxItems: 1

View File

@ -55,20 +55,20 @@ properties:
compatible:
oneOf:
- items:
- const: arm,realview-eb-soc
- const: simple-bus
- const: arm,realview-eb-soc
- const: simple-bus
- items:
- const: arm,realview-pb1176-soc
- const: simple-bus
- const: arm,realview-pb1176-soc
- const: simple-bus
- items:
- const: arm,realview-pb11mp-soc
- const: simple-bus
- const: arm,realview-pb11mp-soc
- const: simple-bus
- items:
- const: arm,realview-pba8-soc
- const: simple-bus
- const: arm,realview-pba8-soc
- const: simple-bus
- items:
- const: arm,realview-pbx-soc
- const: simple-bus
- const: arm,realview-pbx-soc
- const: simple-bus
patternProperties:
"^.*syscon@[0-9a-f]+$":
@ -79,35 +79,35 @@ properties:
compatible:
oneOf:
- items:
- const: arm,realview-eb11mp-revb-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- const: arm,realview-eb11mp-revb-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb11mp-revc-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- const: arm,realview-eb11mp-revc-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb1176-syscon
- const: syscon
- const: simple-mfd
- const: arm,realview-pb1176-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb11mp-syscon
- const: syscon
- const: simple-mfd
- const: arm,realview-pb11mp-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pba8-syscon
- const: syscon
- const: simple-mfd
- const: arm,realview-pba8-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pbx-syscon
- const: syscon
- const: simple-mfd
- const: arm,realview-pbx-syscon
- const: syscon
- const: simple-mfd
required:
- compatible

View File

@ -165,10 +165,10 @@ patternProperties:
compatible:
oneOf:
- items:
- enum:
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- const: simple-bus
- enum:
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- const: simple-bus
- const: simple-bus
motherboard:
type: object
@ -186,8 +186,8 @@ patternProperties:
compatible:
items:
- enum:
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- const: simple-bus
arm,v2m-memory-map:
description: This describes the memory map type.

View File

@ -15,7 +15,7 @@ properties:
compatible:
items:
- enum:
- brcm,bcm28155-ap
- brcm,bcm28155-ap
- const: brcm,bcm11351
...

View File

@ -15,7 +15,7 @@ properties:
compatible:
items:
- enum:
- brcm,bcm21664-garnet
- brcm,bcm21664-garnet
- const: brcm,bcm21664
...

View File

@ -15,7 +15,7 @@ properties:
compatible:
items:
- enum:
- brcm,bcm23550-sparrow
- brcm,bcm23550-sparrow
- const: brcm,bcm23550
...

View File

@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Cygnus device tree bindings
maintainers:
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
properties:
$nodename:
@ -16,14 +16,14 @@ properties:
compatible:
items:
- enum:
- brcm,bcm11300
- brcm,bcm11320
- brcm,bcm11350
- brcm,bcm11360
- brcm,bcm58300
- brcm,bcm58302
- brcm,bcm58303
- brcm,bcm58305
- brcm,bcm11300
- brcm,bcm11320
- brcm,bcm11350
- brcm,bcm11360
- brcm,bcm58300
- brcm,bcm58302
- brcm,bcm58303
- brcm,bcm58305
- const: brcm,cygnus
...

View File

@ -21,7 +21,7 @@ properties:
compatible:
items:
- enum:
- ubnt,unifi-switch8
- ubnt,unifi-switch8
- const: brcm,bcm53342
- const: brcm,hr2

View File

@ -16,8 +16,8 @@ properties:
compatible:
items:
- enum:
- brcm,ns2-svk
- brcm,ns2-xmc
- brcm,ns2-svk
- brcm,ns2-xmc
- const: brcm,ns2
...

View File

@ -24,13 +24,13 @@ properties:
compatible:
items:
- enum:
- brcm,bcm58522
- brcm,bcm58525
- brcm,bcm58535
- brcm,bcm58622
- brcm,bcm58623
- brcm,bcm58625
- brcm,bcm88312
- brcm,bcm58522
- brcm,bcm58525
- brcm,bcm58535
- brcm,bcm58622
- brcm,bcm58623
- brcm,bcm58625
- brcm,bcm88312
- const: brcm,nsp
...

View File

@ -16,9 +16,9 @@ properties:
compatible:
items:
- enum:
- brcm,bcm958742k
- brcm,bcm958742t
- brcm,bcm958802a802x
- brcm,bcm958742k
- brcm,bcm958742t
- brcm,bcm958802a802x
- const: brcm,stingray
...

View File

@ -15,8 +15,8 @@ properties:
compatible:
items:
- enum:
- brcm,vulcan-eval
- cavium,thunderx2-cn9900
- brcm,vulcan-eval
- cavium,thunderx2-cn9900
- const: brcm,vulcan-soc
...

View File

@ -10,6 +10,15 @@ maintainers:
- Eric Anholt <eric@anholt.net>
- Stefan Wahren <wahrenst@gmx.net>
select:
properties:
compatible:
contains:
const: raspberrypi,bcm2835-firmware
required:
- compatible
properties:
compatible:
items:

View File

@ -82,12 +82,12 @@ properties:
compatible:
oneOf:
- items:
- const: arm,coresight-cti
- const: arm,primecell
- const: arm,coresight-cti
- const: arm,primecell
- items:
- const: arm,coresight-cti-v8-arch
- const: arm,coresight-cti
- const: arm,primecell
- const: arm,coresight-cti-v8-arch
- const: arm,coresight-cti
- const: arm,primecell
reg:
maxItems: 1
@ -191,16 +191,16 @@ patternProperties:
anyOf:
- required:
- arm,trig-in-sigs
- arm,trig-in-sigs
- required:
- arm,trig-out-sigs
- arm,trig-out-sigs
oneOf:
- required:
- arm,trig-conn-name
- arm,trig-conn-name
- required:
- cpu
- cpu
- required:
- arm,cs-dev-assoc
- arm,cs-dev-assoc
required:
- reg

View File

@ -330,8 +330,8 @@ if:
- enable-method
then:
required:
- secondary-boot-reg
required:
- secondary-boot-reg
required:
- device_type

View File

@ -273,8 +273,8 @@ properties:
- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board
- kontron,imx6ull-n6411-som # Kontron N6411 SOM
- myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board
- toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / Bluetooth Module on Colibri Evaluation Board
- toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Eval Board
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT Module on Colibri Eval Board
- const: fsl,imx6ull
- description: Kontron N6411 S Board
@ -312,9 +312,12 @@ properties:
- toradex,colibri-imx7d # Colibri iMX7 Dual Module
- toradex,colibri-imx7d-aster # Colibri iMX7 Dual Module on Aster Carrier Board
- toradex,colibri-imx7d-emmc # Colibri iMX7 Dual 1GB (eMMC) Module
- toradex,colibri-imx7d-emmc-aster # Colibri iMX7 Dual 1GB (eMMC) Module on Aster Carrier Board
- toradex,colibri-imx7d-emmc-eval-v3 # Colibri iMX7 Dual 1GB (eMMC) Module on Colibri Evaluation Board V3
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on Colibri Evaluation Board V3
- toradex,colibri-imx7d-emmc-aster # Colibri iMX7 Dual 1GB (eMMC) Module on
# Aster Carrier Board
- toradex,colibri-imx7d-emmc-eval-v3 # Colibri iMX7 Dual 1GB (eMMC) Module on
# Colibri Evaluation Board V3
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on
# Colibri Evaluation Board V3
- tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM
- zii,imx7d-rmu2 # ZII RMU2 Board
- zii,imx7d-rpu2 # ZII RPU2 Board

View File

@ -14,6 +14,6 @@ properties:
compatible:
items:
- enum:
- intel,keembay-evm
- intel,keembay-evm
- const: intel,keembay
...

View File

@ -0,0 +1,44 @@
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/keystone/ti,k3-sci-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common K3 TI-SCI bindings
maintainers:
- Nishanth Menon <nm@ti.com>
description: |
The TI K3 family of SoCs usually have a central System Controller Processor
that is responsible for managing various SoC-level resources like clocks,
resets, interrupts etc. The communication with that processor is performed
through the TI-SCI protocol.
Each specific device management node like a clock controller node, a reset
controller node or an interrupt-controller node should define a common set
of properties that enables them to implement the corresponding functionality
over the TI-SCI protocol. The following are some of the common properties
needed by such individual nodes. The required properties for each device
management node is defined in the respective binding.
properties:
ti,sci:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Should be a phandle to the TI-SCI System Controller node
ti,sci-dev-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Should contain the TI-SCI device id corresponding to the device. Please
refer to the corresponding System Controller documentation for valid
values for the desired device.
ti,sci-proc-ids:
description: Should contain a single tuple of <proc_id host_id>.
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- description: TI-SCI processor id for the remote processor device
- description: TI-SCI host id to which processor control ownership
should be transferred to

View File

@ -17,22 +17,22 @@ properties:
compatible:
oneOf:
- items:
- enum:
- mediatek,mt2701-pericfg
- mediatek,mt2712-pericfg
- mediatek,mt6765-pericfg
- mediatek,mt7622-pericfg
- mediatek,mt7629-pericfg
- mediatek,mt8135-pericfg
- mediatek,mt8173-pericfg
- mediatek,mt8183-pericfg
- mediatek,mt8516-pericfg
- const: syscon
- enum:
- mediatek,mt2701-pericfg
- mediatek,mt2712-pericfg
- mediatek,mt6765-pericfg
- mediatek,mt7622-pericfg
- mediatek,mt7629-pericfg
- mediatek,mt8135-pericfg
- mediatek,mt8173-pericfg
- mediatek,mt8183-pericfg
- mediatek,mt8516-pericfg
- const: syscon
- items:
# Special case for mt7623 for backward compatibility
- const: mediatek,mt7623-pericfg
- const: mediatek,mt2701-pericfg
- const: syscon
# Special case for mt7623 for backward compatibility
- const: mediatek,mt7623-pericfg
- const: mediatek,mt2701-pericfg
- const: syscon
reg:
maxItems: 1

View File

@ -19,7 +19,7 @@ description: |
reported to the APB terminator (APB Errors Handler Block).
allOf:
- $ref: /schemas/simple-bus.yaml#
- $ref: /schemas/simple-bus.yaml#
properties:
compatible:

View File

@ -23,7 +23,7 @@ description: |
accessible by means of the Baikal-T1 System Controller.
allOf:
- $ref: /schemas/simple-bus.yaml#
- $ref: /schemas/simple-bus.yaml#
properties:
compatible:

View File

@ -1,125 +0,0 @@
Binding for IDT VersaClock 5,6 programmable i2c clock generators.
The IDT VersaClock 5 and VersaClock 6 are programmable i2c clock
generators providing from 3 to 12 output clocks.
==I2C device node==
Required properties:
- compatible: shall be one of
"idt,5p49v5923"
"idt,5p49v5925"
"idt,5p49v5933"
"idt,5p49v5935"
"idt,5p49v6901"
"idt,5p49v6965"
- reg: i2c device address, shall be 0x68 or 0x6a.
- #clock-cells: from common clock binding; shall be set to 1.
- clocks: from common clock binding; list of parent clock handles,
- 5p49v5923 and
5p49v5925 and
5p49v6901: (required) either or both of XTAL or CLKIN
reference clock.
- 5p49v5933 and
- 5p49v5935: (optional) property not present (internal
Xtal used) or CLKIN reference
clock.
- clock-names: from common clock binding; clock input names, can be
- 5p49v5923 and
5p49v5925 and
5p49v6901: (required) either or both of "xin", "clkin".
- 5p49v5933 and
- 5p49v5935: (optional) property not present or "clkin".
For all output ports, a corresponding, optional child node named OUT1,
OUT2, etc. can represent a each output, and the node can be used to
specify the following:
- itd,mode: can be one of the following:
- VC5_LVPECL
- VC5_CMOS
- VC5_HCSL33
- VC5_LVDS
- VC5_CMOS2
- VC5_CMOSD
- VC5_HCSL25
- idt,voltage-microvolts: can be one of the following
- 1800000
- 2500000
- 3300000
- idt,slew-percent: Percent of normal, can be one of
- 80
- 85
- 90
- 100
==Mapping between clock specifier and physical pins==
When referencing the provided clock in the DT using phandle and
clock specifier, the following mapping applies:
5P49V5923:
0 -- OUT0_SEL_I2CB
1 -- OUT1
2 -- OUT2
5P49V5933:
0 -- OUT0_SEL_I2CB
1 -- OUT1
2 -- OUT4
5P49V5925 and
5P49V5935:
0 -- OUT0_SEL_I2CB
1 -- OUT1
2 -- OUT2
3 -- OUT3
4 -- OUT4
5P49V6901:
0 -- OUT0_SEL_I2CB
1 -- OUT1
2 -- OUT2
3 -- OUT3
4 -- OUT4
==Example==
/* 25MHz reference crystal */
ref25: ref25m {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
};
i2c-master-node {
/* IDT 5P49V5923 i2c clock generator */
vc5: clock-generator@6a {
compatible = "idt,5p49v5923";
reg = <0x6a>;
#clock-cells = <1>;
/* Connect XIN input to 25MHz reference */
clocks = <&ref25m>;
clock-names = "xin";
OUT1 {
itd,mode = <VC5_CMOS>;
idt,voltage-microvolts = <1800000>;
idt,slew-percent = <80>;
};
OUT2 {
...
};
...
};
};
/* Consumer referencing the 5P49V5923 pin OUT1 */
consumer {
...
clocks = <&vc5 1>;
...
}

View File

@ -0,0 +1,154 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/idt,versaclock5.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Binding for IDT VersaClock 5 and 6 programmable I2C clock generators
description: |
The IDT VersaClock 5 and VersaClock 6 are programmable I2C
clock generators providing from 3 to 12 output clocks.
When referencing the provided clock in the DT using phandle and clock
specifier, the following mapping applies:
- 5P49V5923:
0 -- OUT0_SEL_I2CB
1 -- OUT1
2 -- OUT2
- 5P49V5933:
0 -- OUT0_SEL_I2CB
1 -- OUT1
2 -- OUT4
- other parts:
0 -- OUT0_SEL_I2CB
1 -- OUT1
2 -- OUT2
3 -- OUT3
4 -- OUT4
maintainers:
- Luca Ceresoli <luca@lucaceresoli.net>
properties:
compatible:
enum:
- idt,5p49v5923
- idt,5p49v5925
- idt,5p49v5933
- idt,5p49v5935
- idt,5p49v6901
- idt,5p49v6965
reg:
description: I2C device address
enum: [ 0x68, 0x6a ]
'#clock-cells':
const: 1
patternProperties:
"^OUT[1-4]$":
type: object
description:
Description of one of the outputs (OUT1..OUT4). See "Clock1 Output
Configuration" in the Versaclock 5/6/6E Family Register Description
and Programming Guide.
properties:
idt,mode:
description:
The output drive mode. Values defined in dt-bindings/clk/versaclock.h
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 6
idt,voltage-microvolt:
description: The output drive voltage.
enum: [ 1800000, 2500000, 3300000 ]
idt,slew-percent:
description: The Slew rate control for CMOS single-ended.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 80, 85, 90, 100 ]
required:
- compatible
- reg
- '#clock-cells'
allOf:
- if:
properties:
compatible:
enum:
- idt,5p49v5933
- idt,5p49v5935
then:
# Devices with builtin crystal + optional external input
properties:
clock-names:
const: clkin
clocks:
maxItems: 1
else:
# Devices without builtin crystal
properties:
clock-names:
minItems: 1
maxItems: 2
items:
enum: [ xin, clkin ]
clocks:
minItems: 1
maxItems: 2
required:
- clock-names
- clocks
examples:
- |
#include <dt-bindings/clk/versaclock.h>
/* 25MHz reference crystal */
ref25: ref25m {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
};
i2c@0 {
reg = <0x0 0x100>;
#address-cells = <1>;
#size-cells = <0>;
/* IDT 5P49V5923 I2C clock generator */
vc5: clock-generator@6a {
compatible = "idt,5p49v5923";
reg = <0x6a>;
#clock-cells = <1>;
/* Connect XIN input to 25MHz reference */
clocks = <&ref25m>;
clock-names = "xin";
OUT1 {
idt,drive-mode = <VC5_CMOSD>;
idt,voltage-microvolts = <1800000>;
idt,slew-percent = <80>;
};
OUT4 {
idt,drive-mode = <VC5_LVDS>;
};
};
};
/* Consumer referencing the 5P49V5923 pin OUT1 */
consumer {
/* ... */
clocks = <&vc5 1>;
/* ... */
};
...

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Clock bindings for Freescale i.MX23
maintainers:
- Shawn Guo <shawn.guo@linaro.org>
- Shawn Guo <shawnguo@kernel.org>
description: |
The clock consumer should specify the desired clock by having the clock

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Clock bindings for Freescale i.MX28
maintainers:
- Shawn Guo <shawn.guo@linaro.org>
- Shawn Guo <shawnguo@kernel.org>
description: |
The clock consumer should specify the desired clock by having the clock

View File

@ -47,12 +47,12 @@ properties:
compatible:
items:
- enum:
- ingenic,jz4740-cgu
- ingenic,jz4725b-cgu
- ingenic,jz4770-cgu
- ingenic,jz4780-cgu
- ingenic,x1000-cgu
- ingenic,x1830-cgu
- ingenic,jz4740-cgu
- ingenic,jz4725b-cgu
- ingenic,jz4770-cgu
- ingenic,jz4780-cgu
- ingenic,x1000-cgu
- ingenic,x1830-cgu
- const: simple-mfd
minItems: 1
@ -68,8 +68,8 @@ properties:
items:
- const: ext
- enum:
- rtc
- osc32k # Different name, same clock
- rtc
- osc32k # Different name, same clock
assigned-clocks:
minItems: 1

View File

@ -1,23 +1,31 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,sdm845-gpucc.yaml#
$id: http://devicetree.org/schemas/clock/qcom,gpucc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Graphics Clock & Reset Controller Binding for SDM845
title: Qualcomm Graphics Clock & Reset Controller Binding
maintainers:
- Taniya Das <tdas@codeaurora.org>
description: |
Qualcomm graphics clock control module which supports the clocks, resets and
power domains on SDM845.
power domains on SDM845/SC7180/SM8150/SM8250.
See also dt-bindings/clock/qcom,gpucc-sdm845.h.
See also:
dt-bindings/clock/qcom,gpucc-sdm845.h
dt-bindings/clock/qcom,gpucc-sc7180.h
dt-bindings/clock/qcom,gpucc-sm8150.h
dt-bindings/clock/qcom,gpucc-sm8250.h
properties:
compatible:
const: qcom,sdm845-gpucc
enum:
- qcom,sdm845-gpucc
- qcom,sc7180-gpucc
- qcom,sm8150-gpucc
- qcom,sm8250-gpucc
clocks:
items:

View File

@ -65,7 +65,7 @@ properties:
protected-clocks:
description:
Protected clock specifier list as per common clock binding
Protected clock specifier list as per common clock binding
vdd-gfx-supply:
description:

View File

@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,kryocc.yaml#
$id: http://devicetree.org/schemas/clock/qcom,msm8996-apcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm clock controller for MSM8996 CPUs
@ -46,11 +46,9 @@ required:
additionalProperties: false
examples:
# Example for msm8996
- |
kryocc: clock-controller@6400000 {
compatible = "qcom,msm8996-apcc";
reg = <0x6400000 0x90000>;
#clock-cells = <1>;
};
...
};

View File

@ -1,74 +0,0 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,sc7180-gpucc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Graphics Clock & Reset Controller Binding for SC7180
maintainers:
- Taniya Das <tdas@codeaurora.org>
description: |
Qualcomm graphics clock control module which supports the clocks, resets and
power domains on SC7180.
See also dt-bindings/clock/qcom,gpucc-sc7180.h.
properties:
compatible:
const: qcom,sc7180-gpucc
clocks:
items:
- description: Board XO source
- description: GPLL0 main branch source
- description: GPLL0 div branch source
clock-names:
items:
- const: bi_tcxo
- const: gcc_gpu_gpll0_clk_src
- const: gcc_gpu_gpll0_div_clk_src
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sc7180.h>
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@5090000 {
compatible = "qcom,sc7180-gpucc";
reg = <0x05090000 0x9000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&gcc GCC_GPU_GPLL0_CLK_SRC>,
<&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
clock-names = "bi_tcxo",
"gcc_gpu_gpll0_clk_src",
"gcc_gpu_gpll0_div_clk_src";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

View File

@ -0,0 +1,108 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,sc7180-lpasscorecc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm LPASS Core Clock Controller Binding for SC7180
maintainers:
- Taniya Das <tdas@codeaurora.org>
description: |
Qualcomm LPASS core clock control module which supports the clocks and
power domains on SC7180.
See also:
- dt-bindings/clock/qcom,lpasscorecc-sc7180.h
properties:
compatible:
enum:
- qcom,sc7180-lpasshm
- qcom,sc7180-lpasscorecc
clocks:
items:
- description: gcc_lpass_sway clock from GCC
- description: Board XO source
clock-names:
items:
- const: iface
- const: bi_tcxo
power-domains:
maxItems: 1
'#clock-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
minItems: 1
items:
- description: lpass core cc register
- description: lpass audio cc register
reg-names:
items:
- const: lpass_core_cc
- const: lpass_audio_cc
if:
properties:
compatible:
contains:
const: qcom,sc7180-lpasshm
then:
properties:
reg:
maxItems: 1
else:
properties:
reg:
minItems: 2
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,gcc-sc7180.h>
#include <dt-bindings/clock/qcom,lpasscorecc-sc7180.h>
clock-controller@63000000 {
compatible = "qcom,sc7180-lpasshm";
reg = <0x63000000 0x28>;
clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>, <&rpmhcc RPMH_CXO_CLK>;
clock-names = "iface", "bi_tcxo";
#clock-cells = <1>;
#power-domain-cells = <1>;
};
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,gcc-sc7180.h>
#include <dt-bindings/clock/qcom,lpasscorecc-sc7180.h>
clock-controller@62d00000 {
compatible = "qcom,sc7180-lpasscorecc";
reg = <0x62d00000 0x50000>, <0x62780000 0x30000>;
reg-names = "lpass_core_cc", "lpass_audio_cc";
clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>, <&rpmhcc RPMH_CXO_CLK>;
clock-names = "iface", "bi_tcxo";
power-domains = <&lpass_hm LPASS_CORE_HM_GDSCR>;
#clock-cells = <1>;
#power-domain-cells = <1>;
};
...

View File

@ -19,15 +19,15 @@ description:
properties:
compatible:
oneOf:
- const: renesas,r8a73a4-cpg-clocks # R-Mobile APE6
- const: renesas,r8a7740-cpg-clocks # R-Mobile A1
- const: renesas,r8a7778-cpg-clocks # R-Car M1
- const: renesas,r8a7779-cpg-clocks # R-Car H1
- const: renesas,r8a73a4-cpg-clocks # R-Mobile APE6
- const: renesas,r8a7740-cpg-clocks # R-Mobile A1
- const: renesas,r8a7778-cpg-clocks # R-Car M1
- const: renesas,r8a7779-cpg-clocks # R-Car H1
- items:
- enum:
- renesas,r7s72100-cpg-clocks # RZ/A1H
- const: renesas,rz-cpg-clocks # RZ/A1
- const: renesas,sh73a0-cpg-clocks # SH-Mobile AG5
- enum:
- renesas,r7s72100-cpg-clocks # RZ/A1H
- const: renesas,rz-cpg-clocks # RZ/A1
- const: renesas,sh73a0-cpg-clocks # SH-Mobile AG5
reg:
maxItems: 1

View File

@ -4,9 +4,15 @@ The RK3288 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
A revision of this SoC is available: rk3288w. The clock tree is a bit
different so another dt-compatible is available. Noticed that it is only
setting the difference but there is no automatic revision detection. This
should be performed by bootloaders.
Required Properties:
- compatible: should be "rockchip,rk3288-cru"
- compatible: should be "rockchip,rk3288-cru" or "rockchip,rk3288w-cru" in
case of this revision of Rockchip rk3288.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.

View File

@ -16,7 +16,7 @@ properties:
"#clock-cells":
const: 1
compatible :
compatible:
enum:
- sprd,sc9863a-ap-clk
- sprd,sc9863a-aon-clk

View File

@ -32,8 +32,7 @@ properties:
- const: hdmi
ddc:
allOf:
- $ref: /schemas/types.yaml#/definitions/phandle
$ref: /schemas/types.yaml#/definitions/phandle
description: >
Phandle of the I2C controller used for DDC EDID probing

View File

@ -162,14 +162,13 @@ required:
additionalProperties: false
examples:
- |
- |
#include <dt-bindings/clock/imx8mq-clock.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/imx8mq-reset.h>
#include <dt-bindings/clock/imx8mq-clock.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/imx8mq-reset.h>
mipi_dsi: mipi_dsi@30a00000 {
mipi_dsi: mipi_dsi@30a00000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx8mq-nwl-dsi";
@ -224,4 +223,4 @@ examples:
};
};
};
};
};

View File

@ -119,17 +119,17 @@ then:
# The LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks.
# These clocks are optional.
- enum:
- extal
- dclkin.0
- dclkin.1
- extal
- dclkin.0
- dclkin.1
- enum:
- extal
- dclkin.0
- dclkin.1
- extal
- dclkin.0
- dclkin.1
- enum:
- extal
- dclkin.0
- dclkin.1
- extal
- dclkin.0
- dclkin.1
required:
- clock-names

View File

@ -18,16 +18,16 @@ properties:
compatible:
oneOf:
- items:
- enum:
- ti,ths8134a
- ti,ths8134b
- const: ti,ths8134
- enum:
- ti,ths8134a
- ti,ths8134b
- const: ti,ths8134
- enum:
- adi,adv7123
- dumb-vga-dac
- ti,opa362
- ti,ths8134
- ti,ths8135
- adi,adv7123
- dumb-vga-dac
- ti,opa362
- ti,ths8134
- ti,ths8135
ports:
type: object

View File

@ -55,11 +55,11 @@ patternProperties:
clock-master:
type: boolean
description:
Should be enabled if the host is being used in conjunction with
another DSI host to drive the same peripheral. Hardware supporting
such a configuration generally requires the data on both the busses
to be driven by the same clock. Only the DSI host instance
controlling this clock should contain this property.
Should be enabled if the host is being used in conjunction with
another DSI host to drive the same peripheral. Hardware supporting
such a configuration generally requires the data on both the busses
to be driven by the same clock. Only the DSI host instance
controlling this clock should contain this property.
enforce-video-mode:
type: boolean

View File

@ -21,9 +21,9 @@ properties:
items:
- enum:
# Waveshare 3.5" 320x480 Color TFT LCD
- waveshare,rpi-lcd-35
- waveshare,rpi-lcd-35
# Ozzmaker 3.5" 320x480 Color TFT LCD
- ozzmaker,piscreen
- ozzmaker,piscreen
- const: ilitek,ili9486
spi-max-frequency:

View File

@ -13,11 +13,11 @@ properties:
compatible:
oneOf:
- enum:
- ingenic,jz4725b-ipu
- ingenic,jz4760-ipu
- ingenic,jz4725b-ipu
- ingenic,jz4760-ipu
- items:
- const: ingenic,jz4770-ipu
- const: ingenic,jz4760-ipu
- const: ingenic,jz4770-ipu
- const: ingenic,jz4760-ipu
reg:
maxItems: 1

View File

@ -58,11 +58,11 @@ properties:
- port@0
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- compatible
- reg
- interrupts
- clocks
- clock-names
if:
properties:

View File

@ -38,10 +38,10 @@ properties:
clocks:
items:
- description: GMU clock
- description: GPU CX clock
- description: GPU AXI clock
- description: GPU MEMNOC clock
- description: GMU clock
- description: GPU CX clock
- description: GPU AXI clock
- description: GPU MEMNOC clock
clock-names:
items:
@ -52,8 +52,8 @@ properties:
interrupts:
items:
- description: GMU HFI interrupt
- description: GMU interrupt
- description: GMU HFI interrupt
- description: GMU interrupt
interrupt-names:
@ -62,14 +62,14 @@ properties:
- const: gmu
power-domains:
items:
- description: CX power domain
- description: GX power domain
items:
- description: CX power domain
- description: GX power domain
power-domain-names:
items:
- const: cx
- const: gx
items:
- const: cx
- const: gx
iommus:
maxItems: 1
@ -90,13 +90,13 @@ required:
- operating-points-v2
examples:
- |
#include <dt-bindings/clock/qcom,gpucc-sdm845.h>
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
- |
#include <dt-bindings/clock/qcom,gpucc-sdm845.h>
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
gmu: gmu@506a000 {
gmu: gmu@506a000 {
compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
reg = <0x506a000 0x30000>,
@ -120,4 +120,4 @@ examples:
iommus = <&adreno_smmu 5>;
operating-points-v2 = <&gmu_opp_table>;
};
};

View File

@ -24,9 +24,9 @@ properties:
reg: true
reset-gpios: true
vdd-supply:
description: core voltage supply
description: core voltage supply
vddio-supply:
description: vddio supply
description: vddio supply
required:
- compatible

View File

@ -48,12 +48,12 @@ properties:
port: true
required:
- compatible
- reg
- enable-gpios
- pp1800-supply
- avdd-supply
- avee-supply
- compatible
- reg
- enable-gpios
- pp1800-supply
- avdd-supply
- avee-supply
additionalProperties: false

View File

@ -19,9 +19,9 @@ properties:
backlight: true
reset-gpios: true
iovcc-supply:
description: regulator that supplies the iovcc voltage
description: regulator that supplies the iovcc voltage
vdd-supply:
description: regulator that supplies the vdd voltage
description: regulator that supplies the vdd voltage
required:
- compatible

View File

@ -19,11 +19,11 @@ properties:
backlight: true
reset-gpios: true
avdd-supply:
description: regulator that supplies the AVDD voltage
description: regulator that supplies the AVDD voltage
dvdd-supply:
description: regulator that supplies the DVDD voltage
description: regulator that supplies the DVDD voltage
cvdd-supply:
description: regulator that supplies the CVDD voltage
description: regulator that supplies the CVDD voltage
required:
- compatible

View File

@ -25,8 +25,7 @@ properties:
compatible:
items:
- enum:
- dlink,dir-685-panel
- dlink,dir-685-panel
- const: ilitek,ili9322
reset-gpios: true

View File

@ -13,8 +13,7 @@ properties:
compatible:
items:
- enum:
- bananapi,lhr050h41
- bananapi,lhr050h41
- const: ilitek,ili9881c
backlight: true

View File

@ -21,9 +21,9 @@ properties:
backlight: true
reset-gpios: true
iovcc-supply:
description: regulator that supplies the iovcc voltage
description: regulator that supplies the iovcc voltage
vci-supply:
description: regulator that supplies the vci voltage
description: regulator that supplies the vci voltage
required:
- compatible

View File

@ -19,9 +19,9 @@ properties:
backlight: true
reset-gpios: true
iovcc-supply:
description: regulator that supplies the iovcc voltage
description: regulator that supplies the iovcc voltage
vcc-supply:
description: regulator that supplies the vcc voltage
description: regulator that supplies the vcc voltage
required:
- compatible

View File

@ -25,9 +25,9 @@ properties:
reg: true
reset-gpios: true
vdd-supply:
description: regulator that supplies the vdd voltage
description: regulator that supplies the vdd voltage
vddi-supply:
description: regulator that supplies the vddi voltage
description: regulator that supplies the vddi voltage
backlight: true
required:

View File

@ -27,10 +27,10 @@ properties:
compatible:
items:
- enum:
- motorola,droid4-panel # Panel from Motorola Droid4 phone
- nokia,himalaya # Panel from Nokia N950 phone
- tpo,taal # Panel from OMAP4 SDP board
- const: panel-dsi-cm # Generic DSI command mode panel compatible fallback
- motorola,droid4-panel # Panel from Motorola Droid4 phone
- nokia,himalaya # Panel from Nokia N950 phone
- tpo,taal # Panel from OMAP4 SDP board
- const: panel-dsi-cm # Generic DSI command mode panel compatible fallback
reg:
maxItems: 1

View File

@ -59,7 +59,7 @@ description: |
properties:
clock-frequency:
description: Panel clock in Hz
description: Panel clock in Hz
hactive:
$ref: /schemas/types.yaml#/definitions/uint32
@ -200,15 +200,15 @@ properties:
description: Enable double clock mode
required:
- clock-frequency
- hactive
- vactive
- hfront-porch
- hback-porch
- hsync-len
- vfront-porch
- vback-porch
- vsync-len
- clock-frequency
- hactive
- vactive
- hfront-porch
- hback-porch
- hsync-len
- vfront-porch
- vback-porch
- vsync-len
additionalProperties: false

View File

@ -10,8 +10,8 @@ maintainers:
- Philippe CORNU <philippe.cornu@st.com>
description: |
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
panel connected using a MIPI-DSI video interface.
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
panel connected using a MIPI-DSI video interface.
allOf:
- $ref: panel-common.yaml#

View File

@ -18,9 +18,9 @@ properties:
reg: true
reset-gpios: true
vdd3-supply:
description: core voltage supply
description: core voltage supply
vci-supply:
description: voltage supply for analog circuits
description: voltage supply for analog circuits
required:
- compatible

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Visionox model RM69299 Panels Device Tree Bindings.
maintainers:
- Harigovindan P <harigovi@codeaurora.org>
- Harigovindan P <harigovi@codeaurora.org>
description: |
This binding is for display panels using a Visionox RM692999 panel.

View File

@ -45,7 +45,7 @@ properties:
phy-dsi-supply:
description:
Phandle of the regulator that provides the supply voltage.
Phandle of the regulator that provides the supply voltage.
ports:
type: object
@ -147,4 +147,3 @@ examples:
...

View File

@ -78,7 +78,7 @@ properties:
- const: vp4
interrupts:
items:
items:
- description: common_m DSS Master common
- description: common_s0 DSS Shared common 0
- description: common_s1 DSS Shared common 1

View File

@ -56,8 +56,8 @@ properties:
memory-region:
description:
phandle to a node describing reserved memory (System RAM memory)
used by DSP (see bindings/reserved-memory/reserved-memory.txt)
phandle to a node describing reserved memory (System RAM memory)
used by DSP (see bindings/reserved-memory/reserved-memory.txt)
maxItems: 1
required:

View File

@ -177,10 +177,10 @@ properties:
dependencies:
# 'vendor,bool-property' is only allowed when 'vendor,string-array-property'
# is present
vendor,bool-property: [ vendor,string-array-property ]
vendor,bool-property: [ 'vendor,string-array-property' ]
# Expressing 2 properties in both orders means all of the set of properties
# must be present or none of them.
vendor,string-array-property: [ vendor,bool-property ]
vendor,string-array-property: [ 'vendor,bool-property' ]
required:
- compatible

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: IBM FSI-attached SPI controllers
maintainers:
- Eddie James <eajames@linux.ibm.com>
- Eddie James <eajames@linux.ibm.com>
description: |
This binding describes an FSI CFAM engine called the FSI2SPI. Therefore this

View File

@ -19,10 +19,8 @@ properties:
reg:
items:
- description: the I/O address containing the GPIO controller
registers.
- description: the I/O address containing the Chip Common A interrupt
registers.
- description: the I/O address containing the GPIO controller registers.
- description: the I/O address containing the Chip Common A interrupt registers.
gpio-controller: true

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale MXS GPIO controller
maintainers:
- Shawn Guo <shawn.guo@linaro.org>
- Shawn Guo <shawnguo@kernel.org>
- Anson Huang <Anson.Huang@nxp.com>
description: |

View File

@ -13,39 +13,39 @@ properties:
compatible:
oneOf:
- items:
- enum:
- renesas,gpio-r8a7778 # R-Car M1
- renesas,gpio-r8a7779 # R-Car H1
- const: renesas,rcar-gen1-gpio # R-Car Gen1
- enum:
- renesas,gpio-r8a7778 # R-Car M1
- renesas,gpio-r8a7779 # R-Car H1
- const: renesas,rcar-gen1-gpio # R-Car Gen1
- items:
- enum:
- renesas,gpio-r8a7742 # RZ/G1H
- renesas,gpio-r8a7743 # RZ/G1M
- renesas,gpio-r8a7744 # RZ/G1N
- renesas,gpio-r8a7745 # RZ/G1E
- renesas,gpio-r8a77470 # RZ/G1C
- renesas,gpio-r8a7790 # R-Car H2
- renesas,gpio-r8a7791 # R-Car M2-W
- renesas,gpio-r8a7792 # R-Car V2H
- renesas,gpio-r8a7793 # R-Car M2-N
- renesas,gpio-r8a7794 # R-Car E2
- const: renesas,rcar-gen2-gpio # R-Car Gen2 or RZ/G1
- enum:
- renesas,gpio-r8a7742 # RZ/G1H
- renesas,gpio-r8a7743 # RZ/G1M
- renesas,gpio-r8a7744 # RZ/G1N
- renesas,gpio-r8a7745 # RZ/G1E
- renesas,gpio-r8a77470 # RZ/G1C
- renesas,gpio-r8a7790 # R-Car H2
- renesas,gpio-r8a7791 # R-Car M2-W
- renesas,gpio-r8a7792 # R-Car V2H
- renesas,gpio-r8a7793 # R-Car M2-N
- renesas,gpio-r8a7794 # R-Car E2
- const: renesas,rcar-gen2-gpio # R-Car Gen2 or RZ/G1
- items:
- enum:
- renesas,gpio-r8a774a1 # RZ/G2M
- renesas,gpio-r8a774b1 # RZ/G2N
- renesas,gpio-r8a774c0 # RZ/G2E
- renesas,gpio-r8a7795 # R-Car H3
- renesas,gpio-r8a7796 # R-Car M3-W
- renesas,gpio-r8a77961 # R-Car M3-W+
- renesas,gpio-r8a77965 # R-Car M3-N
- renesas,gpio-r8a77970 # R-Car V3M
- renesas,gpio-r8a77980 # R-Car V3H
- renesas,gpio-r8a77990 # R-Car E3
- renesas,gpio-r8a77995 # R-Car D3
- const: renesas,rcar-gen3-gpio # R-Car Gen3 or RZ/G2
- enum:
- renesas,gpio-r8a774a1 # RZ/G2M
- renesas,gpio-r8a774b1 # RZ/G2N
- renesas,gpio-r8a774c0 # RZ/G2E
- renesas,gpio-r8a7795 # R-Car H3
- renesas,gpio-r8a7796 # R-Car M3-W
- renesas,gpio-r8a77961 # R-Car M3-W+
- renesas,gpio-r8a77965 # R-Car M3-N
- renesas,gpio-r8a77970 # R-Car V3M
- renesas,gpio-r8a77980 # R-Car V3H
- renesas,gpio-r8a77990 # R-Car E3
- renesas,gpio-r8a77995 # R-Car D3
- const: renesas,rcar-gen3-gpio # R-Car Gen3 or RZ/G2
reg:
maxItems: 1

View File

@ -26,7 +26,8 @@ properties:
- description: AXI/master interface clock
- description: GPU core clock
- description: Shader clock (only required if GPU has feature PIPE_3D)
- description: AHB/slave interface clock (only required if GPU can gate slave interface independently)
- description: AHB/slave interface clock (only required if GPU can gate
slave interface independently)
minItems: 1
maxItems: 4

View File

@ -1,39 +0,0 @@
Qualcomm Hardware Mutex Block:
The hardware block provides mutexes utilized between different processors on
the SoC as part of the communication protocol used by these processors.
- compatible:
Usage: required
Value type: <string>
Definition: must be one of:
"qcom,sfpb-mutex",
"qcom,tcsr-mutex"
- syscon:
Usage: required
Value type: <prop-encoded-array>
Definition: one cell containing:
syscon phandle
offset of the hwmutex block within the syscon
stride of the hwmutex registers
- #hwlock-cells:
Usage: required
Value type: <u32>
Definition: must be 1, the specified cell represent the lock id
(hwlock standard property, see hwlock.txt)
Example:
tcsr_mutex_block: syscon@fd484000 {
compatible = "syscon";
reg = <0xfd484000 0x2000>;
};
hwlock@fd484000 {
compatible = "qcom,tcsr-mutex";
syscon = <&tcsr_mutex_block 0 0x80>;
#hwlock-cells = <1>;
};

View File

@ -0,0 +1,42 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwlock/qcom-hwspinlock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Hardware Mutex Block
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
description:
The hardware block provides mutexes utilized between different processors on
the SoC as part of the communication protocol used by these processors.
properties:
compatible:
enum:
- qcom,sfpb-mutex
- qcom,tcsr-mutex
reg:
maxItems: 1
'#hwlock-cells':
const: 1
required:
- compatible
- reg
- '#hwlock-cells'
additionalProperties: false
examples:
- |
tcsr_mutex: hwlock@1f40000 {
compatible = "qcom,tcsr-mutex";
reg = <0x01f40000 0x40000>;
#hwlock-cells = <1>;
};
...

View File

@ -19,7 +19,7 @@ description: |+
properties:
compatible:
enum:
- adi,axi-fan-control-1.00.a
- adi,axi-fan-control-1.00.a
reg:
maxItems: 1

View File

@ -20,22 +20,22 @@ properties:
- const: fsl,imx1-i2c
- items:
- enum:
- fsl,imx25-i2c
- fsl,imx27-i2c
- fsl,imx31-i2c
- fsl,imx50-i2c
- fsl,imx51-i2c
- fsl,imx53-i2c
- fsl,imx6q-i2c
- fsl,imx6sl-i2c
- fsl,imx6sx-i2c
- fsl,imx6sll-i2c
- fsl,imx6ul-i2c
- fsl,imx7s-i2c
- fsl,imx8mq-i2c
- fsl,imx8mm-i2c
- fsl,imx8mn-i2c
- fsl,imx8mp-i2c
- fsl,imx25-i2c
- fsl,imx27-i2c
- fsl,imx31-i2c
- fsl,imx50-i2c
- fsl,imx51-i2c
- fsl,imx53-i2c
- fsl,imx6q-i2c
- fsl,imx6sl-i2c
- fsl,imx6sx-i2c
- fsl,imx6sll-i2c
- fsl,imx6ul-i2c
- fsl,imx7s-i2c
- fsl,imx8mq-i2c
- fsl,imx8mm-i2c
- fsl,imx8mn-i2c
- fsl,imx8mp-i2c
- const: fsl,imx21-i2c
reg:

View File

@ -14,6 +14,7 @@ Required properties:
"mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629
"mediatek,mt8173-i2c": for MediaTek MT8173
"mediatek,mt8183-i2c": for MediaTek MT8183
"mediatek,mt8192-i2c": for MediaTek MT8192
"mediatek,mt8516-i2c", "mediatek,mt2712-i2c": for MediaTek MT8516
- reg: physical base address of the controller and dma base, length of memory
mapped region.

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale MXS Inter IC (I2C) Controller
maintainers:
- Shawn Guo <shawn.guo@linaro.org>
- Shawn Guo <shawnguo@kernel.org>
properties:
compatible:

View File

@ -16,8 +16,8 @@ allOf:
required:
- mrvl,i2c-polling
then:
required:
- interrupts
required:
- interrupts
properties:
compatible:

View File

@ -72,6 +72,16 @@ wants to support one of the below features, it should adapt these bindings.
this information to adapt power management to keep the arbitration awake
all the time, for example. Can not be combined with 'single-master'.
- pinctrl
add extra pinctrl to configure SCL/SDA pins to GPIO function for bus
recovery, call it "gpio" or "recovery" (deprecated) state
- scl-gpios
specify the gpio related to SCL pin. Used for GPIO bus recovery.
- sda-gpios
specify the gpio related to SDA pin. Optional for GPIO bus recovery.
- single-master
states that there is no other master active on this bus. The OS can use
this information to detect a stalled bus more reliably, for example.

View File

@ -26,6 +26,9 @@ properties:
- items:
- const: allwinner,sun50i-a64-i2c
- const: allwinner,sun6i-a31-i2c
- items:
- const: allwinner,sun50i-a100-i2c
- const: allwinner,sun6i-a31-i2c
- items:
- const: allwinner,sun50i-h6-i2c
- const: allwinner,sun6i-a31-i2c

View File

@ -10,6 +10,7 @@ Required properties:
"renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC.
"renesas,i2c-r8a774b1" if the device is a part of a R8A774B1 SoC.
"renesas,i2c-r8a774c0" if the device is a part of a R8A774C0 SoC.
"renesas,i2c-r8a774e1" if the device is a part of a R8A774E1 SoC.
"renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
"renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
"renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.

View File

@ -11,6 +11,7 @@ Required properties:
- "renesas,iic-r8a774a1" (RZ/G2M)
- "renesas,iic-r8a774b1" (RZ/G2N)
- "renesas,iic-r8a774c0" (RZ/G2E)
- "renesas,iic-r8a774e1" (RZ/G2H)
- "renesas,iic-r8a7790" (R-Car H2)
- "renesas,iic-r8a7791" (R-Car M2-W)
- "renesas,iic-r8a7792" (R-Car V2H)

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