mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-11-11 12:28:41 +08:00
irqchip updates for Linux 5.11
- Preliminary support for managed interrupts on platform devices - Correctly identify allocation of MSIs proxyied by another device - Remove the fasteoi IPI flow which has been proved useless - Generalise the Ocelot support to new SoCs - Improve GICv4.1 vcpu entry, matching the corresponding KVM optimisation - Work around spurious interrupts on Qualcomm PDC - Random fixes and cleanups -----BEGIN PGP SIGNATURE----- iQJDBAABCgAtFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAl/Uxq8PHG1hekBrZXJu ZWwub3JnAAoJECPQ0LrRPXpDoW0P/0ZMDvFPxrfnJD46exUgUOPuuFF8jZxAlxD8 7UExqar7u6yX7bbq394jPgtOOxldDagfCx/jCXgb9ja7DK5EHKRcrfjaDT8knHi2 Keg5RaRMRi9TVltvWQTxAkXwSv0Atl881qqsndPeZCez0GNZp+HB34s+rNkZwBOu MBrWihMQOSv5QE6milsNc7HXLSHM1eLZ7Y2XgumNtKrIGEX9yZI7qwdMofwP8Za3 ayMOvc1WAWaTJI7Mg5ac1yTCVbqLmRHhCtws6c6DMgaRu6SI0itmbpQzkDuJJIe3 k9h4KQPaKAFcQsoo3GV0MKTMm63eq82XT3CAdv+htYRY1z95D2+nzNK+mJtsGptX gJ2zeJkUb4u+yVtNguL9qjo5ssCXV/6IybJxv6baaEFnSwQMUwqa066NdxmtqfIe 1BOWnc153a7SRbQ34M9/llje+v8YJbueGMS2RFR2LQ6IjjpaHsXh+YCZokfA/kdk zGbOUD5WWFtFD1T3UoaJ4gFt+pzHjNqym4CcEj4S1Vf5y+POUkNmC+GYK+xfm2Fp WJMbdIUxJhHFRD9L1ShtfAVUSbp712VOOdILp9rYAkOdqfb51BVUiMUP++s2dGp1 ZIT78qt7kTKT1CxbDdFAjzsi7RoMqdSGYgKmG4sVprELeZnFwq47nBkBr8XEQ1TT 0ccEUOY8 =7Z24 -----END PGP SIGNATURE----- Merge tag 'irqchip-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates for 5.11 from Marc Zyngier: - Preliminary support for managed interrupts on platform devices - Correctly identify allocation of MSIs proxyied by another device - Remove the fasteoi IPI flow which has been proved useless - Generalise the Ocelot support to new SoCs - Improve GICv4.1 vcpu entry, matching the corresponding KVM optimisation - Work around spurious interrupts on Qualcomm PDC - Random fixes and cleanups Link: https://lore.kernel.org/r/20201212135626.1479884-1-maz@kernel.org
This commit is contained in:
Thomas Gleixner
commit
3c41e57a1e
6
.mailmap
6
.mailmap
@ -82,7 +82,10 @@ 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 Baryshkov <dbaryshkov@gmail.com>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com> <[dbaryshkov@gmail.com]>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com> <dmitry_baryshkov@mentor.com>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com> <dmitry_eremin@mentor.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>
|
||||
@ -287,6 +290,7 @@ Santosh Shilimkar <ssantosh@kernel.org>
|
||||
Sarangdhar Joshi <spjoshi@codeaurora.org>
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
S.Çağlar Onur <caglar@pardus.org.tr>
|
||||
Sean Christopherson <seanjc@google.com> <sean.j.christopherson@intel.com>
|
||||
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
|
||||
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
|
||||
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
|
||||
|
||||
62
CREDITS
62
CREDITS
@ -98,7 +98,7 @@ N: Erik Andersen
|
||||
E: andersen@codepoet.org
|
||||
W: https://www.codepoet.org/
|
||||
P: 1024D/30D39057 1BC4 2742 E885 E4DE 9301 0C82 5F9B 643E 30D3 9057
|
||||
D: Maintainer of ide-cd and Uniform CD-ROM driver,
|
||||
D: Maintainer of ide-cd and Uniform CD-ROM driver,
|
||||
D: ATAPI CD-Changer support, Major 2.1.x CD-ROM update.
|
||||
S: 352 North 525 East
|
||||
S: Springville, Utah 84663
|
||||
@ -263,7 +263,7 @@ N: Paul Barton-Davis
|
||||
E: pbd@op.net
|
||||
D: Driver for WaveFront soundcards (Turtle Beach Maui, Tropez, Tropez+)
|
||||
D: Various bugfixes and changes to sound drivers
|
||||
S: USA
|
||||
S: USA
|
||||
|
||||
N: Carlos Henrique Bauer
|
||||
E: chbauer@acm.org
|
||||
@ -849,6 +849,12 @@ D: trivial hack to add variable address length routing to Rose.
|
||||
D: AX25-HOWTO, HAM-HOWTO, IPX-HOWTO, NET-2-HOWTO
|
||||
D: ax25-utils maintainer.
|
||||
|
||||
N: Kamil Debski
|
||||
E: kamil@wypas.org
|
||||
D: Samsung S5P 2D graphics acceleration and Multi Format Codec drivers
|
||||
D: Samsung USB2 phy drivers
|
||||
D: PWM fan driver
|
||||
|
||||
N: Helge Deller
|
||||
E: deller@gmx.de
|
||||
W: http://www.parisc-linux.org/
|
||||
@ -1199,7 +1205,7 @@ N: Daniel J. Frasnelli
|
||||
E: dfrasnel@alphalinux.org
|
||||
W: http://www.alphalinux.org/
|
||||
P: 1024/3EF87611 B9 F1 44 50 D3 E8 C2 80 DA E5 55 AA 56 7C 42 DA
|
||||
D: DEC Alpha hacker
|
||||
D: DEC Alpha hacker
|
||||
D: Miscellaneous bug squisher
|
||||
|
||||
N: Jim Freeman
|
||||
@ -1299,7 +1305,7 @@ S: P.O. Box 76, Epping
|
||||
S: New South Wales, 2121
|
||||
S: Australia
|
||||
|
||||
N: Carlos E. Gorges
|
||||
N: Carlos E. Gorges
|
||||
E: carlos@techlinux.com.br
|
||||
D: fix smp support on cmpci driver
|
||||
P: 2048G/EA3C4B19 FF31 33A6 0362 4915 B7EB E541 17D0 0379 EA3C 4B19
|
||||
@ -1340,7 +1346,7 @@ E: wgreathouse@smva.com
|
||||
E: wgreathouse@myfavoritei.com
|
||||
D: Current Belkin USB Serial Adapter F5U103 hacker
|
||||
D: Kernel hacker, embedded systems
|
||||
S: 7802 Fitzwater Road
|
||||
S: 7802 Fitzwater Road
|
||||
S: Brecksville, OH 44141-1334
|
||||
S: USA
|
||||
|
||||
@ -1381,7 +1387,7 @@ N: Grant Guenther
|
||||
E: grant@torque.net
|
||||
W: http://www.torque.net/linux-pp.html
|
||||
D: original author of ppa driver for parallel port ZIP drive
|
||||
D: original architect of the parallel-port sharing scheme
|
||||
D: original architect of the parallel-port sharing scheme
|
||||
D: PARIDE subsystem: drivers for parallel port IDE & ATAPI devices
|
||||
S: 44 St. Joseph Street, Suite 506
|
||||
S: Toronto, Ontario, M4Y 2W4
|
||||
@ -1523,7 +1529,7 @@ N: Benjamin Herrenschmidt
|
||||
E: benh@kernel.crashing.org
|
||||
D: Various parts of PPC/PPC64 & PowerMac
|
||||
S: 312/107 Canberra Avenue
|
||||
S: Griffith, ACT 2603
|
||||
S: Griffith, ACT 2603
|
||||
S: Australia
|
||||
|
||||
N: Andreas Herrmann
|
||||
@ -1825,7 +1831,7 @@ S: Hungary
|
||||
N: Bernhard Kaindl
|
||||
E: bkaindl@netway.at
|
||||
E: edv@bartelt.via.at
|
||||
D: Author of a menu based configuration tool, kmenu, which
|
||||
D: Author of a menu based configuration tool, kmenu, which
|
||||
D: is the predecessor of 'make menuconfig' and 'make xconfig'.
|
||||
D: digiboard driver update(modularisation work and 2.1.x upd)
|
||||
S: Tallak 95
|
||||
@ -2016,7 +2022,7 @@ W: http://www.xos.nl/
|
||||
D: IP transparent proxy support
|
||||
S: X/OS Experts in Open Systems BV
|
||||
S: Kruislaan 419
|
||||
S: 1098 VA Amsterdam
|
||||
S: 1098 VA Amsterdam
|
||||
S: The Netherlands
|
||||
|
||||
N: Goran Koruga
|
||||
@ -2088,7 +2094,7 @@ S: Germany
|
||||
|
||||
N: Andrzej M. Krzysztofowicz
|
||||
E: ankry@mif.pg.gda.pl
|
||||
D: Some 8-bit XT disk driver and devfs hacking
|
||||
D: Some 8-bit XT disk driver and devfs hacking
|
||||
D: Aladdin 1533/1543(C) chipset IDE
|
||||
D: PIIX chipset IDE
|
||||
S: ul. Matemblewska 1B/10
|
||||
@ -2463,7 +2469,7 @@ E: mge@EZ-Darmstadt.Telekom.de
|
||||
D: Logical Volume Manager
|
||||
S: Bartningstr. 12
|
||||
S: 64289 Darmstadt
|
||||
S: Germany
|
||||
S: Germany
|
||||
|
||||
N: Mark W. McClelland
|
||||
E: mmcclell@bigfoot.com
|
||||
@ -2547,7 +2553,7 @@ E: meskes@debian.org
|
||||
P: 1024/04B6E8F5 6C 77 33 CA CC D6 22 03 AB AB 15 A3 AE AD 39 7D
|
||||
D: Kernel hacker. PostgreSQL hacker. Software watchdog daemon.
|
||||
D: Maintainer of several Debian packages
|
||||
S: Th.-Heuss-Str. 61
|
||||
S: Th.-Heuss-Str. 61
|
||||
S: D-41812 Erkelenz
|
||||
S: Germany
|
||||
|
||||
@ -2785,7 +2791,7 @@ E: neuffer@goofy.zdv.uni-mainz.de
|
||||
W: http://www.i-Connect.Net/~mike/
|
||||
D: Developer and maintainer of the EATA-DMA SCSI driver
|
||||
D: Co-developer EATA-PIO SCSI driver
|
||||
D: /proc/scsi and assorted other snippets
|
||||
D: /proc/scsi and assorted other snippets
|
||||
S: Zum Schiersteiner Grund 2
|
||||
S: 55127 Mainz
|
||||
S: Germany
|
||||
@ -2852,6 +2858,10 @@ D: IPX development and support
|
||||
N: Venkatesh Pallipadi (Venki)
|
||||
D: x86/HPET
|
||||
|
||||
N: Kyungmin Park
|
||||
E: kyungmin.park@samsung.com
|
||||
D: Samsung S5Pv210 and Exynos4210 mobile platforms
|
||||
|
||||
N: David Parsons
|
||||
E: orc@pell.chi.il.us
|
||||
D: improved memory detection code.
|
||||
@ -3019,7 +3029,7 @@ D: Embedded PowerPC 4xx/6xx/7xx/74xx support
|
||||
S: Chandler, Arizona 85249
|
||||
S: USA
|
||||
|
||||
N: Frederic Potter
|
||||
N: Frederic Potter
|
||||
E: fpotter@cirpack.com
|
||||
D: Some PCI kernel support
|
||||
|
||||
@ -3452,21 +3462,21 @@ S: Klosterweg 28 / i309
|
||||
S: 76131 Karlsruhe
|
||||
S: Germany
|
||||
|
||||
N: James Simmons
|
||||
N: James Simmons
|
||||
E: jsimmons@infradead.org
|
||||
E: jsimmons@users.sf.net
|
||||
E: jsimmons@users.sf.net
|
||||
D: Frame buffer device maintainer
|
||||
D: input layer development
|
||||
D: tty/console layer
|
||||
D: various mipsel devices
|
||||
S: 115 Carmel Avenue
|
||||
D: various mipsel devices
|
||||
S: 115 Carmel Avenue
|
||||
S: El Cerrito CA 94530
|
||||
S: USA
|
||||
S: USA
|
||||
|
||||
N: Jaspreet Singh
|
||||
E: jaspreet@sangoma.com
|
||||
W: www.sangoma.com
|
||||
D: WANPIPE drivers & API Support for Sangoma S508/FT1 cards
|
||||
D: WANPIPE drivers & API Support for Sangoma S508/FT1 cards
|
||||
S: Sangoma Technologies Inc.,
|
||||
S: 1001 Denison Street
|
||||
S: Suite 101
|
||||
@ -3490,7 +3500,7 @@ N: Craig Small
|
||||
E: csmall@triode.apana.org.au
|
||||
E: vk2xlz@gonzo.vk2xlz.ampr.org (packet radio)
|
||||
D: Gracilis PackeTwin device driver
|
||||
D: RSPF daemon
|
||||
D: RSPF daemon
|
||||
S: 10 Stockalls Place
|
||||
S: Minto, NSW, 2566
|
||||
S: Australia
|
||||
@ -3700,7 +3710,7 @@ N: Tsu-Sheng Tsao
|
||||
E: tsusheng@scf.usc.edu
|
||||
D: IGMP(Internet Group Management Protocol) version 2
|
||||
S: 2F 14 ALY 31 LN 166 SEC 1 SHIH-PEI RD
|
||||
S: Taipei
|
||||
S: Taipei
|
||||
S: Taiwan 112
|
||||
S: Republic of China
|
||||
S: 24335 Delta Drive
|
||||
@ -3861,7 +3871,7 @@ D: Produced the Slackware distribution, updated the SVGAlib
|
||||
D: patches for ghostscript, worked on color 'ls', etc.
|
||||
S: 301 15th Street S.
|
||||
S: Moorhead, Minnesota 56560
|
||||
S: USA
|
||||
S: USA
|
||||
|
||||
N: Jos Vos
|
||||
E: jos@xos.nl
|
||||
@ -3869,7 +3879,7 @@ W: http://www.xos.nl/
|
||||
D: Various IP firewall updates, ipfwadm
|
||||
S: X/OS Experts in Open Systems BV
|
||||
S: Kruislaan 419
|
||||
S: 1098 VA Amsterdam
|
||||
S: 1098 VA Amsterdam
|
||||
S: The Netherlands
|
||||
|
||||
N: Jeroen Vreeken
|
||||
@ -4107,7 +4117,7 @@ S: People's Repulic of China
|
||||
N: Victor Yodaiken
|
||||
E: yodaiken@fsmlabs.com
|
||||
D: RTLinux (RealTime Linux)
|
||||
S: POB 1822
|
||||
S: POB 1822
|
||||
S: Socorro NM, 87801
|
||||
S: USA
|
||||
|
||||
@ -4205,7 +4215,7 @@ D: EISA/sysfs subsystem
|
||||
S: France
|
||||
|
||||
# Don't add your name here, unless you really _are_ after Marc
|
||||
# alphabetically. Leonard used to be very proud of being the
|
||||
# alphabetically. Leonard used to be very proud of being the
|
||||
# last entry, and he'll get positively pissed if he can't even
|
||||
# be second-to-last. (and this file really _is_ supposed to be
|
||||
# in alphabetic order)
|
||||
|
||||
@ -1,29 +1,29 @@
|
||||
What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/cap
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/cap
|
||||
Date: December 3, 2009
|
||||
KernelVersion: 2.6.32
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Capabilities the DMA supports.Currently there are DMA_PQ, DMA_PQ_VAL,
|
||||
DMA_XOR,DMA_XOR_VAL,DMA_INTERRUPT.
|
||||
|
||||
What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/ring_active
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/ring_active
|
||||
Date: December 3, 2009
|
||||
KernelVersion: 2.6.32
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The number of descriptors active in the ring.
|
||||
|
||||
What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/ring_size
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/ring_size
|
||||
Date: December 3, 2009
|
||||
KernelVersion: 2.6.32
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Descriptor ring size, total number of descriptors available.
|
||||
|
||||
What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/version
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/version
|
||||
Date: December 3, 2009
|
||||
KernelVersion: 2.6.32
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Version of ioatdma device.
|
||||
|
||||
What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/intr_coalesce
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/intr_coalesce
|
||||
Date: August 8, 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
|
||||
@ -109,30 +109,6 @@ Description:
|
||||
When counting down the counter start from preset value
|
||||
and fire event when reach 0.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
|
||||
KernelVersion: 4.12
|
||||
Contact: benjamin.gaignard@st.com
|
||||
Description:
|
||||
Reading returns the list possible quadrature modes.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
|
||||
KernelVersion: 4.12
|
||||
Contact: benjamin.gaignard@st.com
|
||||
Description:
|
||||
Configure the device counter quadrature modes:
|
||||
|
||||
channel_A:
|
||||
Encoder A input servers as the count input and B as
|
||||
the UP/DOWN direction control input.
|
||||
|
||||
channel_B:
|
||||
Encoder B input serves as the count input and A as
|
||||
the UP/DOWN direction control input.
|
||||
|
||||
quadrature:
|
||||
Encoder A and B inputs are mixed to get direction
|
||||
and count with a scale of 0.25.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_count_enable_mode_available
|
||||
KernelVersion: 4.12
|
||||
Contact: benjamin.gaignard@st.com
|
||||
|
||||
@ -152,7 +152,7 @@ Description:
|
||||
When an interface is under test, it cannot be expected
|
||||
to pass packets as normal.
|
||||
|
||||
What: /sys/clas/net/<iface>/duplex
|
||||
What: /sys/class/net/<iface>/duplex
|
||||
Date: October 2009
|
||||
KernelVersion: 2.6.33
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
||||
@ -26,6 +26,10 @@ BUILDDIR = $(obj)/output
|
||||
PDFLATEX = xelatex
|
||||
LATEXOPTS = -interaction=batchmode
|
||||
|
||||
ifeq ($(KBUILD_VERBOSE),0)
|
||||
SPHINXOPTS += "-q"
|
||||
endif
|
||||
|
||||
# User-friendly check for sphinx-build
|
||||
HAVE_SPHINX := $(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi)
|
||||
|
||||
|
||||
@ -107,7 +107,7 @@ for a UID/GID will prevent that UID/GID from obtaining auxiliary setid
|
||||
privileges, such as allowing a user to set up user namespace UID/GID mappings.
|
||||
|
||||
Note on GID policies and setgroups()
|
||||
==================
|
||||
====================================
|
||||
In v5.9 we are adding support for limiting CAP_SETGID privileges as was done
|
||||
previously for CAP_SETUID. However, for compatibility with common sandboxing
|
||||
related code conventions in userspace, we currently allow arbitrary
|
||||
|
||||
@ -2858,6 +2858,8 @@
|
||||
mds=off [X86]
|
||||
tsx_async_abort=off [X86]
|
||||
kvm.nx_huge_pages=off [X86]
|
||||
no_entry_flush [PPC]
|
||||
no_uaccess_flush [PPC]
|
||||
|
||||
Exceptions:
|
||||
This does not have any effect on
|
||||
@ -3186,6 +3188,8 @@
|
||||
|
||||
noefi Disable EFI runtime services support.
|
||||
|
||||
no_entry_flush [PPC] Don't flush the L1-D cache when entering the kernel.
|
||||
|
||||
noexec [IA-64]
|
||||
|
||||
noexec [X86]
|
||||
@ -3235,6 +3239,9 @@
|
||||
nospec_store_bypass_disable
|
||||
[HW] Disable all mitigations for the Speculative Store Bypass vulnerability
|
||||
|
||||
no_uaccess_flush
|
||||
[PPC] Don't flush the L1-D cache after accessing user data.
|
||||
|
||||
noxsave [BUGS=X86] Disables x86 extended register state save
|
||||
and restore using xsave. The kernel will fallback to
|
||||
enabling legacy floating-point and sse state.
|
||||
|
||||
@ -478,7 +478,7 @@ order to ask the hardware to enter that state. Also, for each
|
||||
statistics of the given idle state. That information is exposed by the kernel
|
||||
via ``sysfs``.
|
||||
|
||||
For each CPU in the system, there is a :file:`/sys/devices/system/cpu<N>/cpuidle/`
|
||||
For each CPU in the system, there is a :file:`/sys/devices/system/cpu/cpu<N>/cpuidle/`
|
||||
directory in ``sysfs``, where the number ``<N>`` is assigned to the given
|
||||
CPU at the initialization time. That directory contains a set of subdirectories
|
||||
called :file:`state0`, :file:`state1` and so on, up to the number of idle state
|
||||
@ -494,7 +494,7 @@ object corresponding to it, as follows:
|
||||
residency.
|
||||
|
||||
``below``
|
||||
Total number of times this idle state had been asked for, but cerainly
|
||||
Total number of times this idle state had been asked for, but certainly
|
||||
a deeper idle state would have been a better match for the observed idle
|
||||
duration.
|
||||
|
||||
|
||||
@ -300,6 +300,7 @@ Note:
|
||||
0: 0 1 2 3 4 5 6 7
|
||||
RSS hash key:
|
||||
84:50:f4:00:a8:15:d1:a7:e9:7f:1d:60:35:c7:47:25:42:97:74:ca:56:bb:b6:a1:d8:43:e3:c9:0c:fd:17:55:c2:3a:4d:69:ed:f1:42:89
|
||||
|
||||
netdev_tstamp_prequeue
|
||||
----------------------
|
||||
|
||||
|
||||
@ -148,3 +148,13 @@ SunXi family
|
||||
* User Manual
|
||||
|
||||
http://dl.linux-sunxi.org/A64/Allwinner%20A64%20User%20Manual%20v1.0.pdf
|
||||
|
||||
- Allwinner H6
|
||||
|
||||
* Datasheet
|
||||
|
||||
https://linux-sunxi.org/images/5/5c/Allwinner_H6_V200_Datasheet_V1.1.pdf
|
||||
|
||||
* User Manual
|
||||
|
||||
https://linux-sunxi.org/images/4/46/Allwinner_H6_V200_User_Manual_V1.1.pdf
|
||||
|
||||
@ -51,7 +51,7 @@ if major >= 3:
|
||||
support for Sphinx v3.0 and above is brand new. Be prepared for
|
||||
possible issues in the generated output.
|
||||
''')
|
||||
if minor > 0 or patch >= 2:
|
||||
if (major > 3) or (minor > 0 or patch >= 2):
|
||||
# Sphinx c function parser is more pedantic with regards to type
|
||||
# checking. Due to that, having macros at c:function cause problems.
|
||||
# Those needed to be scaped by using c_id_attributes[] array
|
||||
|
||||
@ -295,11 +295,13 @@ print the number of the test and the status of the test:
|
||||
pass::
|
||||
|
||||
ok 28 - kmalloc_double_kzfree
|
||||
|
||||
or, if kmalloc failed::
|
||||
|
||||
# kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163
|
||||
Expected ptr is not null, but is
|
||||
not ok 4 - kmalloc_large_oob_right
|
||||
|
||||
or, if a KASAN report was expected, but not found::
|
||||
|
||||
# kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629
|
||||
|
||||
@ -90,7 +90,7 @@ things to try.
|
||||
re-run kunit_tool.
|
||||
5. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This
|
||||
may help clean up any residual config items which could be causing problems.
|
||||
6. Finally, try running KUnit outside UML. KUnit and KUnit tests can run be
|
||||
6. Finally, try running KUnit outside UML. KUnit and KUnit tests can be
|
||||
built into any kernel, or can be built as a module and loaded at runtime.
|
||||
Doing so should allow you to determine if UML is causing the issue you're
|
||||
seeing. When tests are built-in, they will execute when the kernel boots, and
|
||||
|
||||
@ -197,7 +197,7 @@ Now add the following to ``drivers/misc/Kconfig``:
|
||||
|
||||
config MISC_EXAMPLE_TEST
|
||||
bool "Test for my example"
|
||||
depends on MISC_EXAMPLE && KUNIT
|
||||
depends on MISC_EXAMPLE && KUNIT=y
|
||||
|
||||
and the following to ``drivers/misc/Makefile``:
|
||||
|
||||
|
||||
@ -175,17 +175,17 @@ An example Kconfig entry:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
config FOO_KUNIT_TEST
|
||||
tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
|
||||
depends on KUNIT
|
||||
default KUNIT_ALL_TESTS
|
||||
help
|
||||
This builds unit tests for foo.
|
||||
config FOO_KUNIT_TEST
|
||||
tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
|
||||
depends on KUNIT
|
||||
default KUNIT_ALL_TESTS
|
||||
help
|
||||
This builds unit tests for foo.
|
||||
|
||||
For more information on KUnit and unit tests in general, please refer
|
||||
to the KUnit documentation in Documentation/dev-tools/kunit
|
||||
For more information on KUnit and unit tests in general, please refer
|
||||
to the KUnit documentation in Documentation/dev-tools/kunit/.
|
||||
|
||||
If unsure, say N
|
||||
If unsure, say N.
|
||||
|
||||
|
||||
Test File and Module Names
|
||||
|
||||
@ -92,7 +92,7 @@ behavior of a function called ``add``; the first parameter is always of type
|
||||
the second parameter, in this case, is what the value is expected to be; the
|
||||
last value is what the value actually is. If ``add`` passes all of these
|
||||
expectations, the test case, ``add_test_basic`` will pass; if any one of these
|
||||
expectations fail, the test case will fail.
|
||||
expectations fails, the test case will fail.
|
||||
|
||||
It is important to understand that a test case *fails* when any expectation is
|
||||
violated; however, the test will continue running, potentially trying other
|
||||
@ -202,7 +202,7 @@ Example:
|
||||
kunit_test_suite(example_test_suite);
|
||||
|
||||
In the above example the test suite, ``example_test_suite``, would run the test
|
||||
cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``,
|
||||
cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``;
|
||||
each would have ``example_test_init`` called immediately before it and would
|
||||
have ``example_test_exit`` called immediately after it.
|
||||
``kunit_test_suite(example_test_suite)`` registers the test suite with the
|
||||
@ -229,7 +229,7 @@ through some sort of indirection where a function is exposed as part of an API
|
||||
such that the definition of that function can be changed without affecting the
|
||||
rest of the code base. In the kernel this primarily comes from two constructs,
|
||||
classes, structs that contain function pointers that are provided by the
|
||||
implementer, and architecture specific functions which have definitions selected
|
||||
implementer, and architecture-specific functions which have definitions selected
|
||||
at compile time.
|
||||
|
||||
Classes
|
||||
@ -459,7 +459,7 @@ KUnit on non-UML architectures
|
||||
By default KUnit uses UML as a way to provide dependencies for code under test.
|
||||
Under most circumstances KUnit's usage of UML should be treated as an
|
||||
implementation detail of how KUnit works under the hood. Nevertheless, there
|
||||
are instances where being able to run architecture specific code or test
|
||||
are instances where being able to run architecture-specific code or test
|
||||
against real hardware is desirable. For these reasons KUnit supports running on
|
||||
other architectures.
|
||||
|
||||
@ -561,6 +561,11 @@ Once the kernel is built and installed, a simple
|
||||
|
||||
...will run the tests.
|
||||
|
||||
.. note::
|
||||
Note that you should make sure your test depends on ``KUNIT=y`` in Kconfig
|
||||
if the test does not support module build. Otherwise, it will trigger
|
||||
compile errors if ``CONFIG_KUNIT`` is ``m``.
|
||||
|
||||
Writing new tests for other architectures
|
||||
-----------------------------------------
|
||||
|
||||
@ -594,7 +599,7 @@ writing normal KUnit tests. One special caveat is that you have to reset
|
||||
hardware state in between test cases; if this is not possible, you may only be
|
||||
able to run one test case per invocation.
|
||||
|
||||
.. TODO(brendanhiggins@google.com): Add an actual example of an architecture
|
||||
.. TODO(brendanhiggins@google.com): Add an actual example of an architecture-
|
||||
dependent KUnit test.
|
||||
|
||||
KUnit debugfs representation
|
||||
|
||||
@ -4,7 +4,7 @@ Clock control registers reside in different Hi6220 system controllers,
|
||||
please refer the following document to know more about the binding rules
|
||||
for these system controllers:
|
||||
|
||||
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
|
||||
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
||||
@ -57,7 +57,7 @@ examples:
|
||||
};
|
||||
|
||||
can@53fc8000 {
|
||||
compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan";
|
||||
compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan";
|
||||
reg = <0x53fc8000 0x4000>;
|
||||
interrupts = <82>;
|
||||
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>;
|
||||
|
||||
@ -76,6 +76,12 @@ properties:
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
wifi-2.4ghz-coexistence:
|
||||
type: boolean
|
||||
description: >
|
||||
Should the pixel frequencies in the WiFi frequencies range be
|
||||
avoided?
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -1,6 +1,7 @@
|
||||
* Freescale Layerscape external IRQs
|
||||
|
||||
Some Layerscape SOCs (LS1021A, LS1043A, LS1046A) support inverting
|
||||
Some Layerscape SOCs (LS1021A, LS1043A, LS1046A
|
||||
LS1088A, LS208xA, LX216xA) support inverting
|
||||
the polarity of certain external interrupt lines.
|
||||
|
||||
The device node must be a child of the node representing the
|
||||
@ -8,12 +9,15 @@ Supplemental Configuration Unit (SCFG).
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "fsl,<soc-name>-extirq", e.g. "fsl,ls1021a-extirq".
|
||||
"fsl,ls1043a-extirq": for LS1043A, LS1046A.
|
||||
"fsl,ls1088a-extirq": for LS1088A, LS208xA, LX216xA.
|
||||
- #interrupt-cells: Must be 2. The first element is the index of the
|
||||
external interrupt line. The second element is the trigger type.
|
||||
- #address-cells: Must be 0.
|
||||
- interrupt-controller: Identifies the node as an interrupt controller
|
||||
- reg: Specifies the Interrupt Polarity Control Register (INTPCR) in
|
||||
the SCFG.
|
||||
the SCFG or the External Interrupt Control Register (IRQCR) in
|
||||
the ISC.
|
||||
- interrupt-map: Specifies the mapping from external interrupts to GIC
|
||||
interrupts.
|
||||
- interrupt-map-mask: Must be <0xffffffff 0>.
|
||||
|
||||
@ -1,21 +0,0 @@
|
||||
Microsemi Ocelot SoC ICPU Interrupt Controller
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "mscc,ocelot-icpu-intr"
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The value shall be 1.
|
||||
- interrupts : Specifies the CPU interrupt the controller is connected to.
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@70000070 {
|
||||
compatible = "mscc,ocelot-icpu-intr";
|
||||
reg = <0x70000070 0x70>;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-controller;
|
||||
interrupt-parent = <&cpuintc>;
|
||||
interrupts = <2>;
|
||||
};
|
||||
@ -0,0 +1,64 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Microsemi Ocelot SoC ICPU Interrupt Controller
|
||||
|
||||
maintainers:
|
||||
- Alexandre Belloni <alexandre.belloni@bootlin.com>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/interrupt-controller.yaml#
|
||||
|
||||
description: |
|
||||
the Microsemi Ocelot interrupt controller that is part of the
|
||||
ICPU. It is connected directly to the MIPS core interrupt
|
||||
controller.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- mscc,jaguar2-icpu-intr
|
||||
- mscc,luton-icpu-intr
|
||||
- mscc,ocelot-icpu-intr
|
||||
- mscc,serval-icpu-intr
|
||||
|
||||
|
||||
'#interrupt-cells':
|
||||
const: 1
|
||||
|
||||
'#address-cells':
|
||||
const: 0
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- '#interrupt-cells'
|
||||
- '#address-cells'
|
||||
- interrupt-controller
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
intc: interrupt-controller@70000070 {
|
||||
compatible = "mscc,ocelot-icpu-intr";
|
||||
reg = <0x70000070 0x70>;
|
||||
#interrupt-cells = <1>;
|
||||
#address-cells = <0>;
|
||||
interrupt-controller;
|
||||
interrupt-parent = <&cpuintc>;
|
||||
interrupts = <2>;
|
||||
};
|
||||
...
|
||||
@ -32,6 +32,11 @@ description: |
|
||||
| | vint | bit | | 0 |.....|63| vintx |
|
||||
| +--------------+ +------------+ |
|
||||
| |
|
||||
| Unmap |
|
||||
| +--------------+ |
|
||||
Unmapped events ---->| | umapidx |-------------------------> Globalevents
|
||||
| +--------------+ |
|
||||
| |
|
||||
+-----------------------------------------+
|
||||
|
||||
Configuration of these Intmap registers that maps global events to vint is
|
||||
@ -70,6 +75,11 @@ properties:
|
||||
- description: |
|
||||
"limit" specifies the limit for translation
|
||||
|
||||
ti,unmapped-event-sources:
|
||||
$ref: /schemas/types.yaml#definitions/phandle-array
|
||||
description:
|
||||
Array of phandles to DMA controllers where the unmapped events originate.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -0,0 +1,18 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/can/can-controller.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: CAN Controller Generic Binding
|
||||
|
||||
maintainers:
|
||||
- Marc Kleine-Budde <mkl@pengutronix.de>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: "^can(@.*)?$"
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
...
|
||||
139
Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
Normal file
139
Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
Normal file
@ -0,0 +1,139 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/can/fsl,flexcan.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title:
|
||||
Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
|
||||
|
||||
maintainers:
|
||||
- Marc Kleine-Budde <mkl@pengutronix.de>
|
||||
|
||||
allOf:
|
||||
- $ref: can-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- enum:
|
||||
- fsl,imx8qm-flexcan
|
||||
- fsl,imx8mp-flexcan
|
||||
- fsl,imx6q-flexcan
|
||||
- fsl,imx28-flexcan
|
||||
- fsl,imx25-flexcan
|
||||
- fsl,p1010-flexcan
|
||||
- fsl,vf610-flexcan
|
||||
- fsl,ls1021ar2-flexcan
|
||||
- fsl,lx2160ar1-flexcan
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx53-flexcan
|
||||
- fsl,imx35-flexcan
|
||||
- const: fsl,imx25-flexcan
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx7d-flexcan
|
||||
- fsl,imx6ul-flexcan
|
||||
- fsl,imx6sx-flexcan
|
||||
- const: fsl,imx6q-flexcan
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,ls1028ar1-flexcan
|
||||
- const: fsl,lx2160ar1-flexcan
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ipg
|
||||
- const: per
|
||||
|
||||
clock-frequency:
|
||||
description: |
|
||||
The oscillator frequency driving the flexcan device, filled in by the
|
||||
boot loader. This property should only be used the used operating system
|
||||
doesn't support the clocks and clock-names property.
|
||||
|
||||
xceiver-supply:
|
||||
description: Regulator that powers the CAN transceiver.
|
||||
|
||||
big-endian:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description: |
|
||||
This means the registers of FlexCAN controller are big endian. This is
|
||||
optional property.i.e. if this property is not present in device tree
|
||||
node then controller is assumed to be little endian. If this property is
|
||||
present then controller is assumed to be big endian.
|
||||
|
||||
fsl,stop-mode:
|
||||
description: |
|
||||
Register bits of stop mode control.
|
||||
|
||||
The format should be as follows:
|
||||
<gpr req_gpr req_bit>
|
||||
gpr is the phandle to general purpose register node.
|
||||
req_gpr is the gpr register offset of CAN stop request.
|
||||
req_bit is the bit offset of CAN stop request.
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
items:
|
||||
items:
|
||||
- description: The 'gpr' is the phandle to general purpose register node.
|
||||
- description: The 'req_gpr' is the gpr register offset of CAN stop request.
|
||||
maximum: 0xff
|
||||
- description: The 'req_bit' is the bit offset of CAN stop request.
|
||||
maximum: 0x1f
|
||||
|
||||
fsl,clk-source:
|
||||
description: |
|
||||
Select the clock source to the CAN Protocol Engine (PE). It's SoC
|
||||
implementation dependent. Refer to RM for detailed definition. If this
|
||||
property is not set in device tree node then driver selects clock source 1
|
||||
by default.
|
||||
0: clock source 0 (oscillator clock)
|
||||
1: clock source 1 (peripheral clock)
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
default: 1
|
||||
minimum: 0
|
||||
maximum: 1
|
||||
|
||||
wakeup-source:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Enable CAN remote wakeup.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
can@1c000 {
|
||||
compatible = "fsl,p1010-flexcan";
|
||||
reg = <0x1c000 0x1000>;
|
||||
interrupts = <48 0x2>;
|
||||
interrupt-parent = <&mpic>;
|
||||
clock-frequency = <200000000>;
|
||||
fsl,clk-source = <0>;
|
||||
};
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
can@2090000 {
|
||||
compatible = "fsl,imx6q-flexcan";
|
||||
reg = <0x02090000 0x4000>;
|
||||
interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&clks 1>, <&clks 2>;
|
||||
clock-names = "ipg", "per";
|
||||
fsl,stop-mode = <&gpr 0x34 28>;
|
||||
};
|
||||
@ -1,57 +0,0 @@
|
||||
Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "fsl,<processor>-flexcan"
|
||||
|
||||
where <processor> is imx8qm, imx6q, imx28, imx53, imx35, imx25, p1010,
|
||||
vf610, ls1021ar2, lx2160ar1, ls1028ar1.
|
||||
|
||||
The ls1028ar1 must be followed by lx2160ar1, e.g.
|
||||
- "fsl,ls1028ar1-flexcan", "fsl,lx2160ar1-flexcan"
|
||||
|
||||
An implementation should also claim any of the following compatibles
|
||||
that it is fully backwards compatible with:
|
||||
|
||||
- fsl,p1010-flexcan
|
||||
|
||||
- reg : Offset and length of the register set for this device
|
||||
- interrupts : Interrupt tuple for this device
|
||||
|
||||
Optional properties:
|
||||
|
||||
- clock-frequency : The oscillator frequency driving the flexcan device
|
||||
|
||||
- xceiver-supply: Regulator that powers the CAN transceiver
|
||||
|
||||
- big-endian: This means the registers of FlexCAN controller are big endian.
|
||||
This is optional property.i.e. if this property is not present in
|
||||
device tree node then controller is assumed to be little endian.
|
||||
if this property is present then controller is assumed to be big
|
||||
endian.
|
||||
|
||||
- fsl,stop-mode: register bits of stop mode control, the format is
|
||||
<&gpr req_gpr req_bit>.
|
||||
gpr is the phandle to general purpose register node.
|
||||
req_gpr is the gpr register offset of CAN stop request.
|
||||
req_bit is the bit offset of CAN stop request.
|
||||
|
||||
- fsl,clk-source: Select the clock source to the CAN Protocol Engine (PE).
|
||||
It's SoC Implementation dependent. Refer to RM for detailed
|
||||
definition. If this property is not set in device tree node
|
||||
then driver selects clock source 1 by default.
|
||||
0: clock source 0 (oscillator clock)
|
||||
1: clock source 1 (peripheral clock)
|
||||
|
||||
- wakeup-source: enable CAN remote wakeup
|
||||
|
||||
Example:
|
||||
|
||||
can@1c000 {
|
||||
compatible = "fsl,p1010-flexcan";
|
||||
reg = <0x1c000 0x1000>;
|
||||
interrupts = <48 0x2>;
|
||||
interrupt-parent = <&mpic>;
|
||||
clock-frequency = <200000000>; // filled in by bootloader
|
||||
fsl,clk-source = <0>; // select clock source 0 for PE
|
||||
};
|
||||
@ -8,10 +8,16 @@ Required properties:
|
||||
|
||||
- reg : The I2C address of the device.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- realtek,power-up-delay-ms
|
||||
Set a delay time for flush work to be completed,
|
||||
this value is adjustable depending on platform.
|
||||
|
||||
Example:
|
||||
|
||||
rt1015: codec@28 {
|
||||
compatible = "realtek,rt1015";
|
||||
reg = <0x28>;
|
||||
realtek,power-up-delay-ms = <50>;
|
||||
};
|
||||
|
||||
@ -149,11 +149,11 @@ vidtv_psi.[ch]
|
||||
Because the generator is implemented in a separate file, it can be
|
||||
reused elsewhere in the media subsystem.
|
||||
|
||||
Currently vidtv supports working with 3 PSI tables: PAT, PMT and
|
||||
SDT.
|
||||
Currently vidtv supports working with 5 PSI tables: PAT, PMT,
|
||||
SDT, NIT and EIT.
|
||||
|
||||
The specification for PAT and PMT can be found in *ISO 13818-1:
|
||||
Systems*, while the specification for the SDT can be found in *ETSI
|
||||
Systems*, while the specification for the SDT, NIT, EIT can be found in *ETSI
|
||||
EN 300 468: Specification for Service Information (SI) in DVB
|
||||
systems*.
|
||||
|
||||
@ -197,6 +197,8 @@ vidtv_channel.[ch]
|
||||
|
||||
#. Their programs will be concatenated to populate the PAT
|
||||
|
||||
#. Their events will be concatenated to populate the EIT
|
||||
|
||||
#. For each program in the PAT, a PMT section will be created
|
||||
|
||||
#. The PMT section for a channel will be assigned its streams.
|
||||
@ -256,6 +258,42 @@ Using dvb-fe-tool
|
||||
The first step to check whether the demod loaded successfully is to run::
|
||||
|
||||
$ dvb-fe-tool
|
||||
Device Dummy demod for DVB-T/T2/C/S/S2 (/dev/dvb/adapter0/frontend0) capabilities:
|
||||
CAN_FEC_1_2
|
||||
CAN_FEC_2_3
|
||||
CAN_FEC_3_4
|
||||
CAN_FEC_4_5
|
||||
CAN_FEC_5_6
|
||||
CAN_FEC_6_7
|
||||
CAN_FEC_7_8
|
||||
CAN_FEC_8_9
|
||||
CAN_FEC_AUTO
|
||||
CAN_GUARD_INTERVAL_AUTO
|
||||
CAN_HIERARCHY_AUTO
|
||||
CAN_INVERSION_AUTO
|
||||
CAN_QAM_16
|
||||
CAN_QAM_32
|
||||
CAN_QAM_64
|
||||
CAN_QAM_128
|
||||
CAN_QAM_256
|
||||
CAN_QAM_AUTO
|
||||
CAN_QPSK
|
||||
CAN_TRANSMISSION_MODE_AUTO
|
||||
DVB API Version 5.11, Current v5 delivery system: DVBC/ANNEX_A
|
||||
Supported delivery systems:
|
||||
DVBT
|
||||
DVBT2
|
||||
[DVBC/ANNEX_A]
|
||||
DVBS
|
||||
DVBS2
|
||||
Frequency range for the current standard:
|
||||
From: 51.0 MHz
|
||||
To: 2.15 GHz
|
||||
Step: 62.5 kHz
|
||||
Tolerance: 29.5 MHz
|
||||
Symbol rate ranges for the current standard:
|
||||
From: 1.00 MBauds
|
||||
To: 45.0 MBauds
|
||||
|
||||
This should return what is currently set up at the demod struct, i.e.::
|
||||
|
||||
@ -314,7 +352,7 @@ For this, one should provide a configuration file known as a 'scan file',
|
||||
here's an example::
|
||||
|
||||
[Channel]
|
||||
FREQUENCY = 330000000
|
||||
FREQUENCY = 474000000
|
||||
MODULATION = QAM/AUTO
|
||||
SYMBOL_RATE = 6940000
|
||||
INNER_FEC = AUTO
|
||||
@ -335,6 +373,14 @@ You can browse scan tables online here: `dvb-scan-tables
|
||||
Assuming this channel is named 'channel.conf', you can then run::
|
||||
|
||||
$ dvbv5-scan channel.conf
|
||||
dvbv5-scan ~/vidtv.conf
|
||||
ERROR command BANDWIDTH_HZ (5) not found during retrieve
|
||||
Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet).
|
||||
Scanning frequency #1 330000000
|
||||
(0x00) Signal= -68.00dBm
|
||||
Scanning frequency #2 474000000
|
||||
Lock (0x1f) Signal= -34.45dBm C/N= 33.74dB UCB= 0
|
||||
Service Beethoven, provider LinuxTV.org: digital television
|
||||
|
||||
For more information on dvb-scan, check its documentation online here:
|
||||
`dvb-scan Documentation <https://www.linuxtv.org/wiki/index.php/Dvbscan>`_.
|
||||
@ -344,23 +390,38 @@ Using dvb-zap
|
||||
|
||||
dvbv5-zap is a command line tool that can be used to record MPEG-TS to disk. The
|
||||
typical use is to tune into a channel and put it into record mode. The example
|
||||
below - which is taken from the documentation - illustrates that::
|
||||
below - which is taken from the documentation - illustrates that\ [1]_::
|
||||
|
||||
$ dvbv5-zap -c dvb_channel.conf "trilhas sonoras" -r
|
||||
using demux '/dev/dvb/adapter0/demux0'
|
||||
$ dvbv5-zap -c dvb_channel.conf "beethoven" -o music.ts -P -t 10
|
||||
using demux 'dvb0.demux0'
|
||||
reading channels from file 'dvb_channel.conf'
|
||||
service has pid type 05: 204
|
||||
tuning to 573000000 Hz
|
||||
audio pid 104
|
||||
dvb_set_pesfilter 104
|
||||
Lock (0x1f) Quality= Good Signal= 100.00% C/N= -13.80dB UCB= 70 postBER= 3.14x10^-3 PER= 0
|
||||
DVR interface '/dev/dvb/adapter0/dvr0' can now be opened
|
||||
tuning to 474000000 Hz
|
||||
pass all PID's to TS
|
||||
dvb_set_pesfilter 8192
|
||||
dvb_dev_set_bufsize: buffer set to 6160384
|
||||
Lock (0x1f) Quality= Good Signal= -34.66dBm C/N= 33.41dB UCB= 0 postBER= 0 preBER= 1.05x10^-3 PER= 0
|
||||
Lock (0x1f) Quality= Good Signal= -34.57dBm C/N= 33.46dB UCB= 0 postBER= 0 preBER= 1.05x10^-3 PER= 0
|
||||
Record to file 'music.ts' started
|
||||
received 24587768 bytes (2401 Kbytes/sec)
|
||||
Lock (0x1f) Quality= Good Signal= -34.42dBm C/N= 33.89dB UCB= 0 postBER= 0 preBER= 2.44x10^-3 PER= 0
|
||||
|
||||
The channel can be watched by playing the contents of the DVR interface, with
|
||||
some player that recognizes the MPEG-TS format, such as *mplayer* or *vlc*.
|
||||
.. [1] In this example, it records 10 seconds with all program ID's stored
|
||||
at the music.ts file.
|
||||
|
||||
|
||||
The channel can be watched by playing the contents of the stream with some
|
||||
player that recognizes the MPEG-TS format, such as ``mplayer`` or ``vlc``.
|
||||
|
||||
By playing the contents of the stream one can visually inspect the workings of
|
||||
vidtv, e.g.::
|
||||
vidtv, e.g., to play a recorded TS file with::
|
||||
|
||||
$ mplayer music.ts
|
||||
|
||||
or, alternatively, running this command on one terminal::
|
||||
|
||||
$ dvbv5-zap -c dvb_channel.conf "beethoven" -P -r &
|
||||
|
||||
And, on a second terminal, playing the contents from DVR interface with::
|
||||
|
||||
$ mplayer /dev/dvb/adapter0/dvr0
|
||||
|
||||
@ -423,3 +484,30 @@ A nice addition is to simulate some noise when the signal quality is bad by:
|
||||
- Updating the error statistics accordingly (e.g. BER, etc).
|
||||
|
||||
- Simulating some noise in the encoded data.
|
||||
|
||||
Functions and structs used within vidtv
|
||||
---------------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_bridge.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_channel.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_demod.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_encoder.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_mux.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_pes.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_psi.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_s302m.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_ts.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_tuner.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_common.c
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_tuner.c
|
||||
|
||||
@ -86,9 +86,6 @@ Other Functions
|
||||
.. kernel-doc:: fs/dax.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: fs/direct-io.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: fs/libfs.c
|
||||
:export:
|
||||
|
||||
|
||||
@ -256,6 +256,10 @@ which is 1024 bytes long:
|
||||
- s\_padding2
|
||||
-
|
||||
* - 0x54
|
||||
- \_\_be32
|
||||
- s\_num\_fc\_blocks
|
||||
- Number of fast commit blocks in the journal.
|
||||
* - 0x58
|
||||
- \_\_u32
|
||||
- s\_padding[42]
|
||||
-
|
||||
@ -310,6 +314,8 @@ The journal incompat features are any combination of the following:
|
||||
- This journal uses v3 of the checksum on-disk format. This is the same as
|
||||
v2, but the journal block tag size is fixed regardless of the size of
|
||||
block numbers. (JBD2\_FEATURE\_INCOMPAT\_CSUM\_V3)
|
||||
* - 0x20
|
||||
- Journal has fast commit blocks. (JBD2\_FEATURE\_INCOMPAT\_FAST\_COMMIT)
|
||||
|
||||
.. _jbd2_checksum_type:
|
||||
|
||||
|
||||
@ -596,6 +596,13 @@ following:
|
||||
- Sparse Super Block, v2. If this flag is set, the SB field s\_backup\_bgs
|
||||
points to the two block groups that contain backup superblocks
|
||||
(COMPAT\_SPARSE\_SUPER2).
|
||||
* - 0x400
|
||||
- Fast commits supported. Although fast commits blocks are
|
||||
backward incompatible, fast commit blocks are not always
|
||||
present in the journal. If fast commit blocks are present in
|
||||
the journal, JBD2 incompat feature
|
||||
(JBD2\_FEATURE\_INCOMPAT\_FAST\_COMMIT) gets
|
||||
set (COMPAT\_FAST\_COMMIT).
|
||||
|
||||
.. _super_incompat:
|
||||
|
||||
|
||||
@ -136,10 +136,8 @@ Fast commits
|
||||
~~~~~~~~~~~~
|
||||
|
||||
JBD2 to also allows you to perform file-system specific delta commits known as
|
||||
fast commits. In order to use fast commits, you first need to call
|
||||
:c:func:`jbd2_fc_init` and tell how many blocks at the end of journal
|
||||
area should be reserved for fast commits. Along with that, you will also need
|
||||
to set following callbacks that perform correspodning work:
|
||||
fast commits. In order to use fast commits, you will need to set following
|
||||
callbacks that perform correspodning work:
|
||||
|
||||
`journal->j_fc_cleanup_cb`: Cleanup function called after every full commit and
|
||||
fast commit.
|
||||
|
||||
@ -19,9 +19,9 @@ report the "current" state of the lid as either "opened" or "closed".
|
||||
|
||||
For most platforms, both the _LID method and the lid notifications are
|
||||
reliable. However, there are exceptions. In order to work with these
|
||||
exceptional buggy platforms, special restrictions and expections should be
|
||||
exceptional buggy platforms, special restrictions and exceptions should be
|
||||
taken into account. This document describes the restrictions and the
|
||||
expections of the Linux ACPI lid device driver.
|
||||
exceptions of the Linux ACPI lid device driver.
|
||||
|
||||
|
||||
Restrictions of the returning value of the _LID control method
|
||||
@ -46,7 +46,7 @@ state is changed to "closed". The "closed" notification is normally used to
|
||||
trigger some system power saving operations on Windows. Since it is fully
|
||||
tested, it is reliable from all AML tables.
|
||||
|
||||
Expections for the userspace users of the ACPI lid device driver
|
||||
Exceptions for the userspace users of the ACPI lid device driver
|
||||
================================================================
|
||||
|
||||
The ACPI button driver exports the lid state to the userspace via the
|
||||
@ -100,7 +100,7 @@ use the following kernel parameter:
|
||||
C. button.lid_init_state=ignore:
|
||||
When this option is specified, the ACPI button driver never reports the
|
||||
initial lid state and there is a compensation mechanism implemented to
|
||||
ensure that the reliable "closed" notifications can always be delievered
|
||||
ensure that the reliable "closed" notifications can always be delivered
|
||||
to the userspace by always pairing "closed" input events with complement
|
||||
"opened" input events. But there is still no guarantee that the "opened"
|
||||
notifications can be delivered to the userspace when the lid is actually
|
||||
|
||||
@ -20,9 +20,9 @@ index, like the ASL example below shows::
|
||||
|
||||
Name (_CRS, ResourceTemplate ()
|
||||
{
|
||||
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
|
||||
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
|
||||
"\\_SB.GPO0", 0, ResourceConsumer) {15}
|
||||
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
|
||||
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
|
||||
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
|
||||
})
|
||||
|
||||
@ -49,15 +49,41 @@ index
|
||||
pin
|
||||
Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
|
||||
active_low
|
||||
If 1 the GPIO is marked as active_low.
|
||||
If 1, the GPIO is marked as active_low.
|
||||
|
||||
Since ACPI GpioIo() resource does not have a field saying whether it is
|
||||
active low or high, the "active_low" argument can be used here. Setting
|
||||
it to 1 marks the GPIO as active low.
|
||||
|
||||
Note, active_low in _DSD does not make sense for GpioInt() resource and
|
||||
must be 0. GpioInt() resource has its own means of defining it.
|
||||
|
||||
In our Bluetooth example the "reset-gpios" refers to the second GpioIo()
|
||||
resource, second pin in that resource with the GPIO number of 31.
|
||||
|
||||
The GpioIo() resource unfortunately doesn't explicitly provide an initial
|
||||
state of the output pin which driver should use during its initialization.
|
||||
|
||||
Linux tries to use common sense here and derives the state from the bias
|
||||
and polarity settings. The table below shows the expectations:
|
||||
|
||||
========= ============= ==============
|
||||
Pull Bias Polarity Requested...
|
||||
========= ============= ==============
|
||||
Implicit x AS IS (assumed firmware configured for us)
|
||||
Explicit x (no _DSD) as Pull Bias (Up == High, Down == Low),
|
||||
assuming non-active (Polarity = !Pull Bias)
|
||||
Down Low as low, assuming active
|
||||
Down High as low, assuming non-active
|
||||
Up Low as high, assuming non-active
|
||||
Up High as high, assuming active
|
||||
========= ============= ==============
|
||||
|
||||
That said, for our above example the both GPIOs, since the bias setting
|
||||
is explicit and _DSD is present, will be treated as active with a high
|
||||
polarity and Linux will configure the pins in this state until a driver
|
||||
reprograms them differently.
|
||||
|
||||
It is possible to leave holes in the array of GPIOs. This is useful in
|
||||
cases like with SPI host controllers where some chip selects may be
|
||||
implemented as GPIOs and some as native signals. For example a SPI host
|
||||
@ -112,8 +138,8 @@ Example::
|
||||
Package () {
|
||||
"gpio-line-names",
|
||||
Package () {
|
||||
"SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD", "MUX7_IO",
|
||||
"LVL_C_A1", "MUX0_IO", "SPI1_MISO"
|
||||
"SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD",
|
||||
"MUX7_IO", "LVL_C_A1", "MUX0_IO", "SPI1_MISO",
|
||||
}
|
||||
}
|
||||
|
||||
@ -137,7 +163,7 @@ to the GPIO lines it is going to use and provide the GPIO subsystem with a
|
||||
mapping between those names and the ACPI GPIO resources corresponding to them.
|
||||
|
||||
To do that, the driver needs to define a mapping table as a NULL-terminated
|
||||
array of struct acpi_gpio_mapping objects that each contain a name, a pointer
|
||||
array of struct acpi_gpio_mapping objects that each contains a name, a pointer
|
||||
to an array of line data (struct acpi_gpio_params) objects and the size of that
|
||||
array. Each struct acpi_gpio_params object consists of three fields,
|
||||
crs_entry_index, line_index, active_low, representing the index of the target
|
||||
@ -154,13 +180,14 @@ question would look like this::
|
||||
static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
|
||||
{ "reset-gpios", &reset_gpio, 1 },
|
||||
{ "shutdown-gpios", &shutdown_gpio, 1 },
|
||||
{ },
|
||||
{ }
|
||||
};
|
||||
|
||||
Next, the mapping table needs to be passed as the second argument to
|
||||
acpi_dev_add_driver_gpios() that will register it with the ACPI device object
|
||||
pointed to by its first argument. That should be done in the driver's .probe()
|
||||
routine. On removal, the driver should unregister its GPIO mapping table by
|
||||
acpi_dev_add_driver_gpios() or its managed analogue that will
|
||||
register it with the ACPI device object pointed to by its first
|
||||
argument. That should be done in the driver's .probe() routine.
|
||||
On removal, the driver should unregister its GPIO mapping table by
|
||||
calling acpi_dev_remove_driver_gpios() on the ACPI device object where that
|
||||
table was previously registered.
|
||||
|
||||
@ -191,12 +218,12 @@ The driver might expect to get the right GPIO when it does::
|
||||
but since there is no way to know the mapping between "reset" and
|
||||
the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT).
|
||||
|
||||
The driver author can solve this by passing the mapping explictly
|
||||
(the recommended way and documented in the above chapter).
|
||||
The driver author can solve this by passing the mapping explicitly
|
||||
(this is the recommended way and it's documented in the above chapter).
|
||||
|
||||
The ACPI GPIO mapping tables should not contaminate drivers that are not
|
||||
knowing about which exact device they are servicing on. It implies that
|
||||
the ACPI GPIO mapping tables are hardly linked to ACPI ID and certain
|
||||
the ACPI GPIO mapping tables are hardly linked to an ACPI ID and certain
|
||||
objects, as listed in the above chapter, of the device in question.
|
||||
|
||||
Getting GPIO descriptor
|
||||
@ -229,5 +256,5 @@ Case 2 explicitly tells GPIO core to look for resources in _CRS.
|
||||
Be aware that gpiod_get_index() in cases 1 and 2, assuming that there
|
||||
are two versions of ACPI device description provided and no mapping is
|
||||
present in the driver, will return different resources. That's why a
|
||||
certain driver has to handle them carefully as explained in previous
|
||||
certain driver has to handle them carefully as explained in the previous
|
||||
chapter.
|
||||
|
||||
@ -98,7 +98,7 @@ subject to change::
|
||||
[ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution.
|
||||
|
||||
Developers can utilize these special log entries to track the AML
|
||||
interpretion, thus can aid issue debugging and performance tuning. Note
|
||||
interpretation, thus can aid issue debugging and performance tuning. Note
|
||||
that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT()
|
||||
macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling
|
||||
"AML tracer" logs.
|
||||
|
||||
@ -83,10 +83,6 @@ AMDGPU XGMI Support
|
||||
===================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
|
||||
:doc: AMDGPU XGMI Support
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
|
||||
:internal:
|
||||
|
||||
AMDGPU RAS Support
|
||||
==================
|
||||
@ -124,9 +120,6 @@ RAS VRAM Bad Pages sysfs Interface
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
|
||||
:doc: AMDGPU RAS sysfs gpu_vram_bad_pages Interface
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
|
||||
:internal:
|
||||
|
||||
Sample Code
|
||||
-----------
|
||||
Sample code for testing error injection can be found here:
|
||||
|
||||
@ -20,7 +20,7 @@ ADM1266 is a sequencer that features voltage readback from 17 channels via an
|
||||
integrated 12 bit SAR ADC, accessed using a PMBus interface.
|
||||
|
||||
The driver is a client driver to the core PMBus driver. Please see
|
||||
Documentation/hwmon/pmbus for details on PMBus client drivers.
|
||||
Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
|
||||
|
||||
|
||||
Sysfs entries
|
||||
|
||||
@ -132,6 +132,7 @@ Hardware Monitoring Kernel Drivers
|
||||
mcp3021
|
||||
menf21bmc
|
||||
mlxreg-fan
|
||||
mp2975
|
||||
nct6683
|
||||
nct6775
|
||||
nct7802
|
||||
|
||||
@ -20,6 +20,7 @@ This driver implements support for Monolithic Power Systems, Inc. (MPS)
|
||||
vendor dual-loop, digital, multi-phase controller MP2975.
|
||||
|
||||
This device:
|
||||
|
||||
- Supports up to two power rail.
|
||||
- Provides 8 pulse-width modulations (PWMs), and can be configured up
|
||||
to 8-phase operation for rail 1 and up to 4-phase operation for rail
|
||||
@ -32,10 +33,12 @@ This device:
|
||||
10-mV DAC, IMVP9 mode with 5-mV DAC.
|
||||
|
||||
Device supports:
|
||||
|
||||
- SVID interface.
|
||||
- AVSBus interface.
|
||||
|
||||
Device complaint with:
|
||||
|
||||
- PMBus rev 1.3 interface.
|
||||
|
||||
Device supports direct format for reading output current, output voltage,
|
||||
@ -45,11 +48,14 @@ Device supports VID and direct formats for reading output voltage.
|
||||
The below VID modes are supported: VR12, VR13, IMVP9.
|
||||
|
||||
The driver provides the next attributes for the current:
|
||||
|
||||
- for current in: input, maximum alarm;
|
||||
- for current out input, maximum alarm and highest values;
|
||||
- for phase current: input and label.
|
||||
attributes.
|
||||
attributes.
|
||||
|
||||
The driver exports the following attributes via the 'sysfs' files, where
|
||||
|
||||
- 'n' is number of telemetry pages (from 1 to 2);
|
||||
- 'k' is number of configured phases (from 1 to 8);
|
||||
- indexes 1, 1*n for "iin";
|
||||
@ -65,11 +71,14 @@ The driver exports the following attributes via the 'sysfs' files, where
|
||||
**curr[1-{2n+k}]_label**
|
||||
|
||||
The driver provides the next attributes for the voltage:
|
||||
|
||||
- for voltage in: input, high critical threshold, high critical alarm, all only
|
||||
from page 0;
|
||||
- for voltage out: input, low and high critical thresholds, low and high
|
||||
critical alarms, from pages 0 and 1;
|
||||
|
||||
The driver exports the following attributes via the 'sysfs' files, where
|
||||
|
||||
- 'n' is number of telemetry pages (from 1 to 2);
|
||||
- indexes 1 for "iin";
|
||||
- indexes n+1, n+2 for "vout";
|
||||
@ -87,9 +96,12 @@ The driver exports the following attributes via the 'sysfs' files, where
|
||||
**in[2-{n+1}1_lcrit_alarm**
|
||||
|
||||
The driver provides the next attributes for the power:
|
||||
|
||||
- for power in alarm and input.
|
||||
- for power out: highest and input.
|
||||
|
||||
The driver exports the following attributes via the 'sysfs' files, where
|
||||
|
||||
- 'n' is number of telemetry pages (from 1 to 2);
|
||||
- indexes 1 for "pin";
|
||||
- indexes n+1, n+2 for "pout";
|
||||
|
||||
@ -57,9 +57,8 @@ to enable them. ::
|
||||
They can be enabled individually. The full list of the parameters: ::
|
||||
|
||||
make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \
|
||||
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump OBJSIZE=llvm-size \
|
||||
READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar \
|
||||
HOSTLD=ld.lld
|
||||
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \
|
||||
HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld
|
||||
|
||||
Currently, the integrated assembler is disabled by default. You can pass
|
||||
``LLVM_IAS=1`` to enable it.
|
||||
|
||||
@ -25,3 +25,4 @@ LEDs
|
||||
leds-lp5562
|
||||
leds-lp55xx
|
||||
leds-mlxcpld
|
||||
leds-sc27xx
|
||||
|
||||
@ -42,6 +42,7 @@ The validator tracks lock-class usage history and divides the usage into
|
||||
(4 usages * n STATEs + 1) categories:
|
||||
|
||||
where the 4 usages can be:
|
||||
|
||||
- 'ever held in STATE context'
|
||||
- 'ever held as readlock in STATE context'
|
||||
- 'ever held with STATE enabled'
|
||||
@ -49,10 +50,12 @@ where the 4 usages can be:
|
||||
|
||||
where the n STATEs are coded in kernel/locking/lockdep_states.h and as of
|
||||
now they include:
|
||||
|
||||
- hardirq
|
||||
- softirq
|
||||
|
||||
where the last 1 category is:
|
||||
|
||||
- 'ever used' [ == !unused ]
|
||||
|
||||
When locking rules are violated, these usage bits are presented in the
|
||||
@ -96,9 +99,9 @@ exact case is for the lock as of the reporting time.
|
||||
+--------------+-------------+--------------+
|
||||
| | irq enabled | irq disabled |
|
||||
+--------------+-------------+--------------+
|
||||
| ever in irq | ? | - |
|
||||
| ever in irq | '?' | '-' |
|
||||
+--------------+-------------+--------------+
|
||||
| never in irq | + | . |
|
||||
| never in irq | '+' | '.' |
|
||||
+--------------+-------------+--------------+
|
||||
|
||||
The character '-' suggests irq is disabled because if otherwise the
|
||||
@ -216,7 +219,7 @@ looks like this::
|
||||
BD_MUTEX_PARTITION
|
||||
};
|
||||
|
||||
mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_PARTITION);
|
||||
mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_PARTITION);
|
||||
|
||||
In this case the locking is done on a bdev object that is known to be a
|
||||
partition.
|
||||
@ -334,7 +337,7 @@ Troubleshooting:
|
||||
----------------
|
||||
|
||||
The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes.
|
||||
Exceeding this number will trigger the following lockdep warning:
|
||||
Exceeding this number will trigger the following lockdep warning::
|
||||
|
||||
(DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS))
|
||||
|
||||
@ -420,7 +423,8 @@ the critical section of another reader of the same lock instance.
|
||||
|
||||
The difference between recursive readers and non-recursive readers is because:
|
||||
recursive readers get blocked only by a write lock *holder*, while non-recursive
|
||||
readers could get blocked by a write lock *waiter*. Considering the follow example:
|
||||
readers could get blocked by a write lock *waiter*. Considering the follow
|
||||
example::
|
||||
|
||||
TASK A: TASK B:
|
||||
|
||||
@ -448,20 +452,22 @@ There are simply four block conditions:
|
||||
|
||||
Block condition matrix, Y means the row blocks the column, and N means otherwise.
|
||||
|
||||
| E | r | R |
|
||||
+---+---+---+---+
|
||||
E | Y | Y | Y |
|
||||
| | E | r | R |
|
||||
+---+---+---+---+
|
||||
r | Y | Y | N |
|
||||
| E | Y | Y | Y |
|
||||
+---+---+---+---+
|
||||
| r | Y | Y | N |
|
||||
+---+---+---+---+
|
||||
| R | Y | Y | N |
|
||||
+---+---+---+---+
|
||||
R | Y | Y | N |
|
||||
|
||||
(W: writers, r: non-recursive readers, R: recursive readers)
|
||||
|
||||
|
||||
acquired recursively. Unlike non-recursive read locks, recursive read locks
|
||||
only get blocked by current write lock *holders* other than write lock
|
||||
*waiters*, for example:
|
||||
*waiters*, for example::
|
||||
|
||||
TASK A: TASK B:
|
||||
|
||||
@ -491,7 +497,7 @@ Recursive locks don't block each other, while non-recursive locks do (this is
|
||||
even true for two non-recursive read locks). A non-recursive lock can block the
|
||||
corresponding recursive lock, and vice versa.
|
||||
|
||||
A deadlock case with recursive locks involved is as follow:
|
||||
A deadlock case with recursive locks involved is as follow::
|
||||
|
||||
TASK A: TASK B:
|
||||
|
||||
@ -510,7 +516,7 @@ because there are 3 types for lockers, there are, in theory, 9 types of lock
|
||||
dependencies, but we can show that 4 types of lock dependencies are enough for
|
||||
deadlock detection.
|
||||
|
||||
For each lock dependency:
|
||||
For each lock dependency::
|
||||
|
||||
L1 -> L2
|
||||
|
||||
@ -525,20 +531,25 @@ same types).
|
||||
With the above combination for simplification, there are 4 types of dependency edges
|
||||
in the lockdep graph:
|
||||
|
||||
1) -(ER)->: exclusive writer to recursive reader dependency, "X -(ER)-> Y" means
|
||||
1) -(ER)->:
|
||||
exclusive writer to recursive reader dependency, "X -(ER)-> Y" means
|
||||
X -> Y and X is a writer and Y is a recursive reader.
|
||||
|
||||
2) -(EN)->: exclusive writer to non-recursive locker dependency, "X -(EN)-> Y" means
|
||||
2) -(EN)->:
|
||||
exclusive writer to non-recursive locker dependency, "X -(EN)-> Y" means
|
||||
X -> Y and X is a writer and Y is either a writer or non-recursive reader.
|
||||
|
||||
3) -(SR)->: shared reader to recursive reader dependency, "X -(SR)-> Y" means
|
||||
3) -(SR)->:
|
||||
shared reader to recursive reader dependency, "X -(SR)-> Y" means
|
||||
X -> Y and X is a reader (recursive or not) and Y is a recursive reader.
|
||||
|
||||
4) -(SN)->: shared reader to non-recursive locker dependency, "X -(SN)-> Y" means
|
||||
4) -(SN)->:
|
||||
shared reader to non-recursive locker dependency, "X -(SN)-> Y" means
|
||||
X -> Y and X is a reader (recursive or not) and Y is either a writer or
|
||||
non-recursive reader.
|
||||
|
||||
Note that given two locks, they may have multiple dependencies between them, for example:
|
||||
Note that given two locks, they may have multiple dependencies between them,
|
||||
for example::
|
||||
|
||||
TASK A:
|
||||
|
||||
@ -592,11 +603,11 @@ circles that won't cause deadlocks.
|
||||
|
||||
Proof for sufficiency (Lemma 1):
|
||||
|
||||
Let's say we have a strong circle:
|
||||
Let's say we have a strong circle::
|
||||
|
||||
L1 -> L2 ... -> Ln -> L1
|
||||
|
||||
, which means we have dependencies:
|
||||
, which means we have dependencies::
|
||||
|
||||
L1 -> L2
|
||||
L2 -> L3
|
||||
@ -633,7 +644,7 @@ a lock held by P2, and P2 is waiting for a lock held by P3, ... and Pn is waitin
|
||||
for a lock held by P1. Let's name the lock Px is waiting as Lx, so since P1 is waiting
|
||||
for L1 and holding Ln, so we will have Ln -> L1 in the dependency graph. Similarly,
|
||||
we have L1 -> L2, L2 -> L3, ..., Ln-1 -> Ln in the dependency graph, which means we
|
||||
have a circle:
|
||||
have a circle::
|
||||
|
||||
Ln -> L1 -> L2 -> ... -> Ln
|
||||
|
||||
|
||||
@ -24,7 +24,6 @@ fit into other categories.
|
||||
isl29003
|
||||
lis3lv02d
|
||||
max6875
|
||||
mic/index
|
||||
pci-endpoint-test
|
||||
spear-pcie-gadget
|
||||
uacce
|
||||
|
||||
@ -70,6 +70,7 @@ The ``ice`` driver reports the following versions
|
||||
that both the name (as reported by ``fw.app.name``) and version are
|
||||
required to uniquely identify the package.
|
||||
* - ``fw.app.bundle_id``
|
||||
- running
|
||||
- 0xc0000001
|
||||
- Unique identifier for the DDP package loaded in the device. Also
|
||||
referred to as the DDP Track ID. Can be used to uniquely identify
|
||||
|
||||
@ -10,9 +10,9 @@ Overview / What Is J1939
|
||||
SAE J1939 defines a higher layer protocol on CAN. It implements a more
|
||||
sophisticated addressing scheme and extends the maximum packet size above 8
|
||||
bytes. Several derived specifications exist, which differ from the original
|
||||
J1939 on the application level, like MilCAN A, NMEA2000 and especially
|
||||
J1939 on the application level, like MilCAN A, NMEA2000, and especially
|
||||
ISO-11783 (ISOBUS). This last one specifies the so-called ETP (Extended
|
||||
Transport Protocol) which is has been included in this implementation. This
|
||||
Transport Protocol), which has been included in this implementation. This
|
||||
results in a maximum packet size of ((2 ^ 24) - 1) * 7 bytes == 111 MiB.
|
||||
|
||||
Specifications used
|
||||
@ -32,15 +32,15 @@ sockets, we found some reasons to justify a kernel implementation for the
|
||||
addressing and transport methods used by J1939.
|
||||
|
||||
* **Addressing:** when a process on an ECU communicates via J1939, it should
|
||||
not necessarily know its source address. Although at least one process per
|
||||
not necessarily know its source address. Although, at least one process per
|
||||
ECU should know the source address. Other processes should be able to reuse
|
||||
that address. This way, address parameters for different processes
|
||||
cooperating for the same ECU, are not duplicated. This way of working is
|
||||
closely related to the UNIX concept where programs do just one thing, and do
|
||||
closely related to the UNIX concept, where programs do just one thing and do
|
||||
it well.
|
||||
|
||||
* **Dynamic addressing:** Address Claiming in J1939 is time critical.
|
||||
Furthermore data transport should be handled properly during the address
|
||||
Furthermore, data transport should be handled properly during the address
|
||||
negotiation. Putting this functionality in the kernel eliminates it as a
|
||||
requirement for _every_ user space process that communicates via J1939. This
|
||||
results in a consistent J1939 bus with proper addressing.
|
||||
@ -58,7 +58,7 @@ Therefore, these parts are left to user space.
|
||||
|
||||
The J1939 sockets operate on CAN network devices (see SocketCAN). Any J1939
|
||||
user space library operating on CAN raw sockets will still operate properly.
|
||||
Since such library does not communicate with the in-kernel implementation, care
|
||||
Since such a library does not communicate with the in-kernel implementation, care
|
||||
must be taken that these two do not interfere. In practice, this means they
|
||||
cannot share ECU addresses. A single ECU (or virtual ECU) address is used by
|
||||
the library exclusively, or by the in-kernel system exclusively.
|
||||
@ -77,13 +77,13 @@ is composed as follows:
|
||||
8 bits : PS (PDU Specific)
|
||||
|
||||
In J1939-21 distinction is made between PDU1 format (where PF < 240) and PDU2
|
||||
format (where PF >= 240). Furthermore, when using PDU2 format, the PS-field
|
||||
format (where PF >= 240). Furthermore, when using the PDU2 format, the PS-field
|
||||
contains a so-called Group Extension, which is part of the PGN. When using PDU2
|
||||
format, the Group Extension is set in the PS-field.
|
||||
|
||||
On the other hand, when using PDU1 format, the PS-field contains a so-called
|
||||
Destination Address, which is _not_ part of the PGN. When communicating a PGN
|
||||
from user space to kernel (or visa versa) and PDU2 format is used, the PS-field
|
||||
from user space to kernel (or vice versa) and PDU2 format is used, the PS-field
|
||||
of the PGN shall be set to zero. The Destination Address shall be set
|
||||
elsewhere.
|
||||
|
||||
@ -96,15 +96,15 @@ Addressing
|
||||
|
||||
Both static and dynamic addressing methods can be used.
|
||||
|
||||
For static addresses, no extra checks are made by the kernel, and provided
|
||||
For static addresses, no extra checks are made by the kernel and provided
|
||||
addresses are considered right. This responsibility is for the OEM or system
|
||||
integrator.
|
||||
|
||||
For dynamic addressing, so-called Address Claiming, extra support is foreseen
|
||||
in the kernel. In J1939 any ECU is known by it's 64-bit NAME. At the moment of
|
||||
in the kernel. In J1939 any ECU is known by its 64-bit NAME. At the moment of
|
||||
a successful address claim, the kernel keeps track of both NAME and source
|
||||
address being claimed. This serves as a base for filter schemes. By default,
|
||||
packets with a destination that is not locally, will be rejected.
|
||||
packets with a destination that is not locally will be rejected.
|
||||
|
||||
Mixed mode packets (from a static to a dynamic address or vice versa) are
|
||||
allowed. The BSD sockets define separate API calls for getting/setting the
|
||||
@ -131,31 +131,31 @@ API Calls
|
||||
---------
|
||||
|
||||
On CAN, you first need to open a socket for communicating over a CAN network.
|
||||
To use J1939, #include <linux/can/j1939.h>. From there, <linux/can.h> will be
|
||||
To use J1939, ``#include <linux/can/j1939.h>``. From there, ``<linux/can.h>`` will be
|
||||
included too. To open a socket, use:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
|
||||
|
||||
J1939 does use SOCK_DGRAM sockets. In the J1939 specification, connections are
|
||||
J1939 does use ``SOCK_DGRAM`` sockets. In the J1939 specification, connections are
|
||||
mentioned in the context of transport protocol sessions. These still deliver
|
||||
packets to the other end (using several CAN packets). SOCK_STREAM is not
|
||||
packets to the other end (using several CAN packets). ``SOCK_STREAM`` is not
|
||||
supported.
|
||||
|
||||
After the successful creation of the socket, you would normally use the bind(2)
|
||||
and/or connect(2) system call to bind the socket to a CAN interface. After
|
||||
binding and/or connecting the socket, you can read(2) and write(2) from/to the
|
||||
socket or use send(2), sendto(2), sendmsg(2) and the recv*() counterpart
|
||||
After the successful creation of the socket, you would normally use the ``bind(2)``
|
||||
and/or ``connect(2)`` system call to bind the socket to a CAN interface. After
|
||||
binding and/or connecting the socket, you can ``read(2)`` and ``write(2)`` from/to the
|
||||
socket or use ``send(2)``, ``sendto(2)``, ``sendmsg(2)`` and the ``recv*()`` counterpart
|
||||
operations on the socket as usual. There are also J1939 specific socket options
|
||||
described below.
|
||||
|
||||
In order to send data, a bind(2) must have been successful. bind(2) assigns a
|
||||
In order to send data, a ``bind(2)`` must have been successful. ``bind(2)`` assigns a
|
||||
local address to a socket.
|
||||
|
||||
Different from CAN is that the payload data is just the data that get send,
|
||||
without it's header info. The header info is derived from the sockaddr supplied
|
||||
to bind(2), connect(2), sendto(2) and recvfrom(2). A write(2) with size 4 will
|
||||
Different from CAN is that the payload data is just the data that get sends,
|
||||
without its header info. The header info is derived from the sockaddr supplied
|
||||
to ``bind(2)``, ``connect(2)``, ``sendto(2)`` and ``recvfrom(2)``. A ``write(2)`` with size 4 will
|
||||
result in a packet with 4 bytes.
|
||||
|
||||
The sockaddr structure has extensions for use with J1939 as specified below:
|
||||
@ -180,47 +180,47 @@ The sockaddr structure has extensions for use with J1939 as specified below:
|
||||
} can_addr;
|
||||
}
|
||||
|
||||
can_family & can_ifindex serve the same purpose as for other SocketCAN sockets.
|
||||
``can_family`` & ``can_ifindex`` serve the same purpose as for other SocketCAN sockets.
|
||||
|
||||
can_addr.j1939.pgn specifies the PGN (max 0x3ffff). Individual bits are
|
||||
``can_addr.j1939.pgn`` specifies the PGN (max 0x3ffff). Individual bits are
|
||||
specified above.
|
||||
|
||||
can_addr.j1939.name contains the 64-bit J1939 NAME.
|
||||
``can_addr.j1939.name`` contains the 64-bit J1939 NAME.
|
||||
|
||||
can_addr.j1939.addr contains the address.
|
||||
``can_addr.j1939.addr`` contains the address.
|
||||
|
||||
The bind(2) system call assigns the local address, i.e. the source address when
|
||||
sending packages. If a PGN during bind(2) is set, it's used as a RX filter.
|
||||
I.e. only packets with a matching PGN are received. If an ADDR or NAME is set
|
||||
The ``bind(2)`` system call assigns the local address, i.e. the source address when
|
||||
sending packages. If a PGN during ``bind(2)`` is set, it's used as a RX filter.
|
||||
I.e. only packets with a matching PGN are received. If an ADDR or NAME is set
|
||||
it is used as a receive filter, too. It will match the destination NAME or ADDR
|
||||
of the incoming packet. The NAME filter will work only if appropriate Address
|
||||
Claiming for this name was done on the CAN bus and registered/cached by the
|
||||
kernel.
|
||||
|
||||
On the other hand connect(2) assigns the remote address, i.e. the destination
|
||||
address. The PGN from connect(2) is used as the default PGN when sending
|
||||
On the other hand ``connect(2)`` assigns the remote address, i.e. the destination
|
||||
address. The PGN from ``connect(2)`` is used as the default PGN when sending
|
||||
packets. If ADDR or NAME is set it will be used as the default destination ADDR
|
||||
or NAME. Further a set ADDR or NAME during connect(2) is used as a receive
|
||||
or NAME. Further a set ADDR or NAME during ``connect(2)`` is used as a receive
|
||||
filter. It will match the source NAME or ADDR of the incoming packet.
|
||||
|
||||
Both write(2) and send(2) will send a packet with local address from bind(2) and
|
||||
the remote address from connect(2). Use sendto(2) to overwrite the destination
|
||||
Both ``write(2)`` and ``send(2)`` will send a packet with local address from ``bind(2)`` and the
|
||||
remote address from ``connect(2)``. Use ``sendto(2)`` to overwrite the destination
|
||||
address.
|
||||
|
||||
If can_addr.j1939.name is set (!= 0) the NAME is looked up by the kernel and
|
||||
the corresponding ADDR is used. If can_addr.j1939.name is not set (== 0),
|
||||
can_addr.j1939.addr is used.
|
||||
If ``can_addr.j1939.name`` is set (!= 0) the NAME is looked up by the kernel and
|
||||
the corresponding ADDR is used. If ``can_addr.j1939.name`` is not set (== 0),
|
||||
``can_addr.j1939.addr`` is used.
|
||||
|
||||
When creating a socket, reasonable defaults are set. Some options can be
|
||||
modified with setsockopt(2) & getsockopt(2).
|
||||
modified with ``setsockopt(2)`` & ``getsockopt(2)``.
|
||||
|
||||
RX path related options:
|
||||
|
||||
- SO_J1939_FILTER - configure array of filters
|
||||
- SO_J1939_PROMISC - disable filters set by bind(2) and connect(2)
|
||||
- ``SO_J1939_FILTER`` - configure array of filters
|
||||
- ``SO_J1939_PROMISC`` - disable filters set by ``bind(2)`` and ``connect(2)``
|
||||
|
||||
By default no broadcast packets can be send or received. To enable sending or
|
||||
receiving broadcast packets use the socket option SO_BROADCAST:
|
||||
receiving broadcast packets use the socket option ``SO_BROADCAST``:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
@ -261,26 +261,26 @@ The following diagram illustrates the RX path:
|
||||
+---------------------------+
|
||||
|
||||
TX path related options:
|
||||
SO_J1939_SEND_PRIO - change default send priority for the socket
|
||||
``SO_J1939_SEND_PRIO`` - change default send priority for the socket
|
||||
|
||||
Message Flags during send() and Related System Calls
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
send(2), sendto(2) and sendmsg(2) take a 'flags' argument. Currently
|
||||
``send(2)``, ``sendto(2)`` and ``sendmsg(2)`` take a 'flags' argument. Currently
|
||||
supported flags are:
|
||||
|
||||
* MSG_DONTWAIT, i.e. non-blocking operation.
|
||||
* ``MSG_DONTWAIT``, i.e. non-blocking operation.
|
||||
|
||||
recvmsg(2)
|
||||
^^^^^^^^^^
|
||||
|
||||
In most cases recvmsg(2) is needed if you want to extract more information than
|
||||
recvfrom(2) can provide. For example package priority and timestamp. The
|
||||
In most cases ``recvmsg(2)`` is needed if you want to extract more information than
|
||||
``recvfrom(2)`` can provide. For example package priority and timestamp. The
|
||||
Destination Address, name and packet priority (if applicable) are attached to
|
||||
the msghdr in the recvmsg(2) call. They can be extracted using cmsg(3) macros,
|
||||
with cmsg_level == SOL_J1939 && cmsg_type == SCM_J1939_DEST_ADDR,
|
||||
SCM_J1939_DEST_NAME or SCM_J1939_PRIO. The returned data is a uint8_t for
|
||||
priority and dst_addr, and uint64_t for dst_name.
|
||||
the msghdr in the ``recvmsg(2)`` call. They can be extracted using ``cmsg(3)`` macros,
|
||||
with ``cmsg_level == SOL_J1939 && cmsg_type == SCM_J1939_DEST_ADDR``,
|
||||
``SCM_J1939_DEST_NAME`` or ``SCM_J1939_PRIO``. The returned data is a ``uint8_t`` for
|
||||
``priority`` and ``dst_addr``, and ``uint64_t`` for ``dst_name``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
@ -305,12 +305,12 @@ Dynamic Addressing
|
||||
|
||||
Distinction has to be made between using the claimed address and doing an
|
||||
address claim. To use an already claimed address, one has to fill in the
|
||||
j1939.name member and provide it to bind(2). If the name had claimed an address
|
||||
``j1939.name`` member and provide it to ``bind(2)``. If the name had claimed an address
|
||||
earlier, all further messages being sent will use that address. And the
|
||||
j1939.addr member will be ignored.
|
||||
``j1939.addr`` member will be ignored.
|
||||
|
||||
An exception on this is PGN 0x0ee00. This is the "Address Claim/Cannot Claim
|
||||
Address" message and the kernel will use the j1939.addr member for that PGN if
|
||||
Address" message and the kernel will use the ``j1939.addr`` member for that PGN if
|
||||
necessary.
|
||||
|
||||
To claim an address following code example can be used:
|
||||
@ -371,12 +371,12 @@ NAME can send packets.
|
||||
|
||||
If another ECU claims the address, the kernel will mark the NAME-SA expired.
|
||||
No socket bound to the NAME can send packets (other than address claims). To
|
||||
claim another address, some socket bound to NAME, must bind(2) again, but with
|
||||
only j1939.addr changed to the new SA, and must then send a valid address claim
|
||||
claim another address, some socket bound to NAME, must ``bind(2)`` again, but with
|
||||
only ``j1939.addr`` changed to the new SA, and must then send a valid address claim
|
||||
packet. This restarts the state machine in the kernel (and any other
|
||||
participant on the bus) for this NAME.
|
||||
|
||||
can-utils also include the jacd tool, so it can be used as code example or as
|
||||
``can-utils`` also include the ``j1939acd`` tool, so it can be used as code example or as
|
||||
default Address Claiming daemon.
|
||||
|
||||
Send Examples
|
||||
@ -403,8 +403,8 @@ Bind:
|
||||
|
||||
bind(sock, (struct sockaddr *)&baddr, sizeof(baddr));
|
||||
|
||||
Now, the socket 'sock' is bound to the SA 0x20. Since no connect(2) was called,
|
||||
at this point we can use only sendto(2) or sendmsg(2).
|
||||
Now, the socket 'sock' is bound to the SA 0x20. Since no ``connect(2)`` was called,
|
||||
at this point we can use only ``sendto(2)`` or ``sendmsg(2)``.
|
||||
|
||||
Send:
|
||||
|
||||
@ -414,8 +414,8 @@ Send:
|
||||
.can_family = AF_CAN,
|
||||
.can_addr.j1939 = {
|
||||
.name = J1939_NO_NAME;
|
||||
.pgn = 0x30,
|
||||
.addr = 0x12300,
|
||||
.addr = 0x30,
|
||||
.pgn = 0x12300,
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
@ -110,7 +110,7 @@ Q: I sent a patch and I'm wondering what happened to it?
|
||||
Q: How can I tell whether it got merged?
|
||||
A: Start by looking at the main patchworks queue for netdev:
|
||||
|
||||
http://patchwork.ozlabs.org/project/netdev/list/
|
||||
https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
|
||||
The "State" field will tell you exactly where things are at with your
|
||||
patch.
|
||||
@ -152,7 +152,7 @@ networking subsystem, and then hands them off to Greg.
|
||||
|
||||
There is a patchworks queue that you can see here:
|
||||
|
||||
http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
|
||||
https://patchwork.kernel.org/bundle/netdev/stable/?state=*
|
||||
|
||||
It contains the patches which Dave has selected, but not yet handed off
|
||||
to Greg. If Greg already has the patch, then it will be here:
|
||||
@ -254,6 +254,32 @@ you will have done run-time testing specific to your change, but at a
|
||||
minimum, your changes should survive an ``allyesconfig`` and an
|
||||
``allmodconfig`` build without new warnings or failures.
|
||||
|
||||
Q: How do I post corresponding changes to user space components?
|
||||
----------------------------------------------------------------
|
||||
A: User space code exercising kernel features should be posted
|
||||
alongside kernel patches. This gives reviewers a chance to see
|
||||
how any new interface is used and how well it works.
|
||||
|
||||
When user space tools reside in the kernel repo itself all changes
|
||||
should generally come as one series. If series becomes too large
|
||||
or the user space project is not reviewed on netdev include a link
|
||||
to a public repo where user space patches can be seen.
|
||||
|
||||
In case user space tooling lives in a separate repository but is
|
||||
reviewed on netdev (e.g. patches to `iproute2` tools) kernel and
|
||||
user space patches should form separate series (threads) when posted
|
||||
to the mailing list, e.g.::
|
||||
|
||||
[PATCH net-next 0/3] net: some feature cover letter
|
||||
└─ [PATCH net-next 1/3] net: some feature prep
|
||||
└─ [PATCH net-next 2/3] net: some feature do it
|
||||
└─ [PATCH net-next 3/3] selftest: net: some feature
|
||||
|
||||
[PATCH iproute2-next] ip: add support for some feature
|
||||
|
||||
Posting as one thread is discouraged because it confuses patchwork
|
||||
(as of patchwork 2.2.2).
|
||||
|
||||
Q: Any other tips to help ensure my net/net-next patch gets OK'd?
|
||||
-----------------------------------------------------------------
|
||||
A: Attention to detail. Re-read your own work as if you were the
|
||||
|
||||
@ -247,8 +247,8 @@ Some of the interface modes are described below:
|
||||
speeds (see below.)
|
||||
|
||||
``PHY_INTERFACE_MODE_2500BASEX``
|
||||
This defines a variant of 1000BASE-X which is clocked 2.5 times faster,
|
||||
than the 802.3 standard giving a fixed bit rate of 3.125Gbaud.
|
||||
This defines a variant of 1000BASE-X which is clocked 2.5 times as fast
|
||||
as the 802.3 standard, giving a fixed bit rate of 3.125Gbaud.
|
||||
|
||||
``PHY_INTERFACE_MODE_SGMII``
|
||||
This is used for Cisco SGMII, which is a modification of 1000BASE-X
|
||||
|
||||
@ -175,5 +175,4 @@ The following structures are internal to the kernel, their members are
|
||||
translated to netlink attributes when dumped. Drivers must not overwrite
|
||||
the statistics they don't report with 0.
|
||||
|
||||
.. kernel-doc:: include/linux/ethtool.h
|
||||
:identifiers: ethtool_pause_stats
|
||||
- ethtool_pause_stats()
|
||||
|
||||
@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree
|
||||
submission guidelines as described in
|
||||
:ref:`Documentation/networking/netdev-FAQ.rst <netdev-FAQ>`
|
||||
after first checking the stable networking queue at
|
||||
https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive=
|
||||
https://patchwork.kernel.org/bundle/netdev/stable/?state=*
|
||||
to ensure the requested patch is not already queued up.
|
||||
- Security patches should not be handled (solely) by the -stable review
|
||||
process but should follow the procedures in
|
||||
|
||||
@ -15,6 +15,14 @@ else:
|
||||
import re
|
||||
from itertools import chain
|
||||
|
||||
#
|
||||
# Python 2 lacks re.ASCII...
|
||||
#
|
||||
try:
|
||||
ascii_p3 = re.ASCII
|
||||
except AttributeError:
|
||||
ascii_p3 = 0
|
||||
|
||||
#
|
||||
# Regex nastiness. Of course.
|
||||
# Try to identify "function()" that's not already marked up some
|
||||
@ -22,22 +30,22 @@ from itertools import chain
|
||||
# :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last
|
||||
# bit tries to restrict matches to things that won't create trouble.
|
||||
#
|
||||
RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=re.ASCII)
|
||||
RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=ascii_p3)
|
||||
|
||||
#
|
||||
# Sphinx 2 uses the same :c:type role for struct, union, enum and typedef
|
||||
#
|
||||
RE_generic_type = re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)',
|
||||
flags=re.ASCII)
|
||||
flags=ascii_p3)
|
||||
|
||||
#
|
||||
# Sphinx 3 uses a different C role for each one of struct, union, enum and
|
||||
# typedef
|
||||
#
|
||||
RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
|
||||
RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
|
||||
RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
|
||||
RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
|
||||
RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
|
||||
RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
|
||||
RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
|
||||
RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
|
||||
|
||||
#
|
||||
# Detects a reference to a documentation page of the form Documentation/... with
|
||||
|
||||
@ -46,7 +46,7 @@ Procedura per sottomettere patch per i sorgenti -stable
|
||||
:ref:`Documentation/translations/it_IT/networking/netdev-FAQ.rst <it_netdev-FAQ>`;
|
||||
ma solo dopo aver verificato al seguente indirizzo che la patch non sia
|
||||
già in coda:
|
||||
https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive=
|
||||
https://patchwork.kernel.org/bundle/netdev/stable/?state=*
|
||||
- Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo
|
||||
di revisione -stable, ma dovrebbe seguire le procedure descritte in
|
||||
:ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`.
|
||||
|
||||
@ -22,6 +22,7 @@ place where this information is gathered.
|
||||
spec_ctrl
|
||||
accelerators/ocxl
|
||||
ioctl/index
|
||||
iommu
|
||||
media/index
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
@ -6367,7 +6367,7 @@ accesses that would usually trigger a #GP by KVM into the guest will
|
||||
instead get bounced to user space through the KVM_EXIT_X86_RDMSR and
|
||||
KVM_EXIT_X86_WRMSR exit notifications.
|
||||
|
||||
8.25 KVM_X86_SET_MSR_FILTER
|
||||
8.27 KVM_X86_SET_MSR_FILTER
|
||||
---------------------------
|
||||
|
||||
:Architectures: x86
|
||||
@ -6381,8 +6381,7 @@ In combination with KVM_CAP_X86_USER_SPACE_MSR, this allows user space to
|
||||
trap and emulate MSRs that are outside of the scope of KVM as well as
|
||||
limit the attack surface on KVM's MSR emulation code.
|
||||
|
||||
|
||||
8.26 KVM_CAP_ENFORCE_PV_CPUID
|
||||
8.28 KVM_CAP_ENFORCE_PV_CPUID
|
||||
-----------------------------
|
||||
|
||||
Architectures: x86
|
||||
|
||||
@ -82,7 +82,8 @@ Default MMUv2-compatible layout::
|
||||
+------------------+
|
||||
| VMALLOC area | VMALLOC_START 0xc0000000 128MB - 64KB
|
||||
+------------------+ VMALLOC_END
|
||||
| Cache aliasing | TLBTEMP_BASE_1 0xc7ff0000 DCACHE_WAY_SIZE
|
||||
+------------------+
|
||||
| Cache aliasing | TLBTEMP_BASE_1 0xc8000000 DCACHE_WAY_SIZE
|
||||
| remap area 1 |
|
||||
+------------------+
|
||||
| Cache aliasing | TLBTEMP_BASE_2 DCACHE_WAY_SIZE
|
||||
@ -124,7 +125,8 @@ Default MMUv2-compatible layout::
|
||||
+------------------+
|
||||
| VMALLOC area | VMALLOC_START 0xa0000000 128MB - 64KB
|
||||
+------------------+ VMALLOC_END
|
||||
| Cache aliasing | TLBTEMP_BASE_1 0xa7ff0000 DCACHE_WAY_SIZE
|
||||
+------------------+
|
||||
| Cache aliasing | TLBTEMP_BASE_1 0xa8000000 DCACHE_WAY_SIZE
|
||||
| remap area 1 |
|
||||
+------------------+
|
||||
| Cache aliasing | TLBTEMP_BASE_2 DCACHE_WAY_SIZE
|
||||
@ -167,7 +169,8 @@ Default MMUv2-compatible layout::
|
||||
+------------------+
|
||||
| VMALLOC area | VMALLOC_START 0x90000000 128MB - 64KB
|
||||
+------------------+ VMALLOC_END
|
||||
| Cache aliasing | TLBTEMP_BASE_1 0x97ff0000 DCACHE_WAY_SIZE
|
||||
+------------------+
|
||||
| Cache aliasing | TLBTEMP_BASE_1 0x98000000 DCACHE_WAY_SIZE
|
||||
| remap area 1 |
|
||||
+------------------+
|
||||
| Cache aliasing | TLBTEMP_BASE_2 DCACHE_WAY_SIZE
|
||||
|
||||
126
MAINTAINERS
126
MAINTAINERS
@ -934,7 +934,7 @@ M: Evan Quan <evan.quan@amd.com>
|
||||
L: amd-gfx@lists.freedesktop.org
|
||||
S: Supported
|
||||
T: git git://people.freedesktop.org/~agd5f/linux
|
||||
F: drivers/gpu/drm/amd/powerplay/
|
||||
F: drivers/gpu/drm/amd/pm/powerplay/
|
||||
|
||||
AMD SEATTLE DEVICE TREE SUPPORT
|
||||
M: Brijesh Singh <brijeshkumar.singh@amd.com>
|
||||
@ -978,7 +978,7 @@ M: Michael Hennerich <Michael.Hennerich@analog.com>
|
||||
L: linux-iio@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://ez.analog.com/community/linux-device-drivers
|
||||
F: Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.txt
|
||||
F: Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
|
||||
F: drivers/iio/adc/ad7768-1.c
|
||||
|
||||
ANALOG DEVICES INC AD7780 DRIVER
|
||||
@ -1279,7 +1279,7 @@ M: Igor Russkikh <irusskikh@marvell.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://www.marvell.com/
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
F: Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst
|
||||
F: drivers/net/ethernet/aquantia/atlantic/
|
||||
|
||||
@ -1546,6 +1546,7 @@ F: drivers/clk/sunxi/
|
||||
ARM/Allwinner sunXi SoC support
|
||||
M: Maxime Ripard <mripard@kernel.org>
|
||||
M: Chen-Yu Tsai <wens@csie.org>
|
||||
R: Jernej Skrabec <jernej.skrabec@siol.net>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
|
||||
@ -1723,11 +1724,13 @@ F: arch/arm/mach-ep93xx/micro9.c
|
||||
|
||||
ARM/CORESIGHT FRAMEWORK AND DRIVERS
|
||||
M: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
R: Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
M: Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
R: Mike Leach <mike.leach@linaro.org>
|
||||
R: Leo Yan <leo.yan@linaro.org>
|
||||
L: coresight@lists.linaro.org (moderated for non-subscribers)
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git
|
||||
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
|
||||
F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
|
||||
F: Documentation/devicetree/bindings/arm/coresight-cti.yaml
|
||||
@ -1994,7 +1997,6 @@ N: lpc18xx
|
||||
|
||||
ARM/LPC32XX SOC SUPPORT
|
||||
M: Vladimir Zapolskiy <vz@mleia.com>
|
||||
M: Sylvain Lemieux <slemieux.tyco@gmail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
T: git git://github.com/vzapolskiy/linux-lpc32xx.git
|
||||
@ -2374,7 +2376,7 @@ F: drivers/i2c/busses/i2c-rk3x.c
|
||||
F: sound/soc/rockchip/
|
||||
N: rockchip
|
||||
|
||||
ARM/SAMSUNG EXYNOS ARM ARCHITECTURES
|
||||
ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES
|
||||
M: Krzysztof Kozlowski <krzk@kernel.org>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: linux-samsung-soc@vger.kernel.org
|
||||
@ -2403,15 +2405,7 @@ N: s3c2410
|
||||
N: s3c64xx
|
||||
N: s5pv210
|
||||
|
||||
ARM/SAMSUNG MOBILE MACHINE SUPPORT
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-s5pv210/
|
||||
|
||||
ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
M: Kamil Debski <kamil@wypas.org>
|
||||
M: Andrzej Hajda <a.hajda@samsung.com>
|
||||
L: linux-arm-kernel@lists.infradead.org
|
||||
L: linux-media@vger.kernel.org
|
||||
@ -2436,9 +2430,6 @@ S: Maintained
|
||||
F: drivers/media/platform/s5p-jpeg/
|
||||
|
||||
ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
M: Kamil Debski <kamil@wypas.org>
|
||||
M: Jeongtae Park <jtp.park@samsung.com>
|
||||
M: Andrzej Hajda <a.hajda@samsung.com>
|
||||
L: linux-arm-kernel@lists.infradead.org
|
||||
L: linux-media@vger.kernel.org
|
||||
@ -3243,10 +3234,10 @@ F: drivers/iio/accel/bma400*
|
||||
BPF (Safe dynamic programs and tools)
|
||||
M: Alexei Starovoitov <ast@kernel.org>
|
||||
M: Daniel Borkmann <daniel@iogearbox.net>
|
||||
M: Andrii Nakryiko <andrii@kernel.org>
|
||||
R: Martin KaFai Lau <kafai@fb.com>
|
||||
R: Song Liu <songliubraving@fb.com>
|
||||
R: Yonghong Song <yhs@fb.com>
|
||||
R: Andrii Nakryiko <andrii@kernel.org>
|
||||
R: John Fastabend <john.fastabend@gmail.com>
|
||||
R: KP Singh <kpsingh@chromium.org>
|
||||
L: netdev@vger.kernel.org
|
||||
@ -3538,11 +3529,12 @@ BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
|
||||
M: Arend van Spriel <arend.vanspriel@broadcom.com>
|
||||
M: Franky Lin <franky.lin@broadcom.com>
|
||||
M: Hante Meuleman <hante.meuleman@broadcom.com>
|
||||
M: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
|
||||
M: Wright Feng <wright.feng@cypress.com>
|
||||
M: Chi-hsien Lin <chi-hsien.lin@infineon.com>
|
||||
M: Wright Feng <wright.feng@infineon.com>
|
||||
M: Chung-hsien Hsu <chung-hsien.hsu@infineon.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: brcm80211-dev-list.pdl@broadcom.com
|
||||
L: brcm80211-dev-list@cypress.com
|
||||
L: SHA-cyfmac-dev-list@infineon.com
|
||||
S: Supported
|
||||
F: drivers/net/wireless/broadcom/brcm80211/
|
||||
|
||||
@ -3857,7 +3849,7 @@ M: Roger Quadros <rogerq@ti.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
|
||||
F: Documentation/devicetree/bindings/usb/cdns-usb3.txt
|
||||
F: Documentation/devicetree/bindings/usb/cdns,usb3.yaml
|
||||
F: drivers/usb/cdns3/
|
||||
|
||||
CADET FM/AM RADIO RECEIVER DRIVER
|
||||
@ -4710,7 +4702,7 @@ T: git git://linuxtv.org/anttip/media_tree.git
|
||||
F: drivers/media/dvb-frontends/cxd2820r*
|
||||
|
||||
CXGB3 ETHERNET DRIVER (CXGB3)
|
||||
M: Vishal Kulkarni <vishal@chelsio.com>
|
||||
M: Raju Rangoju <rajur@chelsio.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.chelsio.com
|
||||
@ -4742,7 +4734,7 @@ W: http://www.chelsio.com
|
||||
F: drivers/net/ethernet/chelsio/inline_crypto/
|
||||
|
||||
CXGB4 ETHERNET DRIVER (CXGB4)
|
||||
M: Vishal Kulkarni <vishal@chelsio.com>
|
||||
M: Raju Rangoju <rajur@chelsio.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.chelsio.com
|
||||
@ -4764,7 +4756,7 @@ F: drivers/infiniband/hw/cxgb4/
|
||||
F: include/uapi/rdma/cxgb4-abi.h
|
||||
|
||||
CXGB4VF ETHERNET DRIVER (CXGB4VF)
|
||||
M: Vishal Kulkarni <vishal@gmail.com>
|
||||
M: Raju Rangoju <rajur@chelsio.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.chelsio.com
|
||||
@ -6614,6 +6606,7 @@ Q: http://patchwork.ozlabs.org/project/linux-ext4/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
|
||||
F: Documentation/filesystems/ext4/
|
||||
F: fs/ext4/
|
||||
F: include/trace/events/ext4.h
|
||||
|
||||
Extended Verification Module (EVM)
|
||||
M: Mimi Zohar <zohar@linux.ibm.com>
|
||||
@ -7916,7 +7909,7 @@ HISILICON LPC BUS DRIVER
|
||||
M: john.garry@huawei.com
|
||||
S: Maintained
|
||||
W: http://www.hisilicon.com
|
||||
F: Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
|
||||
F: Documentation/devicetree/bindings/arm/hisilicon/low-pin-count.yaml
|
||||
F: drivers/bus/hisi_lpc.c
|
||||
|
||||
HISILICON NETWORK SUBSYSTEM 3 DRIVER (HNS3)
|
||||
@ -8829,8 +8822,8 @@ S: Supported
|
||||
W: http://www.intel.com/support/feedback.htm
|
||||
W: http://e1000.sourceforge.net/
|
||||
Q: http://patchwork.ozlabs.org/project/intel-wired-lan/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git
|
||||
F: Documentation/networking/device_drivers/ethernet/intel/
|
||||
F: drivers/net/ethernet/intel/
|
||||
F: drivers/net/ethernet/intel/*/
|
||||
@ -9171,6 +9164,7 @@ F: include/linux/iomap.h
|
||||
|
||||
IOMMU DRIVERS
|
||||
M: Joerg Roedel <joro@8bytes.org>
|
||||
M: Will Deacon <will@kernel.org>
|
||||
L: iommu@lists.linux-foundation.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
|
||||
@ -9654,6 +9648,7 @@ F: Documentation/virt/kvm/s390*
|
||||
F: arch/s390/include/asm/gmap.h
|
||||
F: arch/s390/include/asm/kvm*
|
||||
F: arch/s390/include/uapi/asm/kvm*
|
||||
F: arch/s390/kernel/uv.c
|
||||
F: arch/s390/kvm/
|
||||
F: arch/s390/mm/gmap.c
|
||||
F: tools/testing/selftests/kvm/*/s390x/
|
||||
@ -9842,13 +9837,6 @@ S: Maintained
|
||||
F: arch/mips/lantiq
|
||||
F: drivers/soc/lantiq
|
||||
|
||||
LAPB module
|
||||
L: linux-x25@vger.kernel.org
|
||||
S: Orphan
|
||||
F: Documentation/networking/lapb-module.rst
|
||||
F: include/*/lapb.h
|
||||
F: net/lapb/
|
||||
|
||||
LASI 53c700 driver for PARISC
|
||||
M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
@ -11163,7 +11151,7 @@ F: Documentation/devicetree/bindings/input/touchscreen/melfas_mip4.txt
|
||||
F: drivers/input/touchscreen/melfas_mip4.c
|
||||
|
||||
MELLANOX BLUEFIELD I2C DRIVER
|
||||
M: Khalil Blaiech <kblaiech@mellanox.com>
|
||||
M: Khalil Blaiech <kblaiech@nvidia.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/i2c/busses/i2c-mlxbf.c
|
||||
@ -11173,7 +11161,7 @@ M: Tariq Toukan <tariqt@nvidia.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
F: drivers/net/ethernet/mellanox/mlx4/en_*
|
||||
|
||||
MELLANOX ETHERNET DRIVER (mlx5e)
|
||||
@ -11181,7 +11169,7 @@ M: Saeed Mahameed <saeedm@nvidia.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/en_*
|
||||
|
||||
MELLANOX ETHERNET INNOVA DRIVERS
|
||||
@ -11189,7 +11177,7 @@ R: Boris Pismenny <borisp@nvidia.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/accel/*
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/en_accel/*
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/fpga/*
|
||||
@ -11201,7 +11189,7 @@ M: Ido Schimmel <idosch@nvidia.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
F: drivers/net/ethernet/mellanox/mlxsw/
|
||||
F: tools/testing/selftests/drivers/net/mlxsw/
|
||||
|
||||
@ -11210,7 +11198,7 @@ M: mlxsw@nvidia.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
F: drivers/net/ethernet/mellanox/mlxfw/
|
||||
|
||||
MELLANOX HARDWARE PLATFORM SUPPORT
|
||||
@ -11229,7 +11217,7 @@ L: netdev@vger.kernel.org
|
||||
L: linux-rdma@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
F: drivers/net/ethernet/mellanox/mlx4/
|
||||
F: include/linux/mlx4/
|
||||
|
||||
@ -11250,7 +11238,7 @@ L: netdev@vger.kernel.org
|
||||
L: linux-rdma@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
F: Documentation/networking/device_drivers/ethernet/mellanox/
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/
|
||||
F: include/linux/mlx5/
|
||||
@ -12130,7 +12118,7 @@ M: Jakub Kicinski <kuba@kernel.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://www.linuxfoundation.org/en/Net
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
|
||||
F: Documentation/devicetree/bindings/net/
|
||||
@ -12175,7 +12163,7 @@ M: Jakub Kicinski <kuba@kernel.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://www.linuxfoundation.org/en/Net
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: https://patchwork.kernel.org/project/netdevbpf/list/
|
||||
B: mailto:netdev@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
|
||||
@ -13176,7 +13164,9 @@ M: Jesper Dangaard Brouer <hawk@kernel.org>
|
||||
M: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/networking/page_pool.rst
|
||||
F: include/net/page_pool.h
|
||||
F: include/trace/events/page_pool.h
|
||||
F: net/core/page_pool.c
|
||||
|
||||
PANASONIC LAPTOP ACPI EXTRAS DRIVER
|
||||
@ -14210,7 +14200,6 @@ F: drivers/media/usb/pwc/*
|
||||
F: include/trace/events/pwc.h
|
||||
|
||||
PWM FAN DRIVER
|
||||
M: Kamil Debski <kamil@wypas.org>
|
||||
M: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
||||
L: linux-hwmon@vger.kernel.org
|
||||
S: Supported
|
||||
@ -14527,6 +14516,14 @@ F: Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
|
||||
F: drivers/mailbox/qcom-ipcc.c
|
||||
F: include/dt-bindings/mailbox/qcom-ipcc.h
|
||||
|
||||
QUALCOMM IPQ4019 VQMMC REGULATOR DRIVER
|
||||
M: Robert Marko <robert.marko@sartura.hr>
|
||||
M: Luka Perkov <luka.perkov@sartura.hr>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml
|
||||
F: drivers/regulator/vqmmc-ipq4019-regulator.c
|
||||
|
||||
QUALCOMM RMNET DRIVER
|
||||
M: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
|
||||
M: Sean Tranchetti <stranche@codeaurora.org>
|
||||
@ -14811,7 +14808,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.g
|
||||
F: drivers/net/wireless/realtek/rtlwifi/
|
||||
|
||||
REALTEK WIRELESS DRIVER (rtw88)
|
||||
M: Yan-Hsuan Chuang <yhchuang@realtek.com>
|
||||
M: Yan-Hsuan Chuang <tony0620emma@gmail.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/wireless/realtek/rtw88/
|
||||
@ -14882,7 +14879,6 @@ RENESAS ETHERNET DRIVERS
|
||||
R: Sergei Shtylyov <sergei.shtylyov@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
F: Documentation/devicetree/bindings/net/renesas,*.txt
|
||||
F: Documentation/devicetree/bindings/net/renesas,*.yaml
|
||||
F: drivers/net/ethernet/renesas/
|
||||
F: include/linux/sh_eth.h
|
||||
@ -15239,7 +15235,6 @@ F: drivers/iommu/s390-iommu.c
|
||||
S390 IUCV NETWORK LAYER
|
||||
M: Julian Wiedmann <jwi@linux.ibm.com>
|
||||
M: Karsten Graul <kgraul@linux.ibm.com>
|
||||
M: Ursula Braun <ubraun@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
@ -15250,7 +15245,6 @@ F: net/iucv/
|
||||
S390 NETWORK DRIVERS
|
||||
M: Julian Wiedmann <jwi@linux.ibm.com>
|
||||
M: Karsten Graul <kgraul@linux.ibm.com>
|
||||
M: Ursula Braun <ubraun@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
@ -15419,14 +15413,12 @@ F: Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
|
||||
F: drivers/nfc/s3fwrn5
|
||||
|
||||
SAMSUNG S5C73M3 CAMERA DRIVER
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
M: Andrzej Hajda <a.hajda@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/media/i2c/s5c73m3/*
|
||||
|
||||
SAMSUNG S5K5BAF CAMERA DRIVER
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
M: Andrzej Hajda <a.hajda@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
@ -15444,7 +15436,6 @@ F: Documentation/devicetree/bindings/crypto/samsung-sss.yaml
|
||||
F: drivers/crypto/s5p-sss.c
|
||||
|
||||
SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
@ -15492,7 +15483,6 @@ T: git https://github.com/lmajewski/linux-samsung-thermal.git
|
||||
F: drivers/thermal/samsung/
|
||||
|
||||
SAMSUNG USB2 PHY DRIVER
|
||||
M: Kamil Debski <kamil@wypas.org>
|
||||
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Supported
|
||||
@ -15791,9 +15781,8 @@ F: drivers/slimbus/
|
||||
F: include/linux/slimbus.h
|
||||
|
||||
SFC NETWORK DRIVER
|
||||
M: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
|
||||
M: Edward Cree <ecree@solarflare.com>
|
||||
M: Martin Habets <mhabets@solarflare.com>
|
||||
M: Edward Cree <ecree.xilinx@gmail.com>
|
||||
M: Martin Habets <habetsm.xilinx@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/sfc/
|
||||
@ -15821,7 +15810,6 @@ S: Maintained
|
||||
F: drivers/misc/sgi-xp/
|
||||
|
||||
SHARED MEMORY COMMUNICATIONS (SMC) SOCKETS
|
||||
M: Ursula Braun <ubraun@linux.ibm.com>
|
||||
M: Karsten Graul <kgraul@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
S: Supported
|
||||
@ -18083,7 +18071,7 @@ M: Yu Chen <chenyu56@huawei.com>
|
||||
M: Binghui Wang <wangbinghui@hisilicon.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt
|
||||
F: Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
|
||||
F: drivers/phy/hisilicon/phy-hi3660-usb3.c
|
||||
|
||||
USB ISP116X DRIVER
|
||||
@ -18168,6 +18156,14 @@ L: linux-usb@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/usb/class/usblp.c
|
||||
|
||||
USB RAW GADGET DRIVER
|
||||
R: Andrey Konovalov <andreyknvl@gmail.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/usb/raw-gadget.rst
|
||||
F: drivers/usb/gadget/legacy/raw_gadget.c
|
||||
F: include/uapi/linux/usb/raw_gadget.h
|
||||
|
||||
USB QMI WWAN NETWORK DRIVER
|
||||
M: Bjørn Mork <bjorn@mork.no>
|
||||
L: netdev@vger.kernel.org
|
||||
@ -18993,12 +18989,18 @@ L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
N: axp[128]
|
||||
|
||||
X.25 NETWORK LAYER
|
||||
M: Andrew Hendry <andrew.hendry@gmail.com>
|
||||
X.25 STACK
|
||||
M: Martin Schiller <ms@dev.tdt.de>
|
||||
L: linux-x25@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
S: Maintained
|
||||
F: Documentation/networking/lapb-module.rst
|
||||
F: Documentation/networking/x25*
|
||||
F: drivers/net/wan/hdlc_x25.c
|
||||
F: drivers/net/wan/lapbether.c
|
||||
F: include/*/lapb.h
|
||||
F: include/net/x25*
|
||||
F: include/uapi/linux/x25.h
|
||||
F: net/lapb/
|
||||
F: net/x25/
|
||||
|
||||
X86 ARCHITECTURE (32-BIT AND 64-BIT)
|
||||
|
||||
6
Makefile
6
Makefile
@ -2,7 +2,7 @@
|
||||
VERSION = 5
|
||||
PATCHLEVEL = 10
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc2
|
||||
EXTRAVERSION = -rc6
|
||||
NAME = Kleptomaniac Octopus
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@ -433,7 +433,6 @@ NM = llvm-nm
|
||||
OBJCOPY = llvm-objcopy
|
||||
OBJDUMP = llvm-objdump
|
||||
READELF = llvm-readelf
|
||||
OBJSIZE = llvm-size
|
||||
STRIP = llvm-strip
|
||||
else
|
||||
CC = $(CROSS_COMPILE)gcc
|
||||
@ -443,7 +442,6 @@ NM = $(CROSS_COMPILE)nm
|
||||
OBJCOPY = $(CROSS_COMPILE)objcopy
|
||||
OBJDUMP = $(CROSS_COMPILE)objdump
|
||||
READELF = $(CROSS_COMPILE)readelf
|
||||
OBJSIZE = $(CROSS_COMPILE)size
|
||||
STRIP = $(CROSS_COMPILE)strip
|
||||
endif
|
||||
PAHOLE = pahole
|
||||
@ -509,7 +507,7 @@ KBUILD_LDFLAGS :=
|
||||
CLANG_FLAGS :=
|
||||
|
||||
export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC
|
||||
export CPP AR NM STRIP OBJCOPY OBJDUMP OBJSIZE READELF PAHOLE RESOLVE_BTFIDS LEX YACC AWK INSTALLKERNEL
|
||||
export CPP AR NM STRIP OBJCOPY OBJDUMP READELF PAHOLE RESOLVE_BTFIDS LEX YACC AWK INSTALLKERNEL
|
||||
export PERL PYTHON PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
|
||||
export KGZIP KBZIP2 KLZOP LZMA LZ4 XZ ZSTD
|
||||
export KBUILD_HOSTCXXFLAGS KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS LDFLAGS_MODULE
|
||||
|
||||
@ -57,7 +57,7 @@ EXPORT_SYMBOL(pm_power_off);
|
||||
void arch_cpu_idle(void)
|
||||
{
|
||||
wtint(0);
|
||||
local_irq_enable();
|
||||
raw_local_irq_enable();
|
||||
}
|
||||
|
||||
void arch_cpu_idle_dead(void)
|
||||
|
||||
@ -243,10 +243,8 @@ static inline int constant_fls(unsigned int x)
|
||||
x <<= 2;
|
||||
r -= 2;
|
||||
}
|
||||
if (!(x & 0x80000000u)) {
|
||||
x <<= 1;
|
||||
if (!(x & 0x80000000u))
|
||||
r -= 1;
|
||||
}
|
||||
return r;
|
||||
}
|
||||
|
||||
|
||||
@ -134,8 +134,10 @@
|
||||
|
||||
#ifdef CONFIG_ARC_HAS_PAE40
|
||||
#define PTE_BITS_NON_RWX_IN_PD1 (0xff00000000 | PAGE_MASK | _PAGE_CACHEABLE)
|
||||
#define MAX_POSSIBLE_PHYSMEM_BITS 40
|
||||
#else
|
||||
#define PTE_BITS_NON_RWX_IN_PD1 (PAGE_MASK | _PAGE_CACHEABLE)
|
||||
#define MAX_POSSIBLE_PHYSMEM_BITS 32
|
||||
#endif
|
||||
|
||||
/**************************************************************************
|
||||
|
||||
@ -67,7 +67,22 @@
|
||||
sr r5, [ARC_REG_LPB_CTRL]
|
||||
1:
|
||||
#endif /* CONFIG_ARC_LPB_DISABLE */
|
||||
#endif
|
||||
|
||||
/* On HSDK, CCMs need to remapped super early */
|
||||
#ifdef CONFIG_ARC_SOC_HSDK
|
||||
mov r6, 0x60000000
|
||||
lr r5, [ARC_REG_ICCM_BUILD]
|
||||
breq r5, 0, 1f
|
||||
sr r6, [ARC_REG_AUX_ICCM]
|
||||
1:
|
||||
lr r5, [ARC_REG_DCCM_BUILD]
|
||||
breq r5, 0, 2f
|
||||
sr r6, [ARC_REG_AUX_DCCM]
|
||||
2:
|
||||
#endif /* CONFIG_ARC_SOC_HSDK */
|
||||
|
||||
#endif /* CONFIG_ISA_ARCV2 */
|
||||
|
||||
; Config DSP_CTRL properly, so kernel may use integer multiply,
|
||||
; multiply-accumulate, and divide operations
|
||||
DSP_EARLY_INIT
|
||||
|
||||
@ -38,15 +38,27 @@
|
||||
|
||||
#ifdef CONFIG_ARC_DW2_UNWIND
|
||||
|
||||
static void seed_unwind_frame_info(struct task_struct *tsk,
|
||||
struct pt_regs *regs,
|
||||
struct unwind_frame_info *frame_info)
|
||||
static int
|
||||
seed_unwind_frame_info(struct task_struct *tsk, struct pt_regs *regs,
|
||||
struct unwind_frame_info *frame_info)
|
||||
{
|
||||
/*
|
||||
* synchronous unwinding (e.g. dump_stack)
|
||||
* - uses current values of SP and friends
|
||||
*/
|
||||
if (tsk == NULL && regs == NULL) {
|
||||
if (regs) {
|
||||
/*
|
||||
* Asynchronous unwinding of intr/exception
|
||||
* - Just uses the pt_regs passed
|
||||
*/
|
||||
frame_info->task = tsk;
|
||||
|
||||
frame_info->regs.r27 = regs->fp;
|
||||
frame_info->regs.r28 = regs->sp;
|
||||
frame_info->regs.r31 = regs->blink;
|
||||
frame_info->regs.r63 = regs->ret;
|
||||
frame_info->call_frame = 0;
|
||||
} else if (tsk == NULL || tsk == current) {
|
||||
/*
|
||||
* synchronous unwinding (e.g. dump_stack)
|
||||
* - uses current values of SP and friends
|
||||
*/
|
||||
unsigned long fp, sp, blink, ret;
|
||||
frame_info->task = current;
|
||||
|
||||
@ -63,13 +75,17 @@ static void seed_unwind_frame_info(struct task_struct *tsk,
|
||||
frame_info->regs.r31 = blink;
|
||||
frame_info->regs.r63 = ret;
|
||||
frame_info->call_frame = 0;
|
||||
} else if (regs == NULL) {
|
||||
} else {
|
||||
/*
|
||||
* Asynchronous unwinding of sleeping task
|
||||
* - Gets SP etc from task's pt_regs (saved bottom of kernel
|
||||
* mode stack of task)
|
||||
* Asynchronous unwinding of a likely sleeping task
|
||||
* - first ensure it is actually sleeping
|
||||
* - if so, it will be in __switch_to, kernel mode SP of task
|
||||
* is safe-kept and BLINK at a well known location in there
|
||||
*/
|
||||
|
||||
if (tsk->state == TASK_RUNNING)
|
||||
return -1;
|
||||
|
||||
frame_info->task = tsk;
|
||||
|
||||
frame_info->regs.r27 = TSK_K_FP(tsk);
|
||||
@ -90,19 +106,8 @@ static void seed_unwind_frame_info(struct task_struct *tsk,
|
||||
frame_info->regs.r28 += 60;
|
||||
frame_info->call_frame = 0;
|
||||
|
||||
} else {
|
||||
/*
|
||||
* Asynchronous unwinding of intr/exception
|
||||
* - Just uses the pt_regs passed
|
||||
*/
|
||||
frame_info->task = tsk;
|
||||
|
||||
frame_info->regs.r27 = regs->fp;
|
||||
frame_info->regs.r28 = regs->sp;
|
||||
frame_info->regs.r31 = regs->blink;
|
||||
frame_info->regs.r63 = regs->ret;
|
||||
frame_info->call_frame = 0;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
#endif
|
||||
@ -112,11 +117,12 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs,
|
||||
int (*consumer_fn) (unsigned int, void *), void *arg)
|
||||
{
|
||||
#ifdef CONFIG_ARC_DW2_UNWIND
|
||||
int ret = 0;
|
||||
int ret = 0, cnt = 0;
|
||||
unsigned int address;
|
||||
struct unwind_frame_info frame_info;
|
||||
|
||||
seed_unwind_frame_info(tsk, regs, &frame_info);
|
||||
if (seed_unwind_frame_info(tsk, regs, &frame_info))
|
||||
return 0;
|
||||
|
||||
while (1) {
|
||||
address = UNW_PC(&frame_info);
|
||||
@ -132,6 +138,11 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs,
|
||||
break;
|
||||
|
||||
frame_info.regs.r63 = frame_info.regs.r31;
|
||||
|
||||
if (cnt++ > 128) {
|
||||
printk("unwinder looping too long, aborting !\n");
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
||||
return address; /* return the last address it saw */
|
||||
|
||||
@ -30,14 +30,14 @@
|
||||
* -Changes related to MMU v2 (Rel 4.8)
|
||||
*
|
||||
* Vineetg: Aug 29th 2008
|
||||
* -In TLB Flush operations (Metal Fix MMU) there is a explict command to
|
||||
* -In TLB Flush operations (Metal Fix MMU) there is a explicit command to
|
||||
* flush Micro-TLBS. If TLB Index Reg is invalid prior to TLBIVUTLB cmd,
|
||||
* it fails. Thus need to load it with ANY valid value before invoking
|
||||
* TLBIVUTLB cmd
|
||||
*
|
||||
* Vineetg: Aug 21th 2008:
|
||||
* -Reduced the duration of IRQ lockouts in TLB Flush routines
|
||||
* -Multiple copies of TLB erase code seperated into a "single" function
|
||||
* -Multiple copies of TLB erase code separated into a "single" function
|
||||
* -In TLB Flush routines, interrupt disabling moved UP to retrieve ASID
|
||||
* in interrupt-safe region.
|
||||
*
|
||||
@ -66,7 +66,7 @@
|
||||
*
|
||||
* Although J-TLB is 2 way set assoc, ARC700 caches J-TLB into uTLBS which has
|
||||
* much higher associativity. u-D-TLB is 8 ways, u-I-TLB is 4 ways.
|
||||
* Given this, the thrasing problem should never happen because once the 3
|
||||
* Given this, the thrashing problem should never happen because once the 3
|
||||
* J-TLB entries are created (even though 3rd will knock out one of the prev
|
||||
* two), the u-D-TLB and u-I-TLB will have what is required to accomplish memcpy
|
||||
*
|
||||
@ -127,7 +127,7 @@ static void utlb_invalidate(void)
|
||||
* There was however an obscure hardware bug, where uTLB flush would
|
||||
* fail when a prior probe for J-TLB (both totally unrelated) would
|
||||
* return lkup err - because the entry didn't exist in MMU.
|
||||
* The Workround was to set Index reg with some valid value, prior to
|
||||
* The Workaround was to set Index reg with some valid value, prior to
|
||||
* flush. This was fixed in MMU v3
|
||||
*/
|
||||
unsigned int idx;
|
||||
@ -272,7 +272,7 @@ noinline void local_flush_tlb_all(void)
|
||||
}
|
||||
|
||||
/*
|
||||
* Flush the entrie MM for userland. The fastest way is to move to Next ASID
|
||||
* Flush the entire MM for userland. The fastest way is to move to Next ASID
|
||||
*/
|
||||
noinline void local_flush_tlb_mm(struct mm_struct *mm)
|
||||
{
|
||||
@ -303,7 +303,7 @@ noinline void local_flush_tlb_mm(struct mm_struct *mm)
|
||||
* Difference between this and Kernel Range Flush is
|
||||
* -Here the fastest way (if range is too large) is to move to next ASID
|
||||
* without doing any explicit Shootdown
|
||||
* -In case of kernel Flush, entry has to be shot down explictly
|
||||
* -In case of kernel Flush, entry has to be shot down explicitly
|
||||
*/
|
||||
void local_flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
|
||||
unsigned long end)
|
||||
@ -620,7 +620,7 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long vaddr_unaligned,
|
||||
* Super Page size is configurable in hardware (4K to 16M), but fixed once
|
||||
* RTL builds.
|
||||
*
|
||||
* The exact THP size a Linx configuration will support is a function of:
|
||||
* The exact THP size a Linux configuration will support is a function of:
|
||||
* - MMU page size (typical 8K, RTL fixed)
|
||||
* - software page walker address split between PGD:PTE:PFN (typical
|
||||
* 11:8:13, but can be changed with 1 line)
|
||||
@ -698,7 +698,7 @@ void local_flush_pmd_tlb_range(struct vm_area_struct *vma, unsigned long start,
|
||||
|
||||
#endif
|
||||
|
||||
/* Read the Cache Build Confuration Registers, Decode them and save into
|
||||
/* Read the Cache Build Configuration Registers, Decode them and save into
|
||||
* the cpuinfo structure for later use.
|
||||
* No Validation is done here, simply read/convert the BCRs
|
||||
*/
|
||||
@ -803,13 +803,13 @@ void arc_mmu_init(void)
|
||||
pr_info("%s", arc_mmu_mumbojumbo(0, str, sizeof(str)));
|
||||
|
||||
/*
|
||||
* Can't be done in processor.h due to header include depenedencies
|
||||
* Can't be done in processor.h due to header include dependencies
|
||||
*/
|
||||
BUILD_BUG_ON(!IS_ALIGNED((CONFIG_ARC_KVADDR_SIZE << 20), PMD_SIZE));
|
||||
|
||||
/*
|
||||
* stack top size sanity check,
|
||||
* Can't be done in processor.h due to header include depenedencies
|
||||
* Can't be done in processor.h due to header include dependencies
|
||||
*/
|
||||
BUILD_BUG_ON(!IS_ALIGNED(STACK_TOP, PMD_SIZE));
|
||||
|
||||
@ -881,7 +881,7 @@ void arc_mmu_init(void)
|
||||
* the duplicate one.
|
||||
* -Knob to be verbose abt it.(TODO: hook them up to debugfs)
|
||||
*/
|
||||
volatile int dup_pd_silent; /* Be slient abt it or complain (default) */
|
||||
volatile int dup_pd_silent; /* Be silent abt it or complain (default) */
|
||||
|
||||
void do_tlb_overlap_fault(unsigned long cause, unsigned long address,
|
||||
struct pt_regs *regs)
|
||||
@ -948,7 +948,7 @@ void do_tlb_overlap_fault(unsigned long cause, unsigned long address,
|
||||
|
||||
/***********************************************************************
|
||||
* Diagnostic Routines
|
||||
* -Called from Low Level TLB Hanlders if things don;t look good
|
||||
* -Called from Low Level TLB Handlers if things don;t look good
|
||||
**********************************************************************/
|
||||
|
||||
#ifdef CONFIG_ARC_DBG_TLB_PARANOIA
|
||||
|
||||
@ -17,22 +17,6 @@ int arc_hsdk_axi_dmac_coherent __section(".data") = 0;
|
||||
|
||||
#define ARC_CCM_UNUSED_ADDR 0x60000000
|
||||
|
||||
static void __init hsdk_init_per_cpu(unsigned int cpu)
|
||||
{
|
||||
/*
|
||||
* By default ICCM is mapped to 0x7z while this area is used for
|
||||
* kernel virtual mappings, so move it to currently unused area.
|
||||
*/
|
||||
if (cpuinfo_arc700[cpu].iccm.sz)
|
||||
write_aux_reg(ARC_REG_AUX_ICCM, ARC_CCM_UNUSED_ADDR);
|
||||
|
||||
/*
|
||||
* By default DCCM is mapped to 0x8z while this area is used by kernel,
|
||||
* so move it to currently unused area.
|
||||
*/
|
||||
if (cpuinfo_arc700[cpu].dccm.sz)
|
||||
write_aux_reg(ARC_REG_AUX_DCCM, ARC_CCM_UNUSED_ADDR);
|
||||
}
|
||||
|
||||
#define ARC_PERIPHERAL_BASE 0xf0000000
|
||||
#define CREG_BASE (ARC_PERIPHERAL_BASE + 0x1000)
|
||||
@ -339,5 +323,4 @@ static const char *hsdk_compat[] __initconst = {
|
||||
MACHINE_START(SIMULATION, "hsdk")
|
||||
.dt_compat = hsdk_compat,
|
||||
.init_early = hsdk_init_early,
|
||||
.init_per_cpu = hsdk_init_per_cpu,
|
||||
MACHINE_END
|
||||
|
||||
@ -1472,6 +1472,9 @@ ENTRY(efi_enter_kernel)
|
||||
@ issued from HYP mode take us to the correct handler code. We
|
||||
@ will disable the MMU before jumping to the kernel proper.
|
||||
@
|
||||
ARM( bic r1, r1, #(1 << 30) ) @ clear HSCTLR.TE
|
||||
THUMB( orr r1, r1, #(1 << 30) ) @ set HSCTLR.TE
|
||||
mcr p15, 4, r1, c1, c0, 0
|
||||
adr r0, __hyp_reentry_vectors
|
||||
mcr p15, 4, r0, c12, c0, 0 @ set HYP vector base (HVBAR)
|
||||
isb
|
||||
|
||||
@ -521,7 +521,7 @@
|
||||
ranges = <0x0 0x100000 0x8000>;
|
||||
|
||||
mac_sw: switch@0 {
|
||||
compatible = "ti,am4372-cpsw","ti,cpsw-switch";
|
||||
compatible = "ti,am4372-cpsw-switch", "ti,cpsw-switch";
|
||||
reg = <0x0 0x4000>;
|
||||
ranges = <0 0 0x4000>;
|
||||
clocks = <&cpsw_125mhz_gclk>, <&dpll_clksel_mac_clk>;
|
||||
|
||||
@ -32,8 +32,8 @@
|
||||
interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "int0", "int1";
|
||||
clocks = <&mcan_clk>, <&l3_iclk_div>;
|
||||
clock-names = "cclk", "hclk";
|
||||
clocks = <&l3_iclk_div>, <&mcan_clk>;
|
||||
clock-names = "hclk", "cclk";
|
||||
bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
|
||||
};
|
||||
};
|
||||
|
||||
@ -122,7 +122,6 @@
|
||||
};
|
||||
|
||||
&clock {
|
||||
clocks = <&clock CLK_XUSBXTI>;
|
||||
assigned-clocks = <&clock CLK_FOUT_EPLL>;
|
||||
assigned-clock-rates = <45158401>;
|
||||
};
|
||||
|
||||
@ -59,7 +59,7 @@
|
||||
MX50_PAD_CSPI_MISO__CSPI_MISO 0x00
|
||||
MX50_PAD_CSPI_MOSI__CSPI_MOSI 0x00
|
||||
MX50_PAD_CSPI_SS0__GPIO4_11 0xc4
|
||||
MX50_PAD_ECSPI1_MOSI__CSPI_SS1 0xf4
|
||||
MX50_PAD_ECSPI1_MOSI__GPIO4_13 0x84
|
||||
>;
|
||||
};
|
||||
|
||||
|
||||
@ -213,8 +213,8 @@
|
||||
#size-cells = <0>;
|
||||
|
||||
/* Microchip KSZ9031RNX PHY */
|
||||
rgmii_phy: ethernet-phy@4 {
|
||||
reg = <4>;
|
||||
rgmii_phy: ethernet-phy@0 {
|
||||
reg = <0>;
|
||||
interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
|
||||
reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
|
||||
reset-assert-us = <10000>;
|
||||
|
||||
@ -98,7 +98,7 @@
|
||||
&fec {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_enet>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
||||
@ -46,6 +46,16 @@
|
||||
linux,code = <KEY_A>;
|
||||
gpios = <&gpiof 3 GPIO_ACTIVE_LOW>;
|
||||
};
|
||||
|
||||
/*
|
||||
* The EXTi IRQ line 0 is shared with PMIC,
|
||||
* so mark this as polled GPIO key.
|
||||
*/
|
||||
button-2 {
|
||||
label = "TA3-GPIO-C";
|
||||
linux,code = <KEY_C>;
|
||||
gpios = <&gpiog 0 GPIO_ACTIVE_LOW>;
|
||||
};
|
||||
};
|
||||
|
||||
gpio-keys {
|
||||
@ -59,13 +69,6 @@
|
||||
wakeup-source;
|
||||
};
|
||||
|
||||
button-2 {
|
||||
label = "TA3-GPIO-C";
|
||||
linux,code = <KEY_C>;
|
||||
gpios = <&gpioi 11 GPIO_ACTIVE_LOW>;
|
||||
wakeup-source;
|
||||
};
|
||||
|
||||
button-3 {
|
||||
label = "TA4-GPIO-D";
|
||||
linux,code = <KEY_D>;
|
||||
@ -79,7 +82,7 @@
|
||||
|
||||
led-0 {
|
||||
label = "green:led5";
|
||||
gpios = <&gpiog 2 GPIO_ACTIVE_HIGH>;
|
||||
gpios = <&gpioc 6 GPIO_ACTIVE_HIGH>;
|
||||
default-state = "off";
|
||||
};
|
||||
|
||||
|
||||
@ -68,6 +68,7 @@
|
||||
gpio = <&gpiog 3 GPIO_ACTIVE_LOW>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
vin-supply = <&vdd>;
|
||||
};
|
||||
};
|
||||
|
||||
@ -202,6 +203,7 @@
|
||||
|
||||
vdda: ldo1 {
|
||||
regulator-name = "vdda";
|
||||
regulator-always-on;
|
||||
regulator-min-microvolt = <2900000>;
|
||||
regulator-max-microvolt = <2900000>;
|
||||
interrupts = <IT_CURLIM_LDO1 0>;
|
||||
|
||||
@ -21,6 +21,10 @@
|
||||
};
|
||||
};
|
||||
|
||||
&dts {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&i2c4 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&i2c4_pins_a>;
|
||||
|
||||
@ -154,7 +154,7 @@
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&gmac_rgmii_pins>;
|
||||
phy-handle = <&phy1>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
||||
@ -130,7 +130,7 @@
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&gmac_rgmii_pins>;
|
||||
phy-handle = <&phy1>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
phy-supply = <®_gmac_3v3>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -151,7 +151,7 @@
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&gmac_rgmii_pins>;
|
||||
phy-handle = <&phy1>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
||||
@ -131,7 +131,7 @@
|
||||
pinctrl-0 = <&emac_rgmii_pins>;
|
||||
phy-supply = <®_sw>;
|
||||
phy-handle = <&rgmii_phy>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
allwinner,rx-delay-ps = <700>;
|
||||
allwinner,tx-delay-ps = <700>;
|
||||
status = "okay";
|
||||
|
||||
@ -183,7 +183,7 @@
|
||||
pinctrl-0 = <&emac_rgmii_pins>;
|
||||
phy-supply = <®_dldo4>;
|
||||
phy-handle = <&rgmii_phy>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
||||
@ -53,11 +53,6 @@
|
||||
};
|
||||
};
|
||||
|
||||
&emac {
|
||||
/* LEDs changed to active high on the plus */
|
||||
/delete-property/ allwinner,leds-active-low;
|
||||
};
|
||||
|
||||
&mmc1 {
|
||||
vmmc-supply = <®_vcc3v3>;
|
||||
bus-width = <4>;
|
||||
|
||||
@ -67,7 +67,7 @@
|
||||
pinctrl-0 = <&emac_rgmii_pins>;
|
||||
phy-supply = <®_gmac_3v3>;
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
||||
@ -129,7 +129,7 @@
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&gmac_rgmii_pins>;
|
||||
phy-handle = <&phy1>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
phy-supply = <®_dc1sw>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -129,7 +129,7 @@
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&gmac_rgmii_pins>;
|
||||
phy-handle = <&phy1>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
phy-supply = <®_cldo1>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -124,7 +124,7 @@
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&gmac_rgmii_pins>;
|
||||
phy-handle = <&phy1>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
phy-supply = <®_cldo1>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -126,7 +126,7 @@
|
||||
pinctrl-0 = <&emac_rgmii_pins>;
|
||||
phy-supply = <®_gmac_3v3>;
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -406,6 +406,9 @@
|
||||
};
|
||||
};
|
||||
|
||||
&mdio1 {
|
||||
clock-frequency = <5000000>;
|
||||
};
|
||||
|
||||
&iomuxc {
|
||||
pinctrl_gpio_e6185_eeprom_sel: pinctrl-gpio-e6185-eeprom-spi0 {
|
||||
|
||||
@ -44,20 +44,20 @@ int kprobe_exceptions_notify(struct notifier_block *self,
|
||||
unsigned long val, void *data);
|
||||
|
||||
/* optinsn template addresses */
|
||||
extern __visible kprobe_opcode_t optprobe_template_entry;
|
||||
extern __visible kprobe_opcode_t optprobe_template_val;
|
||||
extern __visible kprobe_opcode_t optprobe_template_call;
|
||||
extern __visible kprobe_opcode_t optprobe_template_end;
|
||||
extern __visible kprobe_opcode_t optprobe_template_sub_sp;
|
||||
extern __visible kprobe_opcode_t optprobe_template_add_sp;
|
||||
extern __visible kprobe_opcode_t optprobe_template_restore_begin;
|
||||
extern __visible kprobe_opcode_t optprobe_template_restore_orig_insn;
|
||||
extern __visible kprobe_opcode_t optprobe_template_restore_end;
|
||||
extern __visible kprobe_opcode_t optprobe_template_entry[];
|
||||
extern __visible kprobe_opcode_t optprobe_template_val[];
|
||||
extern __visible kprobe_opcode_t optprobe_template_call[];
|
||||
extern __visible kprobe_opcode_t optprobe_template_end[];
|
||||
extern __visible kprobe_opcode_t optprobe_template_sub_sp[];
|
||||
extern __visible kprobe_opcode_t optprobe_template_add_sp[];
|
||||
extern __visible kprobe_opcode_t optprobe_template_restore_begin[];
|
||||
extern __visible kprobe_opcode_t optprobe_template_restore_orig_insn[];
|
||||
extern __visible kprobe_opcode_t optprobe_template_restore_end[];
|
||||
|
||||
#define MAX_OPTIMIZED_LENGTH 4
|
||||
#define MAX_OPTINSN_SIZE \
|
||||
((unsigned long)&optprobe_template_end - \
|
||||
(unsigned long)&optprobe_template_entry)
|
||||
((unsigned long)optprobe_template_end - \
|
||||
(unsigned long)optprobe_template_entry)
|
||||
#define RELATIVEJUMP_SIZE 4
|
||||
|
||||
struct arch_optimized_insn {
|
||||
|
||||
@ -75,6 +75,8 @@
|
||||
#define PTE_HWTABLE_OFF (PTE_HWTABLE_PTRS * sizeof(pte_t))
|
||||
#define PTE_HWTABLE_SIZE (PTRS_PER_PTE * sizeof(u32))
|
||||
|
||||
#define MAX_POSSIBLE_PHYSMEM_BITS 32
|
||||
|
||||
/*
|
||||
* PMD_SHIFT determines the size of the area a second-level page table can map
|
||||
* PGDIR_SHIFT determines what a third-level page table entry can map
|
||||
|
||||
@ -25,6 +25,8 @@
|
||||
#define PTE_HWTABLE_OFF (0)
|
||||
#define PTE_HWTABLE_SIZE (PTRS_PER_PTE * sizeof(u64))
|
||||
|
||||
#define MAX_POSSIBLE_PHYSMEM_BITS 40
|
||||
|
||||
/*
|
||||
* PGDIR_SHIFT determines the size a top-level page table entry can map.
|
||||
*/
|
||||
|
||||
@ -32,8 +32,7 @@ u64 perf_reg_abi(struct task_struct *task)
|
||||
}
|
||||
|
||||
void perf_get_regs_user(struct perf_regs *regs_user,
|
||||
struct pt_regs *regs,
|
||||
struct pt_regs *regs_user_copy)
|
||||
struct pt_regs *regs)
|
||||
{
|
||||
regs_user->regs = task_pt_regs(current);
|
||||
regs_user->abi = perf_reg_abi(current);
|
||||
|
||||
@ -71,7 +71,7 @@ void arch_cpu_idle(void)
|
||||
arm_pm_idle();
|
||||
else
|
||||
cpu_do_idle();
|
||||
local_irq_enable();
|
||||
raw_local_irq_enable();
|
||||
}
|
||||
|
||||
void arch_cpu_idle_prepare(void)
|
||||
|
||||
@ -7,7 +7,6 @@ config ARCH_OMAP2
|
||||
depends on ARCH_MULTI_V6
|
||||
select ARCH_OMAP2PLUS
|
||||
select CPU_V6
|
||||
select PM_GENERIC_DOMAINS if PM
|
||||
select SOC_HAS_OMAP2_SDRC
|
||||
|
||||
config ARCH_OMAP3
|
||||
@ -106,6 +105,8 @@ config ARCH_OMAP2PLUS
|
||||
select OMAP_DM_TIMER
|
||||
select OMAP_GPMC
|
||||
select PINCTRL
|
||||
select PM_GENERIC_DOMAINS if PM
|
||||
select PM_GENERIC_DOMAINS_OF if PM
|
||||
select RESET_CONTROLLER
|
||||
select SOC_BUS
|
||||
select TI_SYSC
|
||||
|
||||
@ -175,8 +175,11 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
|
||||
if (mpuss_can_lose_context) {
|
||||
error = cpu_cluster_pm_enter();
|
||||
if (error) {
|
||||
omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
|
||||
goto cpu_cluster_pm_out;
|
||||
index = 0;
|
||||
cx = state_ptr + index;
|
||||
pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
|
||||
omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
|
||||
mpuss_can_lose_context = 0;
|
||||
}
|
||||
}
|
||||
}
|
||||
@ -184,7 +187,6 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
|
||||
omap4_enter_lowpower(dev->cpu, cx->cpu_state);
|
||||
cpu_done[dev->cpu] = true;
|
||||
|
||||
cpu_cluster_pm_out:
|
||||
/* Wakeup CPU1 only if it is not offlined */
|
||||
if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
|
||||
|
||||
|
||||
@ -354,8 +354,8 @@ static void __init free_highpages(void)
|
||||
/* set highmem page free */
|
||||
for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
|
||||
&range_start, &range_end, NULL) {
|
||||
unsigned long start = PHYS_PFN(range_start);
|
||||
unsigned long end = PHYS_PFN(range_end);
|
||||
unsigned long start = PFN_UP(range_start);
|
||||
unsigned long end = PFN_DOWN(range_end);
|
||||
|
||||
/* Ignore complete lowmem entries */
|
||||
if (end <= max_low)
|
||||
|
||||
@ -85,21 +85,21 @@ asm (
|
||||
"optprobe_template_end:\n");
|
||||
|
||||
#define TMPL_VAL_IDX \
|
||||
((unsigned long *)&optprobe_template_val - (unsigned long *)&optprobe_template_entry)
|
||||
((unsigned long *)optprobe_template_val - (unsigned long *)optprobe_template_entry)
|
||||
#define TMPL_CALL_IDX \
|
||||
((unsigned long *)&optprobe_template_call - (unsigned long *)&optprobe_template_entry)
|
||||
((unsigned long *)optprobe_template_call - (unsigned long *)optprobe_template_entry)
|
||||
#define TMPL_END_IDX \
|
||||
((unsigned long *)&optprobe_template_end - (unsigned long *)&optprobe_template_entry)
|
||||
((unsigned long *)optprobe_template_end - (unsigned long *)optprobe_template_entry)
|
||||
#define TMPL_ADD_SP \
|
||||
((unsigned long *)&optprobe_template_add_sp - (unsigned long *)&optprobe_template_entry)
|
||||
((unsigned long *)optprobe_template_add_sp - (unsigned long *)optprobe_template_entry)
|
||||
#define TMPL_SUB_SP \
|
||||
((unsigned long *)&optprobe_template_sub_sp - (unsigned long *)&optprobe_template_entry)
|
||||
((unsigned long *)optprobe_template_sub_sp - (unsigned long *)optprobe_template_entry)
|
||||
#define TMPL_RESTORE_BEGIN \
|
||||
((unsigned long *)&optprobe_template_restore_begin - (unsigned long *)&optprobe_template_entry)
|
||||
((unsigned long *)optprobe_template_restore_begin - (unsigned long *)optprobe_template_entry)
|
||||
#define TMPL_RESTORE_ORIGN_INSN \
|
||||
((unsigned long *)&optprobe_template_restore_orig_insn - (unsigned long *)&optprobe_template_entry)
|
||||
((unsigned long *)optprobe_template_restore_orig_insn - (unsigned long *)optprobe_template_entry)
|
||||
#define TMPL_RESTORE_END \
|
||||
((unsigned long *)&optprobe_template_restore_end - (unsigned long *)&optprobe_template_entry)
|
||||
((unsigned long *)optprobe_template_restore_end - (unsigned long *)optprobe_template_entry)
|
||||
|
||||
/*
|
||||
* ARM can always optimize an instruction when using ARM ISA, except
|
||||
@ -234,7 +234,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe *op, struct kprobe *or
|
||||
}
|
||||
|
||||
/* Copy arch-dep-instance from template. */
|
||||
memcpy(code, (unsigned long *)&optprobe_template_entry,
|
||||
memcpy(code, (unsigned long *)optprobe_template_entry,
|
||||
TMPL_END_IDX * sizeof(kprobe_opcode_t));
|
||||
|
||||
/* Adjust buffer according to instruction. */
|
||||
|
||||
@ -1002,7 +1002,7 @@ config NUMA
|
||||
config NODES_SHIFT
|
||||
int "Maximum NUMA Nodes (as a power of 2)"
|
||||
range 1 10
|
||||
default "2"
|
||||
default "4"
|
||||
depends on NEED_MULTIPLE_NODES
|
||||
help
|
||||
Specify the maximum number of NUMA Nodes available on the target
|
||||
|
||||
@ -105,7 +105,7 @@
|
||||
&emac {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&rgmii_pins>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
phy-supply = <®_dc1sw>;
|
||||
status = "okay";
|
||||
|
||||
@ -120,7 +120,7 @@
|
||||
&emac {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&rgmii_pins>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
phy-supply = <®_gmac_3v3>;
|
||||
status = "okay";
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
&emac {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&rgmii_pins>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-txid";
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -122,9 +122,6 @@
|
||||
status = "okay";
|
||||
|
||||
port {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
csi_ep: endpoint {
|
||||
remote-endpoint = <&ov5640_ep>;
|
||||
bus-width = <8>;
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user