Merge remote-tracking branch 'torvalds/master' into perf/core
To pick up fixes. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This commit is contained in:
commit
1f195e557d
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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -24,7 +24,6 @@ fit into other categories.
|
||||
isl29003
|
||||
lis3lv02d
|
||||
max6875
|
||||
mic/index
|
||||
pci-endpoint-test
|
||||
spear-pcie-gadget
|
||||
uacce
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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>`.
|
||||
|
@ -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
|
||||
|
117
MAINTAINERS
117
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>
|
||||
@ -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/
|
||||
|
||||
@ -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>
|
||||
@ -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/
|
||||
@ -15238,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/
|
||||
@ -15249,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/
|
||||
@ -15418,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
|
||||
@ -15443,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
|
||||
@ -15491,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
|
||||
@ -15790,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/
|
||||
@ -15820,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
|
||||
@ -18167,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
|
||||
@ -18992,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>;
|
||||
|
@ -36,7 +36,7 @@
|
||||
pinctrl-0 = <&emac_rgmii_pins>;
|
||||
phy-supply = <®_gmac_3v3>;
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
/delete-property/ allwinner,leds-active-low;
|
||||
status = "okay";
|
||||
};
|
||||
|
@ -123,7 +123,7 @@
|
||||
pinctrl-0 = <&emac_rgmii_pins>;
|
||||
phy-supply = <®_gmac_3v3>;
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
@ -124,7 +124,7 @@
|
||||
pinctrl-0 = <&emac_rgmii_pins>;
|
||||
phy-supply = <®_gmac_3v3>;
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
@ -97,7 +97,7 @@
|
||||
&emac {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ext_rgmii_pins>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
phy-supply = <®_aldo2>;
|
||||
status = "okay";
|
||||
|
@ -100,7 +100,7 @@
|
||||
&emac {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ext_rgmii_pins>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
phy-handle = <&ext_rgmii_phy>;
|
||||
phy-supply = <®_gmac_3v3>;
|
||||
allwinner,rx-delay-ps = <200>;
|
||||
|
@ -159,7 +159,7 @@
|
||||
flash@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "n25q00a";
|
||||
compatible = "micron,mt25qu02g", "jedec,spi-nor";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <100000000>;
|
||||
|
||||
|
@ -192,7 +192,7 @@
|
||||
flash@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "n25q00a";
|
||||
compatible = "micron,mt25qu02g", "jedec,spi-nor";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <100000000>;
|
||||
|
||||
|
@ -5,20 +5,20 @@
|
||||
usb {
|
||||
compatible = "simple-bus";
|
||||
dma-ranges;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0x0 0x0 0x68500000 0x00400000>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
ranges = <0x0 0x0 0x0 0x68500000 0x0 0x00400000>;
|
||||
|
||||
usbphy0: usb-phy@0 {
|
||||
compatible = "brcm,sr-usb-combo-phy";
|
||||
reg = <0x00000000 0x100>;
|
||||
reg = <0x0 0x00000000 0x0 0x100>;
|
||||
#phy-cells = <1>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
xhci0: usb@1000 {
|
||||
compatible = "generic-xhci";
|
||||
reg = <0x00001000 0x1000>;
|
||||
reg = <0x0 0x00001000 0x0 0x1000>;
|
||||
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
|
||||
phys = <&usbphy0 1>, <&usbphy0 0>;
|
||||
phy-names = "phy0", "phy1";
|
||||
@ -28,7 +28,7 @@
|
||||
|
||||
bdc0: usb@2000 {
|
||||
compatible = "brcm,bdc-v0.16";
|
||||
reg = <0x00002000 0x1000>;
|
||||
reg = <0x0 0x00002000 0x0 0x1000>;
|
||||
interrupts = <GIC_SPI 259 IRQ_TYPE_LEVEL_HIGH>;
|
||||
phys = <&usbphy0 0>, <&usbphy0 1>;
|
||||
phy-names = "phy0", "phy1";
|
||||
@ -38,21 +38,21 @@
|
||||
|
||||
usbphy1: usb-phy@10000 {
|
||||
compatible = "brcm,sr-usb-combo-phy";
|
||||
reg = <0x00010000 0x100>;
|
||||
reg = <0x0 0x00010000 0x0 0x100>;
|
||||
#phy-cells = <1>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
usbphy2: usb-phy@20000 {
|
||||
compatible = "brcm,sr-usb-hs-phy";
|
||||
reg = <0x00020000 0x100>;
|
||||
reg = <0x0 0x00020000 0x0 0x100>;
|
||||
#phy-cells = <0>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
xhci1: usb@11000 {
|
||||
compatible = "generic-xhci";
|
||||
reg = <0x00011000 0x1000>;
|
||||
reg = <0x0 0x00011000 0x0 0x1000>;
|
||||
interrupts = <GIC_SPI 263 IRQ_TYPE_LEVEL_HIGH>;
|
||||
phys = <&usbphy1 1>, <&usbphy2>, <&usbphy1 0>;
|
||||
phy-names = "phy0", "phy1", "phy2";
|
||||
@ -62,7 +62,7 @@
|
||||
|
||||
bdc1: usb@21000 {
|
||||
compatible = "brcm,bdc-v0.16";
|
||||
reg = <0x00021000 0x1000>;
|
||||
reg = <0x0 0x00021000 0x0 0x1000>;
|
||||
interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
|
||||
phys = <&usbphy2>;
|
||||
phy-names = "phy0";
|
||||
|
@ -75,6 +75,7 @@
|
||||
&enetc_port0 {
|
||||
phy-handle = <&phy0>;
|
||||
phy-connection-type = "sgmii";
|
||||
managed = "in-band-status";
|
||||
status = "okay";
|
||||
|
||||
mdio {
|
||||
|
@ -1012,6 +1012,7 @@
|
||||
compatible = "fsl,ls1028a-rcpm", "fsl,qoriq-rcpm-2.1+";
|
||||
reg = <0x0 0x1e34040 0x0 0x1c>;
|
||||
#fsl,rcpm-wakeup-cells = <7>;
|
||||
little-endian;
|
||||
};
|
||||
|
||||
ftm_alarm0: timer@2800000 {
|
||||
|
@ -805,6 +805,7 @@
|
||||
compatible = "fsl,ls1088a-rcpm", "fsl,qoriq-rcpm-2.1+";
|
||||
reg = <0x0 0x1e34040 0x0 0x18>;
|
||||
#fsl,rcpm-wakeup-cells = <6>;
|
||||
little-endian;
|
||||
};
|
||||
|
||||
ftm_alarm0: timer@2800000 {
|
||||
|
@ -892,6 +892,7 @@
|
||||
compatible = "fsl,ls208xa-rcpm", "fsl,qoriq-rcpm-2.1+";
|
||||
reg = <0x0 0x1e34040 0x0 0x18>;
|
||||
#fsl,rcpm-wakeup-cells = <6>;
|
||||
little-endian;
|
||||
};
|
||||
|
||||
ftm_alarm0: timer@2800000 {
|
||||
|
@ -72,6 +72,7 @@
|
||||
pmic@4b {
|
||||
compatible = "rohm,bd71847";
|
||||
reg = <0x4b>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_pmic>;
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
|
||||
@ -210,6 +211,7 @@
|
||||
host-wakeup-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>;
|
||||
device-wakeup-gpios = <&gpio2 7 GPIO_ACTIVE_HIGH>;
|
||||
clocks = <&osc_32k>;
|
||||
max-speed = <4000000>;
|
||||
clock-names = "extclk";
|
||||
};
|
||||
};
|
||||
|
@ -121,6 +121,7 @@
|
||||
pmic@4b {
|
||||
compatible = "rohm,bd71847";
|
||||
reg = <0x4b>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_pmic>;
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
@ -135,13 +135,10 @@
|
||||
pmic@4b {
|
||||
compatible = "rohm,bd71847";
|
||||
reg = <0x4b>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_pmic>;
|
||||
interrupt-parent = <&gpio2>;
|
||||
/*
|
||||
* The interrupt is not correct. It should be level low,
|
||||
* however with internal pull up this causes IRQ storm.
|
||||
*/
|
||||
interrupts = <8 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
|
||||
rohm,reset-snvs-powered;
|
||||
|
||||
#clock-cells = <0>;
|
||||
@ -398,7 +395,7 @@
|
||||
|
||||
pinctrl_pmic: pmicirqgrp {
|
||||
fsl,pins = <
|
||||
MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8 0x41
|
||||
MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8 0x141
|
||||
>;
|
||||
};
|
||||
|
||||
|
@ -129,7 +129,7 @@
|
||||
|
||||
opp-1600000000 {
|
||||
opp-hz = /bits/ 64 <1600000000>;
|
||||
opp-microvolt = <900000>;
|
||||
opp-microvolt = <950000>;
|
||||
opp-supported-hw = <0xc>, <0x7>;
|
||||
clock-latency-ns = <150000>;
|
||||
opp-suspend;
|
||||
|
@ -53,6 +53,7 @@
|
||||
pmic@4b {
|
||||
compatible = "rohm,bd71847";
|
||||
reg = <0x4b>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_pmic>;
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
@ -18,6 +18,7 @@
|
||||
pmic: pmic@25 {
|
||||
compatible = "nxp,pca9450b";
|
||||
reg = <0x25>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_pmic>;
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
@ -116,13 +116,10 @@
|
||||
pmic@4b {
|
||||
compatible = "rohm,bd71847";
|
||||
reg = <0x4b>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_pmic>;
|
||||
interrupt-parent = <&gpio2>;
|
||||
/*
|
||||
* The interrupt is not correct. It should be level low,
|
||||
* however with internal pull up this causes IRQ storm.
|
||||
*/
|
||||
interrupts = <8 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
|
||||
rohm,reset-snvs-powered;
|
||||
|
||||
regulators {
|
||||
@ -388,7 +385,7 @@
|
||||
|
||||
pinctrl_pmic: pmicirqgrp {
|
||||
fsl,pins = <
|
||||
MX8MN_IOMUXC_SD1_DATA6_GPIO2_IO8 0x101
|
||||
MX8MN_IOMUXC_SD1_DATA6_GPIO2_IO8 0x141
|
||||
>;
|
||||
};
|
||||
|
||||
|
@ -790,28 +790,6 @@
|
||||
#index-cells = <1>;
|
||||
reg = <0x32e40200 0x200>;
|
||||
};
|
||||
|
||||
usbotg2: usb@32e50000 {
|
||||
compatible = "fsl,imx8mn-usb", "fsl,imx7d-usb";
|
||||
reg = <0x32e50000 0x200>;
|
||||
interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&clk IMX8MN_CLK_USB1_CTRL_ROOT>;
|
||||
clock-names = "usb1_ctrl_root_clk";
|
||||
assigned-clocks = <&clk IMX8MN_CLK_USB_BUS>,
|
||||
<&clk IMX8MN_CLK_USB_CORE_REF>;
|
||||
assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_500M>,
|
||||
<&clk IMX8MN_SYS_PLL1_100M>;
|
||||
fsl,usbphy = <&usbphynop2>;
|
||||
fsl,usbmisc = <&usbmisc2 0>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
usbmisc2: usbmisc@32e50200 {
|
||||
compatible = "fsl,imx8mn-usbmisc", "fsl,imx7d-usbmisc";
|
||||
#index-cells = <1>;
|
||||
reg = <0x32e50200 0x200>;
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
dma_apbh: dma-controller@33000000 {
|
||||
@ -876,12 +854,4 @@
|
||||
assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_100M>;
|
||||
clock-names = "main_clk";
|
||||
};
|
||||
|
||||
usbphynop2: usbphynop2 {
|
||||
compatible = "usb-nop-xceiv";
|
||||
clocks = <&clk IMX8MN_CLK_USB_PHY_REF>;
|
||||
assigned-clocks = <&clk IMX8MN_CLK_USB_PHY_REF>;
|
||||
assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_100M>;
|
||||
clock-names = "main_clk";
|
||||
};
|
||||
};
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user