tmakin/ack-tegra
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

base: tmakin:6298de0220900e9b6e3caac75b144f1b8f4fa9bc
Branches Tags
tmakin:testing-6.12 tmakin:testing-6/12 tmakin:6.12-non-gki
..
compare: tmakin:6.12-non-gki
Branches Tags
tmakin:testing-6.12 tmakin:testing-6/12 tmakin:6.12-non-gki

160 Commits
6298de0220 ... 6.12-non-g

Author SHA1 Message Date
Thomas Makin
1529c65700 xusb: bulk commit to split 2025-11-11 15:25:56 +00:00
Thomas Makin
d33417366f defconfig: updates 2025-11-11 15:24:14 +00:00
Thomas Makin
a1929690c5 dts: misc updates 2025-11-11 15:24:14 +00:00
Thomas Makin
50119fb291 phy: xusb-tegra210: use same supplies for b01 2025-11-11 15:24:14 +00:00
Thomas Makin
f615fff570 memory: tegra: populate dt subnodes 
Tegra210b01 uses tegra186-emc driver as emc clock is controlled by BPMP.
However, this driver expects emc as subnode of mc. Adjust Tegra30 mc
probe routine to populate subnodes.
 2025-11-11 15:24:13 +00:00
Thomas Makin
36202b6dc2 clk: tegra210b01: add plle 2025-11-11 15:15:10 +00:00
Rohith Seelaboyina
6c5e31fc75 phy: tegra: xusb: Add T210B01 support 
- Add T210b01 soc data for xusb_padctl driver
- Add uphy_management clock support
- Add PLL defaults programming

Bug 200340262

Change-Id: Ie5a685a49542221142a0a8e31e5a9ebb729a3035
Signed-off-by: Rohith Seelaboyina <rseelaboyina@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1584421
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Rakesh Babu Bodla <rbodla@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
 2025-11-11 15:15:10 +00:00
Thomas Makin
b33310ac0b pci: tegra: fix link_up invocation 2025-11-11 15:15:10 +00:00
Vidya Sagar
d1351e804e PCI: tegra: add PCI_REASSIGN_ALL_BUS flag 
adds PCI_REASSIGN_ALL_BUS pci flag so as to enable
re-assigning bus numbers (if there is any bridge device added
recently) during rescan.

Bug 200192107

Change-Id: Iffc02827a75dcb82f5e02b69e96e65b38a0b7cd6
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-on: http://git-master/r/1144609
(cherry picked from commit 26464cda2eff345548e3271f26b00ddcd79d9264)
Reviewed-on: http://git-master/r/1176833
(cherry picked from commit bf21f6959bbecc70b4dce07329e0deea32b41b67)
Reviewed-on: http://git-master/r/1141937
(cherry picked from commit 284d2e97ce311771808d8dbd75c861a95c16d031)
Reviewed-on: http://git-master/r/1210983
(cherry picked from commit ef83e7563eb0ce4dad493abba2c92d20a67f41ac)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-4.14/+/2371135
(cherry picked from commit a43acb68398f7fd6208988684698b49962b3c6f9)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407883
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:10 +00:00
Manikanta Maddireddy
3ac7bfa0f3 PCI: tegra: Add DT support to disable CLKREQ# control on PLLE 
Sometimes CLKREQ# pin connection might be missing on a platform. Add DT
support to disable CLKREQ# control on PLLE in driver. Platform device tree
can use this DT property to disable CLKREQ# control on PLLE. In kernel-5.9,
upstream device tree property "supports-clkreq" is used in place of
kernel-4.14 custom device tree property "nvidia,disable-clock-request".

bug 200420606

Change-Id: I6ac44bd99d090e158fa10e5e9b62d63e52563c8c
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786551
(cherry picked from commit 6870a94b48a4bbbe9df607802c7f7c1f61806b7b)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407880
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:10 +00:00
Manikanta Maddireddy
f6a8256ac3 PCI: tegra: aspm DT support 
Squashed below k414 commits into single change.

PCI: tegra: Add DT support to disable per state aspm

Kernel config option provides choice to disable L0s & L1 or L1 substates
combinedly. Add DT support to disable each aspm state individually.

bug 200420606

Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786548
(cherry picked from commit f3c5bcdc3ab8cadd3d24ea4d1a8e0aba7beea751)

PCI: tegra: Fix ASPM DT property parsing code

DT property "nvidia,disable-aspm-states" is part of PCIe port node.
Use correct of_node pointer to parse this property.

bug 200434876

Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-4.14/+/2383766
(cherry picked from commit 8dd957e9ecf29da4ba94471e3d74b2aef98a0643)

Change-Id: Iee1f573a103c0045d4f8f6606db13b47575b8cb9
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2408709
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: Bitan Biswas <bbiswas@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
 2025-11-11 15:15:10 +00:00
Manikanta Maddireddy
3a39898f0d PCI: tegra: Bypass CLKREQ# control over PLLE 
When PCIe link is L2 CLKREQ# will be floating and this might interfere
with PLL power down. Bypass CLKREQ# control over PLLE when link is in L2.

bug 1356695
bug 200420606

Change-Id: I361db03df5f9a1a8d38bd9fb816d17fc4c64a9fc
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786565
(cherry picked from commit 69e79f42f65df70b0c76e62200aca40ed3972e3b)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407877
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:10 +00:00
Manikanta Maddireddy
e3a136b7a7 PCI: tegra: Fix incorrect CLKREQ and PLLE programming 
CLKREQ_EN bit should be cleared to control REFCLK through CLKREQ# pin.
Enable PCIE2PLLE bit to control PLLE through clock clamp signal.
Program PADS2PLLE and PCIE2PLLE bits only if Tegra PCIe supports L1SS.

bug 200420606

Change-Id: I04cacf64fce8eed0f17bb632457ffcc9f052819d
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786550
(cherry picked from commit e71a64e47225b848c9b8a1d33e8c80a7bdb9d3cc)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407876
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:10 +00:00
Vidya Sagar
00f1cf7c84 PCI: tegra: Fixups to avoid unnecessary wakeup from ASPM-L1.2 
sets CLKREQ asserted delay to a higher value to avoid
unnecessary wake up from L1.2.ENTRY state for Tegra210

bug 200420606

Change-Id: Iec2564bfd434897f0e50cd3f0ad6bc76aacc12e8
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786545
(cherry picked from commit d7785c1e6c98e33a85ba9487d3be6ab7e518a285)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407875
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:10 +00:00
Vidya Sagar
b011642f03 PCI: tegra: Apply sw fixups to support ASPM-L1 Sub-States 
Programs Port Common_Mode_Restore_Time and Port T_POWER_ON values
(from the L1 PM Substates Capabilities Register, PCIe 4.0r0.9, sec 7.8.3.2)
to get them reflected in ASPM-L1 Sub-States capability registers.
Also adjusts internal counter values according to 19.2 MHz clk_m value.

bug 200420606

Change-Id: Ie139255e522e4476fdfbe64aa6250d0293b7ae89
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786544
(cherry picked from commit 9ac6211e1a99583618945c86748214ccc33de463)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407874
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:10 +00:00
Manikanta Maddireddy
2b7a4256cc PCI: tegra: Configure L1 power save parameters 
Programmed bits of register RP_VEND_XP_PAD_PWRDN are defined as follows,

L1(bit[0]):
 This bit, when set, causes the analog pads to power down when we're in L1.
 When clear, the LTSSM still enters L1 as required, but the analog pads
 are left at full power.
DYNAMIC(bit[1]):
 This bit, when set, causes unused analog pads to power down after
 "Dynamic Link Width Re-negotiation" takes place.  When clear, all analog
 pads remain powered up, even those that are no longer being used after
 "Dynamic Link Width Re-negotiation" down-sizes the link.
DISABLED(bit[2]):
 This bit, when set, causes the analog pads to power down when we're in the
 DISABLED_DOWN state. When clear, the LTSSM still enters DISBLED_DOWN as
 required, but the analog pads are left at full power.
L1_CLKREQ(bit[15]):
 This bit, when set, causes the analog pads to power down to
 SLEEP_MODE_L1_REQ when clkreq signal is deasserted in L1.
 (NV_PROJ__PCIE2_RP_VEND_XP_PAD_PWRDN_L1 needs to be set in order to power
 down pad in L1.)  Also, when clkreq is asserted in L1, ltssm will exit L1
 immediately. When clear, the clkreq signal doesn't affect the power
 management.
SLEEP_MODE_L1(bits[4:3]):
 It defines the 2-bit sleep-mode coding in the pad when LTSSM is in the L1
 state or DISABLED state.
SLEEP_MODE_DYNAMIC(bits[6:5]):
 It defines the 2-bit sleep-mode coding in the pad when the lane shut down
 due to dynamic link downsizing.
SLEEP_MODE_L1_CLKREQ(bits[17:16]):
 It defines the 2-bit sleep-mode coding when clkreq is deasserted in L1.
The 2-bit sleep-mode encoding is defined as:
 - L0 (0x0): Normal power-up mode
 - L1 (0x1): L1 power-down mode; Tx common mode on, Rx e-idle detect on
 - L1P (0x2): L1 power-down mode; Tx common mode off, Rx e-idle detect on
 - L1PP (0x3): L1 power-down mode; Tx common mode off, Rx e-idle detect off

bug 200420606

Change-Id: I74aa9c1460d882084b1ecccb9c0168dd667c9d84
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786547
(cherry picked from commit d7899c186f89ecf503812003b743adbae07c4cbe)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407873
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:10 +00:00
Vidya Sagar
dd0f08b513 PCI: tegra: Advertise ASPM L1 PM support 
Enables advertisement of ASPM-L1 support in capability
registers of applicable Tegra chips

bug 200420606

Change-Id: Ie5dbb3a262ca1c0c9cc59c91a8710bf6bd6a6900
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786543
(cherry picked from commit 7eedf2a02489b529374bc1ca95234be1f02b9119)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407872
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:09 +00:00
Manikanta Maddireddy
8e42e98420 PCI: tegra: Convert WRAP transactions to increment burst 
AFI module doesn't support WRAP transactions in Tegra. WRAP instructions
from CPU targeting PCIe BAR memory can cause data corruption. This can
happen if PCIe memory is marked as normal cacheable or GRE device.
Program mselect register to convert WRAP transactions to increment burst
for slave PCIe.

bug 200353330
bug 200420606

Change-Id: I867da85eb63332708bc294238e30ad99a71f345d
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786561
(cherry picked from commit b345cfae7b7633a3a52e0f2a659baf44feee1466)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407869
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:09 +00:00
Manikanta Maddireddy
44c081db2a PCI: tegra: Access endpoint config only if PCIe link is up 
Few endpoints like Wi-Fi supports power on/off and to leverage that
root port must support hot-plug and hot-unplug. Tegra PCIe doesn't
support hot-plug and hot-unplug, however it supports endpoint power
on/off feature as follows,
 - Power off sequence:
   - Transition of PCIe link to L2
   - Power off endpoint
   - Leave root port in power up state with the link in L2
 - Power on sequence:
   - Power on endpoint
   - Apply hot reset to get PCIe link up

PCIe client driver stops accessing PCIe endpoint config and BAR registers
after endpoint is powered off. However, software applications like x11
server or lspci can access endpoint config registers in which case
host controller raises "response decoding" errors. To avoid this scenario,
add PCIe link up check in config read and write callback functions before
accessing endpoint config registers.

Change-Id: I47653cb0b580c2b764cb0ad9c42deeb9c8823c58
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-4.14/+/2371131
(cherry picked from commit be664bfdd901138222a8ea8bb17160a2fa9de04a)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407866
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:09 +00:00
Manikanta Maddireddy
3db69fdfe2 PCI: tegra: Add PCIe support for tegra210b01 chip 
bug 200420606

Change-Id: I943e4ad90915332fbecc3ed9cb368d3f549925a6
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1786562
(cherry picked from commit ef7328abda206df3b00364eeaeecc20103896326)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-5.9/+/2407885
Reviewed-by: automaticguardword <automaticguardword@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
 2025-11-11 15:15:09 +00:00
Thomas Makin
a248214f65 t210b01: sdmmc pinmuxing 2025-11-11 15:15:09 +00:00
Thomas Makin
6c26ccf6d2 tegra210b01: use bpmp for emc 
Make use of the existing tegra186-emc driver to handle emc
clocking and scaling via BPMP API instead of in kernel.

Downstream uses tables from emc and overrides the clock.
 2025-11-11 15:15:09 +00:00
Thomas Makin
94681aeae8 [WAR] core: don't loop 2025-11-11 15:15:09 +00:00
Thomas Makin
6f1f1abf26 [DEBUG] emc logging 2025-11-11 15:15:09 +00:00
Thomas Makin
6d44dc2607 typec: introduce bm92txx driver 
TODO: fix commit
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:09 +00:00
Thomas Makin
b6b5a56f88 memory: tegra186-emc: support t210b01 
Tegra210b01 uses Tegra186 style emc management, as in it is
offloaded to BPMP. This driver already implements this, so no
reason to shoehorn in elsewhere.

Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:09 +00:00
Thomas Makin
c6ca332037 nouveau: add tegra210b01 support 
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:09 +00:00
Thomas Makin
963c5f5011 tegra210b01: do not enable venc 
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:09 +00:00
Thomas Makin
0c1e29cf14 tegra-drm: add t210b01 dsi support 
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Thomas Makin
0bb8fa8047 enable max77812 
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
azkali
b9ed6706e1 panel: dsi-nx: Add dsi-nx panel driver 
dsi-nx is a new blanket driver for panels on the Nintendo Switch.
The Switch boots Linux via the "hekate" custom bootloader, which
performs panel initialization and passes panel info to kernel.

This driver is based on panel-jdi-lpm062m326a by SwitchR.

Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Thomas Makin
f005bd8b44 t210: add core dvfs floor/cap 
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Thomas Makin
c818120483 tegra: dfll: forward-port 4.9 dfll 
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Laxman Dewangan
77f7f06729 regulator: core: add API to get min/max voltage for rails 
Add API to get min/max rail voltage configured from platform for
given rails. This will help to set the pad voltage based on platform
specific power tree.

bug 200083043

Change-Id: I054734ca2a25b5c830525e27ab22e43534f67351
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-on: http://git-master/r/712001
(cherry picked from commit c0d1de0da091132d037e1bb32f2ee09b5c00369b)
Reviewed-on: http://git-master/r/1119836
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Alex Frid
4ba2917a97 clk: Add parent change notifications 
Added parent change notifications to be used when drivers behavior
depends on physical nature of the parent, not just clock rate it
supplies (e.g., selection of Tegra DFLL as CPU clock source changes
mechanism of voltage control even if the clock rate stays the same
as on PLL).

Bug 200269751

Change-Id: I617c94927ef437caf240efd91497b49ad6f5c39d
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1573111
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: Peter De Schrijver <pdeschrijver@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Timo Alho <talho@nvidia.com>
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Alex Frid
13c3818949 clk: tegra: Add subtree change notifications 
Added PRE_SUBTREE_CHANGE and POST_SUBTREE_CHANGE that called before
and after rate change is propagated down the sub-tree rooted in clk.
This would allow children to be aware that next set rate operation
is triggered by downward rate propagation, rather than direct set rate
on a child clock.

Bug 200267979

Change-Id: I6f2acbeca7cead0ecd385dcb2e58ced32448e998
Signed-off-by: Alex Frid <afrid@nvidia.com>
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
(cherry picked from commit 62f0d763fcb6c9d5bd9a373d22d802503ab0fdc5)
Reviewed-on: https://git-master.nvidia.com/r/1558143
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Timo Alho <talho@nvidia.com>
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Thomas Makin
eeb92feb05 tegra: dfll: use tune1_low 
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Jon Hunter
9448b31662 soc/tegra: update sppedo and chip rev handling 
- Make revisions consistent
- Enable T210B01 support
- Update speedo structs

soc/tegra: fuse: Add support for retrieving IDDQ information

Add helpers functions for retrieving IDDQ information which is used
by SYSEDP.

Bug 1811732

Change-Id: I889afecebc9b6d7c2085a528f5dfb58a095165ff
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: http://git-master/r/1255677

Conflicts:
	include/linux/tegra-fuse.h

soc: tegra: Don't confuse chip / speedo revisions

During T210 DVFS initialization SoC chip revision was incorrectly used
instead of speedo fuse revision to limit core maximum voltage. Fixed it
in this commit.

Bug 200269751
Bug 200277489

Change-Id: Ifadabb1840039f407d2abfd8b9a8782b865b5a13
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: http://git-master/r/1302687
Reviewed-on: https://git-master.nvidia.com/r/1563340
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Tested-by: Sachin Nikam <snikam@nvidia.com>

soc: tegra: Fix for Automotive speedo/process ids

This fixes to derive correct speedo/process ids for
automotive skus(0x17 and 0x23).

Also display the sku info in hexadecimal format.

Bug 200258423

Change-Id: Ifab5f957983494fcffeb253f7fdda6b6062c56c5
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1576315
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Timo Alho <talho@nvidia.com>

soc: fuse: Introduce T210b01 speedo IDs

Introduce T210b01 speedo ID initialization by implementing:

- Parse T210b01 speedo fuses programming revision from spare fuses
- T210b01 binning thresholds
- Detection of T210b01 SKUs

Bug 1906940

Change-Id: If7d168434c12b5e92250be608f9736fc80cc2886
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1576317
Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Tested-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Sachin Nikam <snikam@nvidia.com>

soc/tegra: fuse: update speedo IDs for Tegra210

Bug 200255986

[ There's a merge conflict during the cherry-pick from Kernel 4.4
  to 4.9 becauase a later patch got merged first -- Nicolin ]

Change-Id: Iacf188f4cccea03d3a82f7ad18455c18681c506d
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: http://git-master/r/1262213
Reviewed-by: Shreshtha Sahu <ssahu@nvidia.com>
Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
GVS: Gerrit_Virtual_Submit
(cherry picked from commit 98a6b47e55b1e5754490420c1ca379793e3569d2)
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1578888
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>

soc: tegra: Update T210 sku info

- Populated sku info ucm field, and selected DVFS ids appropriately
- Made "a02" DVFS ids selection forward looking
  (applied to all A02+ revisions)
- Applied vcm31_sku to a02 parts (was a01 only), but limit it to
  0x17 sku fuses (was applied to 0x07 and 0x13 as well)
- Made always on personality a must for sku 0x8F

Bug 200269751

Change-Id: I85cbe2f1621c271640643aa2d203b9dac5b8c992
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: http://git-master/r/1307422
Reviewed-by: svccoveritychecker <svccoveritychecker@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Jon Mayo <jmayo@nvidia.com>
(cherry picked from commit 9ffc1f1cc2cb588f440640921f77223a6baee280)
Reviewed-on: https://git-master.nvidia.com/r/1578889
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Timo Alho <talho@nvidia.com>

soc: tegra: Add support for T210 sku 0x1F

Bug 2059069

Change-Id: I7d20b6f1b889a18f23ae2fe6662d7b08e950154e
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1669017
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bo Yan <byan@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>

clk: soc: tegra: Add support for T210b01 sku 0x87

Bug 2075533

Change-Id: I07433bd7139a5c845065a9a1d46f5f6e9559fbb5
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1669169
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bo Yan <byan@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>

soc: tegra: Add usage mode UCM field to sku info

Bug 200269751
Bug 200277498
Bug 200340064

Change-Id: I8044b350587e2298ec1b705dd01fec5fc6d83379
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: http://git-master/r/1307421
Signed-off-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1563330
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit

soc/tegra: add support for getting b01 rev

soc/tegra: adjust revision handling for t210 skus

Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Alex Frid
b8a786039a clk: soc: tegra: Rename DFLL tune1 to tune1_low 
Renamed DFLL tune1 to tune1_low to be consistent with
tune0_low/tune0_high naming convention.

Bug 1967884

Change-Id: If23170305143b05c2918e04691c73fe13b777272
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1576306
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:08 +00:00
Thomas Makin
7530eba983 arm64: t210b01: enable max77812 
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:07 +00:00
Thomas Makin
19be22ef9a arm64: t210b01: add max77620 support 
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:07 +00:00
Thomas Makin
0ac6a10eaa arm64: t210: add initial support for nx 
The Nintendo Switch is a video game console based on the
Tegra X1 (T210) and X1+ (T210B01).

Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:07 +00:00
Aaron Kling
40380c8c38 clk: tegra: dfll: add CVB tables for Tegra210B01 
To generate OPP tables for the soc

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:07 +00:00
Aaron Kling
31ecc0af39 drm/tegra: Create switch class for primary hdmi 
Change-Id: I353b1c5ad98bcd69b4827b0c74327511b4d8222d
 2025-11-11 15:15:07 +00:00
Faith Ekstrand
9f565ad57c nouveau: Use WC maps instead of uncached 2025-11-11 15:15:07 +00:00
kuyo chang
eb74f85a1f sched/deadline: Fix RT task potential starvation when expiry time passed 
[Symptom]
The fair server mechanism, which is intended to prevent fair starvation
when higher-priority tasks monopolize the CPU.
Specifically, RT tasks on the runqueue may not be scheduled as expected.

[Analysis]
---------
The log "sched: DL replenish lagged too much" triggered.

By memory dump of dl_server:
--------------
    curr = 0xFFFFFF80D6A0AC00 (
      dl_server = 0xFFFFFF83CD5B1470(
        dl_runtime = 0x02FAF080,
        dl_deadline = 0x3B9ACA00,
        dl_period = 0x3B9ACA00,
        dl_bw = 0xCCCC,
        dl_density = 0xCCCC,
        runtime = 0x02FAF080,
        deadline = 0x0000082031EB0E80,
        flags = 0x0,
        dl_throttled = 0x0,
        dl_yielded = 0x0,
        dl_non_contending = 0x0,
        dl_overrun = 0x0,
        dl_server = 0x1,
        dl_server_active = 0x1,
        dl_defer = 0x1,
        dl_defer_armed = 0x0,
        dl_defer_running = 0x1,
        dl_timer = (
          node = (
            expires = 0x000008199756E700),
          _softexpires = 0x000008199756E700,
          function = 0xFFFFFFDB9AF44D30 = dl_task_timer,
          base = 0xFFFFFF83CD5A12C0,
          state = 0x0,
          is_rel = 0x0,
          is_soft = 0x0,
    clock_update_flags = 0x4,
    clock = 0x000008204A496900,

- The timer expiration time (rq->curr->dl_server->dl_timer->expires)
  is already in the past, indicating the timer has expired.
- The timer state (rq->curr->dl_server->dl_timer->state) is 0.

[Suspected Root Cause]
--------------------
The relevant code flow in the throttle path of
update_curr_dl_se() as follows:

dequeue_dl_entity(dl_se, 0);                // the DL entity is dequeued

if (unlikely(is_dl_boosted(dl_se) || !start_dl_timer(dl_se))) {
    if (dl_server(dl_se))                   // timer registration fails
        enqueue_dl_entity(dl_se, ENQUEUE_REPLENISH);//enqueue immediately
    ...
}

The failure of `start_dl_timer` is caused by attempting to register a
timer with an expiration time that is already in the past. When this
situation persists, the code repeatedly re-enqueues the DL entity
without properly replenishing or restarting the timer, resulting in RT
task may not be scheduled as expected.

[Proposed Solution]:
------------------
Instead of immediately re-enqueuing the DL entity on timer registration
failure, this change ensures the DL entity is properly replenished and
the timer is restarted, preventing RT potential starvation.

Signed-off-by: kuyo chang <kuyo.chang@mediatek.com>
Closes: https://lore.kernel.org/CAMuHMdXn4z1pioTtBGMfQM0jsLviqS2jwysaWXpoLxWYoGa82w@mail.gmail.com
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
 2025-11-11 15:15:07 +00:00
Aaron Kling
8cf759f651 HACK: HID: usbhid: schedule a hid_reset() for -75 irq_in 
Copied from nvidia's downstream 3.10 kernel

Change-Id: Ifd017363927d249637444d1874aa0f680a48acc4
 2025-11-11 15:15:07 +00:00
Dmitry Osipenko
b39c839c7f partitions: Support NVIDIA Tegra Partition Table 
All NVIDIA Tegra devices use a special partition table format for the
internal storage partitioning.  Most of Tegra devices have GPT partition
in addition to TegraPT, but some older Android consumer-grade devices do
not or GPT is placed in a wrong sector, and thus, the TegraPT is needed
in order to support these devices properly by the upstream kernel. This
patch adds support for NVIDIA Tegra Partition Table format that is used
at least by all NVIDIA Tegra20 and Tegra30 devices.

Tested-by: Nils Östlund <nils@naltan.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
 2025-11-11 15:15:07 +00:00
Dmitry Osipenko
fa5772ad55 mmc: Support non-standard gpt_sector cmdline parameter 
Add support for the gpt_sector cmdline parameter which will be used
for looking up GPT entry on internal eMMC storage of NVIDIA Tegra20+
devices. This parameter is used by a stock downstream bootloader of
Android devices.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
 2025-11-11 15:15:07 +00:00
Aaron Kling
abeb79e303 ARM: tegra: Use io memcpy to write to iram 
Kasan crashes the kernel trying to check boundaries when using the
normal memcpy.

Change-Id: I093741be1ff73e3d5cefc41eeab719bb67b4c3d0
 2025-11-11 15:15:07 +00:00
Vishwaroop A
234fadb4f4 drivers: spi: add support for prod framework 
Add support for prod framework in spi core

Change-Id: Iaa70f8b3bb3efb3a3b13aa7f2d43562b9fff9e51
Signed-off-by: Vishwaroop A <va@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Abhilash G <abhilashg@nvidia.com>
 2025-11-11 15:15:07 +00:00
Shardar Shariff Md
201b0a8131 i2c: core: skip prod-settings node during i2c device registration 
skip prod-settings node during i2c device registration as
prod-settings is not i2c device

Change-Id: Iaeff454cf17ffd68a7273aeb8afcce6e2c8894c6
Signed-off-by: Shardar Shariff Md <smohammed@nvidia.com>
Signed-off-by: Bitan Biswas <bbiswas@nvidia.com>
Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com>
Reviewed-by: Akhil R <akhilrajeev@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Tested-by: Akhil R <akhilrajeev@nvidia.com>
Signed-off-by: Abhilash G <abhilashg@nvidia.com>
 2025-11-11 15:15:06 +00:00
Aaron Kling
06ba67e49f Revert "fbdev: Make registered_fb[] private to fbmem.c" 
This reverts commit 5727dcfd84.

Change-Id: I724a29c438f62d504a386795e59685e5b6c1c3a1
 2025-11-11 15:15:06 +00:00
David Ng
d842dcc46b arm64: Add 32-bit sigcontext definition to uapi signcontext.h 
The arm64 uapi sigcontext.h can be included by 32-bit userspace
modules.  Since arm and arm64 sigcontext definition are not
compatible, add arm sigcontext definition to arm64 sigcontext.h.

Signed-off-by: David Ng <dave@codeaurora.org>
Signed-off-by: Divya Sharma <c_shard@codeaurora.org>
Signed-off-by: Anh Nguyen <anguyen@codeaurora.org>
Change-Id: Iaed58045fd345e4ca66e8a6981c6b4f80c4bdfca
 2025-11-11 15:15:06 +00:00
Aaron Kling
39ed1555a2 arm64: Disable some cpu feature sanity checks 
On t186, these differ between denver and a57

Change-Id: I65b1515ef9f5d42b0da1dfa605e51536eb902ca5
 2025-11-11 15:15:06 +00:00
Aaron Kling
97f611dcd2 arm64: tegra: Enable mmu on Tegra194 display controllers 
These use a separate mmu instance compared to everything else currently
enabled for the soc.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:06 +00:00
Aaron Kling
361e8f46a4 Revert "arm64: tegra: Disable ISO SMMU for Tegra194" 
This reverts commit ebea268ea5.

Mmu is now being enabled for the display controllers.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:06 +00:00
Aaron Kling
8c79250f5e drm/tegra: Enable cmu for Tegra186 and Tegra194 
Without the cmu, nvdisplay will display colors that are notably darker
than intended. The vendor bootloader and the downstream display driver
enable the cmu and sets a sRGB table. Loading that table here results in
the intended colors.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:06 +00:00
Svyatoslav Ryhel
eb6a966d67 ARM: tegra: add device-tree for Xiaomi Mi Pad (A0101) 
The Mi Pad is a tablet computer based on Nvidia Tegra K1 SoC which
originally ran the Android operating system. The Mi Pad has a 7.9" IPS
display with 1536 x 2048 (324 ppi) resolution. 2 GB of RAM and 16/64 GB of
internal memory that can be supplemented with a microSDXC card giving up
to 128 GB of additional storage.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
 2025-11-11 15:15:06 +00:00
Svyatoslav Ryhel
afe22b10e3 drm/panel: Add Sharp LQ079L1SX01 support 
This panel requires dual-channel mode. The device accepts video-mode data
on 8 lanes and will therefore need a dual-channel DSI controller. The two
interfaces that make up this device need to be instantiated in the
controllers that gang up to provide the dual-channel DSI host.

Change-Id: I5ca26fe0cdcdf40620b8a9e7801962c66b0be2b5
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
 2025-11-11 15:15:06 +00:00
Aaron Kling
bc31a9092d arm64: tegra: Add CPU OPP tables for Tegra194 
Add OPP table and interconnects property to scale DDR frequency with
CPU frequency for better performance. Each operating point entry of
the OPP table has CPU freq to per MC channel bandwidth mapping.
One table is added for each cluster even though the table data is
same because the bandwidth request is per cluster. This is done
because OPP framework creates a single icc path and hence single
bandwidth request if the table is marked as 'opp-shared' and shared
among all clusters. For us, the OPP table data is same but the MC
Client ID argument to interconnects property is different for each
cluster. So, having per cluster table makes different icc path for
each cluster and helps to make per cluster BW requests.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:06 +00:00
Aaron Kling
99260f415c arm64: tegra: Add CPU OPP tables for Tegra186 
Add OPP table and interconnects property to scale DDR frequency with
CPU frequency for better performance. Each operating point entry of
the OPP table has CPU freq to per MC channel bandwidth mapping. One
table is added for each cluster because the different cpu types have
different scaling curves.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:06 +00:00
Aaron Kling
2825a74d67 memory: tegra194: Support icc scaling 
Add Interconnect framework support to dynamically set the DRAM
bandwidth from different clients. The MC driver is added as an ICC
provider and the EMC is already a provider.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:06 +00:00
Aaron Kling
da694360e3 memory: tegra186: Support icc scaling 
Add Interconnect framework support to dynamically set the DRAM
bandwidth from different clients. The MC driver is added as an ICC
provider and the EMC is already a provider.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:06 +00:00
Aaron Kling
1141b0ace0 memory: tegra186-emc: Support non-bpmp icc scaling 
This adds support for dynamic frequency scaling of external memory on
devices with bpmp firmware that does not support bwmgr.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
b6c886e75e cpufreq: tegra186: add OPP support and set bandwidth 
Add support to use OPP table from DT in Tegra186 cpufreq driver.
Tegra SoC's receive the frequency lookup table (LUT) from BPMP-FW.
Cross check the OPP's present in DT against the LUT from BPMP-FW
and enable only those DT OPP's which are present in LUT also.

The OPP table in DT has CPU Frequency to bandwidth mapping where
the bandwidth value is per MC channel. DRAM bandwidth depends on the
number of MC channels which can vary as per the boot configuration.
This per channel bandwidth from OPP table will be later converted by
MC driver to final bandwidth value by multiplying with number of
channels before being handled in the EMC driver.

If OPP table is not present in DT, then use the LUT from BPMP-FW
directy as the CPU frequency table and not do the DRAM frequency
scaling which is same as the current behavior.

Change-Id: I11a37b2bd7d6b7a7ee9d270ecd0430430a407d65
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
8b4602a837 dt-bindings: tegra: Add ICC IDs for dummy memory clients for Tegra194 
Add ICC IDs for dummy software clients representing CCPLEX clusters.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
13da52bbd1 dt-bindings: tegra: Add ICC IDs for dummy memory clients for Tegra186 
Add ICC IDs for dummy software clients representing CCPLEX clusters.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
25d30a45af arm64: tegra: Add OPP tables on Tegra210 
This adds OPP tables for actmon and emc, enabling dynamic frequency
scaling for ram.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
9401bac24d arm64: tegra: Add interconnect properties to Tegra210 device-tree 
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
8daf4ee46f arm64: tegra: tegra210: Add actmon 
This enables the action monitor to facilitate dynamic frequency scaling.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
343e60550d soc: tegra: fuse: speedo-tegra210: Add soc speedo 2 
The Jetson Nano series of modules only have 2 emc table entries,
different from other soc sku's. As the emc driver uses the soc speedo to
populate the emc opp tables, add a new speedo id to uniquely identify
this.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
091bffaf7e memory: tegra210: Support interconnect framework 
This makes mc and emc interconnect providers and allows for dynamic
memory clock scaling.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
50699fa40a memory: tegra210: Use bindings for client ids 
Since the related binding is being added, use that for the client ids
instead of hardcoded magic numbers.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
e95129a161 dt-bindings: memory: tegra210: Add memory client IDs 
Each memory client has unique hardware ID, add these IDs.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
b75fae54c9 soc: tegra: fuse: speedo-tegra210: Update speedo ids 
Existing code only sets cpu and gpu speedo ids 0 and 1. The cpu dvfs
code supports 11 ids and nouveau supports 5. This aligns with what the
downstream vendor kernel supports. Align skus with the downstream list.

The Tegra210 CVB tables were added in the first referenced fixes commit.
Since then, all Tegra210 socs have tried to scale to 1.9 GHz, when the
supported devkits are only supposed to scale to 1.5 or 1.7 GHZ.
Overclocking should not be the default state.

Fixes: 2b2dbc2f94 ("clk: tegra: dfll: add CVB tables for Tegra210")
Fixes: 579db6e5d9 ("arm64: tegra: Enable DFLL support on Jetson Nano")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
16e7bf68b1 drm/nouveau: Support devfreq for Tegra 
Using pmu counters for usage stats. This enables dynamic frequency
scaling on all of the currently supported Tegra gpus.

The register offsets are valid for gk20a, gm20b, gp10b, and gv11b. If
support is added for ga10b, this will need rearchitected.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Aaron Kling
06ba4c8e65 drm/nouveau: Support reclocking on gp10b 
Starting with Tegra186, gpu clock handling is done by the bpmp and there
is little to be done by the kernel. The only thing necessary for
reclocking is to set the gpcclk to the desired rate and the bpmp handles
the rest. The pstate list is based on the downstream driver generates.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:05 +00:00
Ard Biesheuvel
21164c1535 efistub: Lower default log level 
Change-Id: I4d4f6e5a93669ca2a99a79f5f760ced2f000a3c2
 2025-11-11 15:15:04 +00:00
Aaron Kling
cc70760341 WIP: drm/tegra: Add devfreq support to media engines 
TODO: Better limit frequency count

Change-Id: If86527dc4985d9afd9d510430d1f3c137ca7f220
 2025-11-11 15:15:04 +00:00
Aaron Kling
1ef6885568 drm/tegra: Support Tegra186+ in NVJPG 
Change-Id: I7bf2c200d4ad9690c4f21a004ecc6dea8065f93e
 2025-11-11 15:15:04 +00:00
Aaron Kling
b66348d05a drm/tegra: Add NVENC driver 
Add support for booting and using NVENC on Tegra210+ to the Host1x
and TegraDRM drivers. This driver only supports the new TegraDRM uAPI.

Change-Id: I07e1386604d7638ba43381c3f289688d7c5cb12b
 2025-11-11 15:15:04 +00:00
Aaron Kling
77a33fa2f7 arm64: tegra: Enable NVDEC and NVENC on Tegra210 
The other engines are already enabled, finish filling out the media
engine nodes and power domains.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:04 +00:00
Diogo Ivo
5de5a7b521 arm64: tegra: Add NVJPG node for Tegra210 platforms 
The Tegra X1 chip contains a NVJPG accelerator capable of
encoding/decoding JPEG files in hardware. Complete its DT node
and enable it.

Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
 2025-11-11 15:15:04 +00:00
Diogo Ivo
bd9ce31a9a arm64: tegra: Add Tegra210 NVJPG power-domain node 
Add the NVJPG power-domain node in order to support the NVJPG
accelerator in Tegra210 platforms.

Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
 2025-11-11 15:15:04 +00:00
Diogo Ivo
17c9b0eac7 drm/tegra: Add NVJPG driver 
Add support for booting and using NVJPG on Tegra210 to the Host1x
and TegraDRM drivers. This driver only supports the new TegraDRM uAPI.

Acked-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
 2025-11-11 15:15:04 +00:00
Mikko Perttunen
796fc53eb5 gpu: host1x: Add MLOCK recovery for rest of engines 
Add class IDs / MLOCKs for MLOCK recovery for rest of engines
present on Tegra234.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240425050238.2943404-4-cyndis@kapsi.fi
 2025-11-11 15:15:04 +00:00
Mikko Perttunen
9490ce4c50 gpu: host1x: Complete stream ID entry tables 
These tables contain fixed values to program the host1x hardware
with, so fill in the missing entries.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240425050238.2943404-3-cyndis@kapsi.fi
 2025-11-11 15:15:04 +00:00
Aaron Kling
18f020320f arm64: tegra: Add support for NVIDIA Shield TV Pro 2019 
Add initial device-tree support for NVIDIA Shield TV Pro 2019 (a.k.a
MDarcy) based up the Tegra210B01 SoC with 3 GiB of LPDDR4 RAM.

This is very basic, intended for checking initial Tegra210B01 support.
More complete support for the device will be added later.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:04 +00:00
Aaron Kling
52dedf079c arm64: tegra: Add Tegra210B01 support 
Also known as Tegra X1+, the Tegra210B01 has higher CPU and GPU clocks
than the original Tegra210.

Add a SoC-level device tree file that describes most of the hardware
available on the SoC. This is derived from the Tegra210 dtsi, as they
share a lot.

Co-authored-by: Thomas Makin <halorocker89@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:04 +00:00
Aaron Kling
e8eeb3dd61 arm64: tegra: Add BPMP node for Tegra210 
The Tegra210 soc supports bpmp offload for power management among other
things. This was considered insecure partway through the soc's lifecycle
and support was removed in the bootloader. However, Tegra210B01 returned
to using the bpmp. Plus old bootloaders on the original Tegra210 still
work with the existing driver. So add the node to the common Tegra210
soc dtsi, but disabled by default.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:04 +00:00
Thomas Makin
99c38e06b6 memory: tegra186-emc: support Tegra210B01 
Tegra210B01 uses Tegra186 style emc management, as in it is
offloaded to BPMP. This driver already implements this, so no
reason to shoehorn in elsewhere.

Signed-off-by: Thomas Makin <halorocker89@gmail.com>
 2025-11-11 15:15:03 +00:00
Aaron Kling
d5fb30731c clk: tegra: Add Tegra210B01 support 
This is based on the downstream Nvidia 5.10 kernel. That version was
semi-integrated into the Tegra210 clock driver. Looking at the existing
Tegra210 support, it made more sense to make this a fully independent
driver, so that is implemented here.

Co-authored-by: Thomas Makin <halorocker89@gmail.com>
Change-Id: Iadee08494eff823155e228063bee8f7a280cbcef
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:03 +00:00
Aaron Kling
07ed2fb23b thermal: tegra: Add Tegra210B01 Support 
Add Tegra210B01 SOC_THERM configuration

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:03 +00:00
Aaron Kling
47ce25d2c5 usb: gadget: tegra-xudc: Add Tegra210B01 Support 
It doesn't need some of the workarounds that the original Tegra210 does.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:03 +00:00
Aaron Kling
dff5ed4c9a usb: xhci: tegra: Add Tegra210B01 support 
This uses a different firmware, but is otherwise compatible with
Tegra210.
 2025-11-11 15:15:03 +00:00
Aaron Kling
cce56005b7 phy: tegra: xusb: Add Tegra201B01 Support 
It has slightly different lanes compared to the original Tegra210.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:03 +00:00
Azkali Manad
16de65709b soc/tegra: pmc: Add Tegra210B01 support 
Co-authored-by: Thomas Makin <halorocker89@gmail.com>
Signed-off-by: Azkali Manad <a.ffcc7@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:03 +00:00
Aaron Kling
fab2cba2df dt-bindings: clock: tegra: Document Tegra210B01 
* Add the compatible string for Tegra210B01 clock and reset
* Add Tegra210B01 specific clock bindings

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:03 +00:00
Venkat Reddy Talla
ec0d70298b regulator: max77812: add max77812 regulator driver 
Adding regulator driver for MAX77812 device which is
used in t210b01 based platforms for powering cpu,gpu
and dram io

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:03 +00:00
Aaron Kling
412e4e172e power: supply: bq24190_charger: Support usb role switching 
Change-Id: Ia1e650f15ae55bb0972612b378d093a20d8a8a98
 2025-11-11 15:15:03 +00:00
Aaron Kling
e24dd8dceb power: supply: bq24190_charger: Export current regulator 
Change-Id: I3958896da66740d503aec5ed93e14a7d743a43ac
 2025-11-11 15:15:03 +00:00
Aaron Kling
5145442e1e power: bq24190: support bq24193 
Change-Id: I66f665af1913a6bf92fa28f10afd9bae845d8867
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:03 +00:00
Aaron Kling
a5c7fa6a90 memory: tegra210-emc: Support Device Tree EMC Tables 
These are generated by the Tegra210 Android bootloader. This is similar
to the Tegra124 handling, so the support is based on that and modified
to match Tegra210 by referencing the downstream Nvidia 4.9 kernel.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:03 +00:00
Aaron Kling
ffe7238665 arm64: tegra: Add EMC timings to P2180 
These entries are imported from the downstream Nvidia Linux4Tegra
kernel. They are expected to be updated with the trained values by the
bootloader. This is done by the Nvidia Android bootloader, which is
different from the handling by the Nvidia Linux bootloader which places
these values in a reserved memory location. P2180 is supported by both
bootloaders, so lets support initializing emc on both.

It should be noted that the bootloader will not create these nodes in
the kernel dtb if they do not exist. It will only set in place existing
properties.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Svyatoslav Ryhel
ed8702254a ARM: tegra: Add DSI-A and DSI-B nodes on Tegra124 
Bind DSI devices and MIPI calibration.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://lore.kernel.org/r/20250226105615.61087-6-clamor95@gmail.com
Signed-off-by: Thierry Reding <treding@nvidia.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
07b857abe5 gpio: palmas: Allow building as a module 
The driver works fine as a module, so allowing building as such. This
adds an exit handler to support module unload.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
49a0bd6704 arm64: tegra: Add Tegra186 pin controllers 
Add the device tree nodes for the MAIN and AON pin controllers found on
the Tegra186 family of SoCs.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
c1548709ab pinctrl: tegra: Add Tegra186 pinmux driver 
This is based on Nvidia's downstream 5.10 driver, rewritten to match the
mainline Tegra194 pinmux driver.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
6aed033f53 dt-bindings: gpio: tegra186: Add gpio-ranges 
Add optional gpio-ranges property.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
dec2ac6aff dt-bindings: pinctrl: Document Tegra186 pin controllers 
Tegra186 contains two pin controllers. Document their compatible strings
and describe the list of pins and functions that they provide.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
78b406880f cpuidle: tegra: Export tegra_cpuidle_pcie_irqs_in_use 
Add export for tegra_cpuidle_pcie_irqs_in_use() so that drivers like
pci-tegra can be loaded as a module.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
b70766325d irqdomain: Export irq_domain_free_irqs 
Export irq_domain_free_irqs() to allow PCI/MSI drivers like pci-tegra to
be built as a module.

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
65aa274d15 arm64: tegra: Enable HDA controller on P2894 
The HDA controller can be used for audio playback over HDMI.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
b715036d9c arm64: tegra: Enable HDMI on P2894 
Add regulators and enable the host1x nodes necessary to attain video
output via hdmi.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
d271e4e311 WIP: arm64: tegra: Enable APE on P2894 
TODO: Drop usused external codecs

Enable support for audio-graph based sound card on P2894. Required I/O
interfaces are enabled.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:02 +00:00
Aaron Kling
a4ac4e98a5 arm64: tegra: Enable DFLL clock on P2894 
Add pinmux for PWM-based DFLL support.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
b603d035b1 arm64: tegra: Enable PWM fan on P2894 
This is based on 6f78a94, which enabled added the fan and thermal zones
for the Jetson Nano Devkit. The fan and thermal characteristics of the
two devices are similar, so using the same configuration.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
d66de87b6b arm64: tegra: Enable PCIe on P2894 
The p2894 product has a PCIe ethernet adapter

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
9e4030a477 WIP: arm64: tegra: Enable XUSB controller on P2894 
TODO: Correct otg connector for full size A port

Enable the XUSB controller on P2894. One of the USB 3.0 lanes goes to a
switchable USB-A port, while the second USB 3.0 lane supports the normal
USB-A port.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
7a04b9bc51 arm64: tegra: Add Wifi node for P2894 
The p2894 product has a BCM4354 module with wifi on sdio.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
0455ca103d arm64: tegra: Wire up Bluetooth for P2894 
The p2894 product contains a BCM4354 module with bluetooth on uart.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
169c7531b2 arm64: tegra: Enable gpu on P2894 
This adds the gpu regulator and enables the gpu node.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
6c03bcbfb3 arm64: tegra: Add support for NVIDIA Shield TV 2015 
Add initial device-tree support for NVIDIA Shield TV (a.k.a. Foster)
based upon Tegra210 SoC with 3 GiB of LPDDR4 RAM. It is based on P2571.

Change-Id: Ideeeb15f835ebf7f7617d3989908d245aff4b316
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
e6e75e0cc4 arm64: tegra: Enable HDA controller on P2571 
The HDA controller can be used for audio playback over HDMI.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
c5fc330ec4 arm64: tegra: Enable HDMI on P2571 
Add regulators and enable the host1x nodes necessary to attain video
output via hdmi.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
7816b529c5 WIP: arm64: tegra: Enable APE on P2571 
TODO: Drop unused external codec references

Enable support for audio-graph based sound card on P2571. Required I/O
interfaces are enabled.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
c01c8b6b14 arm64: tegra: Enable DFLL clock on P2571 
Add pinmux for PWM-based DFLL support.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
db2ded908b arm64: tegra: Enable XUSB controller on P2571 
Enable the XUSB controller on P2571. One of the USB 3.0 lanes goes to an
internal ethernet interface, while two other USB 3.0 lanes support the
the USB-A receptacles on the I/O board.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:01 +00:00
Aaron Kling
fca2d7886c arm64: tegra: Enable PWM fan on P2571 
This is based on 6f78a94, which enabled added the fan and thermal zones
for the Jetson Nano Devkit. The fan and thermal characteristics of the
two devices are similar, so using the same configuration.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
0af726c616 arm64: tegra: Add Wifi node for P2530 
The p2530 som has a BCM4354 module with wifi on sdio.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
e99e8cac91 arm64: tegra: Wire up Bluetooth for P2530 
The p2530 som contains a BCM4354 module with bluetooth on uart.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
381fdbc5a5 arm64: tegra: Enable gpu on P2530 
This adds the gpu regulator and enables the gpu node.

Change-Id: I8a0f580fa600d8f37fb3fa497cf657abf2905d5f
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
888868a8e9 arm64: tegra: Add PMIC support on P2530 
Based on the p2180 pmic config, modified to match p2530

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
7a7de6ab35 arm64: tegra: Add P2530 SC7 timings 
Same as 106f7a0 and 47b4e12. Without these, the pmc driver locks up
during boot.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
3549513b0d arm64: tegra: Enable bluetooth on P3310 
The p3310 som contains a BCM4354 module with bluetooth on uart.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
30d99c8fd7 arm64: tegra: Enable wifi on P3310 
The p3310 som has a BCM4354 module with wifi on sdio.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
3d7de18141 arm64: tegra: Fix ldo5 voltage on P3310 
This appears to be a typo. The voltage input to the wireless module is
expected to be 1.8V-3.3V, per the downstream device tree.

Fixes: 02df3f03a8 ("arm64: tegra: Add initial power tree for P3310")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
6f188fca32 arm64: tegra: Add NVIDIA Jetson Nano 2GB Developer Kit support 
This devkit is very similar to P3450, except it has less ram, no display
port, and only 3 usb host ports. Derive from P3450 and disable the
hardware that is unavailable.

Gpio PA6 is used to control the hdmi power rail and needs to be on for
hotplug detect to work. This is mapped to the 3.3V usb hub on P3450.
That usb rail is not used here, so delete the regulator to avoid
conflicts.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
21041900eb arm64: tegra: Set usb micro-b port to otg mode on P3450 
The usb micro-b port on p3450 is capable of otg and doesn't need
hardcoded to peripheral. No other supported tegra device is set up like
this, so align for consistency.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
fbb227f786 arm64: tegra: Remove otg id gpio from Jetson TX2 NX 
The p3509 carrier board does not connect the id gpio. Prior to this, the
gpio role switch driver could not detect the mode of the otg port.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
13f4490c9d arm64: tegra: Add DMA properties for Tegra186 and Tegra194 UARTs 
Adding the missing dmas and dma-names properties which are required
for uart when using with the Tegra HSUART driver.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:15:00 +00:00
Aaron Kling
a6c8c18494 arm64: tegra: Enable PWM fan on the Jetson TX2 Devkit 
This is based on the existing configuration of the Jetson TX2 NX devkit.
The fan and thermal characteristics of the two devkits are similar, so
using the same configuration.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
d904038ff4 arm64: tegra: p3310: Explicitly enable GPU 
The gpu node originally was explicitly left disabled as it was expected
for the bootloader to enable it. However, this is only done in u-boot.
If u-boot is not in the boot chain, this will never be enabled. Other
Tegra186 devices already explicitly enable the gpu, so make p3310 match.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
0005ac0f5e arm64: tegra: Enable PWM fan on the Jetson TX1 Devkit 
This is based on 6f78a94, which enabled added the fan and thermal zones
for the Jetson Nano Devkit. The fan and thermal characteristics of the
two devkits are similar, so using the same configuration.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
f25ac04f34 arm64: tegra: p2180: Explicitly enable GPU 
The gpu node originally was explicitly left disabled as it was expected
for the bootloader to enable it. However, this is only done in u-boot.
If u-boot is not in the boot chain, this will never be enabled. Other
Tegra210 devices already explicitly enable the gpu, so make p2180 match.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
0fe7d9f01b cpufreq: tegra186: Initialize all cores to max frequencies 
During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores
are still at reset values and not reflecting the actual frequency. This
causes get calls to fail. Set all cores to their respective max
frequency during probe to initialize the registers to working values.

Suggested-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
d6fddffbe3 cpufreq: tegra186: Set target frequency for all cpus in policy 
The original commit set all cores in a cluster to a shared policy, but
did not update set_target to apply a frequency change to all cores for
the policy. This caused most cores to remain stuck at their boot
frequency.

Fixes: be4ae8c19492 ("cpufreq: tegra186: Share policy per cluster")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
ce444f4987 cpufreq: tegra186: Share policy per cluster 
This functionally brings tegra186 in line with tegra210 and tegra194,
sharing a cpufreq policy between all cores in a cluster.

Reviewed-by: Sumit Gupta <sumitg@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
 2025-11-11 15:14:59 +00:00
Aaron Kling
666dc7bf47 cpufreq: tegra124: Allow building as a module 
This requires four changes:
* Using the cpufreq-dt register helper to establish a hard dependency
  for depmod to track
* Adding a remove routine to remove the cpufreq-dt device
* Adding a exit routine to handle cleaning up the driver
* Populate module license

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
939d7a1bbd cpufreq: dt: Add register helper 
Cpufreq-dt currently exports no functions. This means that drivers that
are based on cpufreq-dt have no way of establishing a depmod dependency
on it. This helper allows that link.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
8b643632f0 cpufreq: Export disable_cpufreq() 
This is used by the tegra124-cpufreq driver.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
2df944f323 arm64: tegra: Bump #address-cells and #size-cells on Tegra186 
This was done for Tegra194 and Tegra234 in 2838cfd, but Tegra186 was not
part of that change. The same reasoning for that commit also applies to
Tegra186, plus keeping the archs as close to each other as possible makes
it easier to compare between them and support features concurrently.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
7ee206935e arm64: tegra: Wire up cec to devkits 
This enables hdmi cec and routes it to the hdmi port on all supported
Tegra210, Tegra186, and Tegra194 devkits.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
9c56b5cd14 arm64: tegra: Add CEC controller on Tegra210 
The CEC controller found on Tegra210 can be used to control consumer
devices using the HDMI CEC pin.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Link: https://lore.kernel.org/r/20250413-tegra-cec-v4-3-b6337b66ccad@gmail.com
Signed-off-by: Thierry Reding <treding@nvidia.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
3eb493ef4f arm64: tegra: Add fallback cec compatibles 
The tegra_cec driver only declares support up to Tegra210 and will not
declare support for Tegra186 or Tegra194. Thus list a fallback
compatible for these archs to tegra210-cec as they work as-is with the
existing driver.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:59 +00:00
Aaron Kling
bca7de3c9e mfd: max77620: Allow building as a module 
The driver works fine as a module, so allowing building as such.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
 2025-11-11 15:14:58 +00:00
Vidya Sagar
1064acd8e0 PCI: tegra194: Add support for PCIe RC & EP in Tegra234 Platforms 
Add PCIe RC & EP support for Tegra234 Platforms.

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
 2025-11-11 15:14:58 +00:00
Lars-Peter Clausen
5ca021df5f gpio: tegra186: Allow to enable driver on Tegra234 
Support for Tegra234 was added to the tegra186 driver in 1db9b241bb (
"gpio: tegra186: Add support for Tegra234"). But the driver is not
selectable on Tegra234. Update the Kconfig entry to allow the driver to be
enabled on Tegra234.

Enable the driver by default on Tegra 234 as well, similar to the other
platforms it supports.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20241113162939.886242-1-lars@metafoo.de
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
 2025-11-11 15:14:58 +00:00
Lars-Peter Clausen
adf95f6f2d phy: tegra194: p2u: Allow to enable driver on Tegra234 
Commit de60266825 ("phy: tegra: Add PCIe PIPE2UPHY support for Tegra234")
add support for Tegra234 to the tegra194-p2u PHY driver. But the driver is
currently not selectable when Tegra234 SoC support is enabled.

Update the Kconfig entry to allow the driver to be built when support the
Tegra234 SoC is enabled.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
 2025-11-11 15:14:58 +00:00
7402 changed files with 73294 additions and 1130115 deletions
Expand all files Collapse all files

1
.bazelignore
View File

@@ -1 +0,0 @@
common/.kunit

9
.clippy.toml
View File

@@ -1,9 +0,0 @@
# SPDX-License-Identifier: GPL-2.0
check-private-items = true
disallowed-macros = [
# The `clippy::dbg_macro` lint only works with `std::dbg!`, thus we simulate
# it here, see: https://github.com/rust-lang/rust-clippy/issues/11303.
{ path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool", allow-invalid = true },
]

1
.gitignore vendored
View File

@@ -103,7 +103,6 @@ modules.order
# We don't want to ignore the following even if they are dot-files
#
!.clang-format
!.clippy.toml
!.cocciconfig
!.editorconfig
!.get_maintainer.ignore

3326
BUILD.bazel
View File

File diff suppressed because it is too large Load Diff

9
Documentation/ABI/stable/sysfs-class-bluetooth
View File

@@ -1,9 +0,0 @@
What: /sys/class/bluetooth/hci<index>/reset
Date: 14-Jan-2025
KernelVersion: 6.13
Contact: linux-bluetooth@vger.kernel.org
Description: This write-only attribute allows users to trigger the vendor reset
method on the Bluetooth device when arbitrary data is written.
The reset may or may not be done through the device transport
(e.g., UART/USB), and can also be done through an out-of-band
approach such as GPIO.

18
Documentation/ABI/stable/sysfs-module
View File

@@ -45,21 +45,3 @@ Date: Jun 2005
Description:
If the module source has MODULE_VERSION, this file will contain
the version of the source code.
What: /sys/module/MODULENAME/scmversion
Date: November 2020
KernelVersion: 5.12
Contact: Will McVicker <willmcvicker@google.com>
Description: This read-only file will appear if modpost was supplied with an
SCM version for the module. It can be enabled with the config
MODULE_SCMVERSION. The SCM version is retrieved by
scripts/setlocalversion, which means that the presence of this
file depends on CONFIG_LOCALVERSION_AUTO=y. When read, the SCM
version that the module was compiled with is returned. The SCM
version is returned in the following format::
===
Git: g[a-f0-9]\+(-dirty)\?
Mercurial: hg[a-f0-9]\+(-dirty)\?
Subversion: svn[0-9]\+
===

11
Documentation/ABI/testing/sysfs-bus-pci
View File

@@ -163,17 +163,6 @@ Description:
will be present in sysfs. Writing 1 to this file
will perform reset.
What: /sys/bus/pci/devices/.../reset_subordinate
Date: October 2024
Contact: linux-pci@vger.kernel.org
Description:
This is visible only for bridge devices. If you want to reset
all devices attached through the subordinate bus of a specific
bridge device, writing 1 to this will try to do it. This will
affect all devices attached to the system through this bridge
similiar to writing 1 to their individual "reset" file, so use
with caution.
What: /sys/bus/pci/devices/.../vpd
Date: February 2008
Contact: Ben Hutchings <bwh@kernel.org>

16
Documentation/ABI/testing/sysfs-class-android_usb
View File

@@ -1,16 +0,0 @@
Android USB devices (eg. /sys/class/android_usb/android0/)
What: /sys/class/android_usb/<android_device>/state
Date: Feb 2024
Contact: Neill Kapron <nkapron@google.com>
Description:
The state of the USB connection. This attribute is likely
redundant with the /sys/class/UDC/state attribute, and should
be deprecated/removed when userspace can be refactored.
Change on the state will also generate uevent KOBJ_CHANGE on
the port with the new state included in the message as
"USB_STATE=<STATE>". Note this is not the correct usage of
uevents, but necessary due to the requirement to maintaine
userspace API compatibility.
Valid values: CONNECTED, DISCONNECTED, CONFIGURED

2
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@@ -511,7 +511,6 @@ Description: information about CPUs heterogeneity.
What: /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
/sys/devices/system/cpu/vulnerabilities/indirect_target_selection
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
/sys/devices/system/cpu/vulnerabilities/l1tf
/sys/devices/system/cpu/vulnerabilities/mds
@@ -523,7 +522,6 @@ What: /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spectre_v1
/sys/devices/system/cpu/vulnerabilities/spectre_v2
/sys/devices/system/cpu/vulnerabilities/srbds
/sys/devices/system/cpu/vulnerabilities/tsa
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
Date: January 2018
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>

162
Documentation/ABI/testing/sysfs-driver-ufs
View File

@@ -711,7 +711,7 @@ Description: This file shows the thin provisioning type. This is one of
The file is read only.
What: /sys/class/scsi_device/*/device/unit_descriptor/physical_memory_resource_count
What: /sys/class/scsi_device/*/device/unit_descriptor/physical_memory_resourse_count
Date: February 2018
Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
Description: This file shows the total physical memory resources. This is
@@ -1559,163 +1559,3 @@ Description:
Symbol - HCMID. This file shows the UFSHCD manufacturer id.
The Manufacturer ID is defined by JEDEC in JEDEC-JEP106.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/critical_health
What: /sys/bus/platform/devices/*.ufs/critical_health
Date: February 2025
Contact: Avri Altman <avri.altman@wdc.com>
Description: Report the number of times a critical health event has been
reported by a UFS device. Further insight into the specific
issue can be gained by reading one of: bPreEOLInfo,
bDeviceLifeTimeEstA, bDeviceLifeTimeEstB,
bWriteBoosterBufferLifeTimeEst, and bRPMBLifeTimeEst.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/clkscale_enable
What: /sys/bus/platform/devices/*.ufs/clkscale_enable
Date: January 2025
Contact: Ziqi Chen <quic_ziqichen@quicinc.com>
Description:
This attribute shows whether the UFS clock scaling is enabled or not.
And it can be used to enable/disable the clock scaling by writing
1 or 0 to this attribute.
The attribute is read/write.
What: /sys/bus/platform/drivers/ufshcd/*/clkgate_enable
What: /sys/bus/platform/devices/*.ufs/clkgate_enable
Date: January 2025
Contact: Ziqi Chen <quic_ziqichen@quicinc.com>
Description:
This attribute shows whether the UFS clock gating is enabled or not.
And it can be used to enable/disable the clock gating by writing
1 or 0 to this attribute.
The attribute is read/write.
What: /sys/bus/platform/drivers/ufshcd/*/clkgate_delay_ms
What: /sys/bus/platform/devices/*.ufs/clkgate_delay_ms
Date: January 2025
Contact: Ziqi Chen <quic_ziqichen@quicinc.com>
Description:
This attribute shows and sets the number of milliseconds of idle time
before the UFS driver starts to perform clock gating. This can
prevent the UFS from frequently performing clock gating/ungating.
The attribute is read/write.
What: /sys/bus/platform/drivers/ufshcd/*/device_lvl_exception_count
What: /sys/bus/platform/devices/*.ufs/device_lvl_exception_count
Date: March 2025
Contact: Bao D. Nguyen <quic_nguyenb@quicinc.com>
Description:
This attribute is applicable to ufs devices compliant to the
JEDEC specifications version 4.1 or later. The
device_lvl_exception_count is a counter indicating the number of
times the device level exceptions have occurred since the last
time this variable is reset. Writing a 0 value to this
attribute will reset the device_lvl_exception_count. If the
device_lvl_exception_count reads a positive value, the user
application should read the device_lvl_exception_id attribute to
know more information about the exception.
The attribute is read/write.
What: /sys/bus/platform/drivers/ufshcd/*/device_lvl_exception_id
What: /sys/bus/platform/devices/*.ufs/device_lvl_exception_id
Date: March 2025
Contact: Bao D. Nguyen <quic_nguyenb@quicinc.com>
Description:
Reading the device_lvl_exception_id returns the
qDeviceLevelExceptionID attribute of the ufs device JEDEC
specification version 4.1. The definition of the
qDeviceLevelExceptionID is the ufs device vendor specific
implementation. Refer to the device manufacturer datasheet for
more information on the meaning of the qDeviceLevelExceptionID
attribute value.
The attribute is read only.
What: /sys/bus/platform/drivers/ufshcd/*/hid/analysis_trigger
What: /sys/bus/platform/devices/*.ufs/hid/analysis_trigger
Date: May 2025
Contact: Huan Tang <tanghuan@vivo.com>
Description:
The host can enable or disable HID analysis operation.
======= =========================================
disable disable HID analysis operation
enable enable HID analysis operation
======= =========================================
The file is write only.
What: /sys/bus/platform/drivers/ufshcd/*/hid/defrag_trigger
What: /sys/bus/platform/devices/*.ufs/hid/defrag_trigger
Date: May 2025
Contact: Huan Tang <tanghuan@vivo.com>
Description:
The host can enable or disable HID defragmentation operation.
======= =========================================
disable disable HID defragmentation operation
enable enable HID defragmentation operation
======= =========================================
The attribute is write only.
What: /sys/bus/platform/drivers/ufshcd/*/hid/fragmented_size
What: /sys/bus/platform/devices/*.ufs/hid/fragmented_size
Date: May 2025
Contact: Huan Tang <tanghuan@vivo.com>
Description:
The total fragmented size in the device is reported through
this attribute.
The attribute is read only.
What: /sys/bus/platform/drivers/ufshcd/*/hid/defrag_size
What: /sys/bus/platform/devices/*.ufs/hid/defrag_size
Date: May 2025
Contact: Huan Tang <tanghuan@vivo.com>
Description:
The host sets the size to be defragmented by an HID
defragmentation operation.
The attribute is read/write.
What: /sys/bus/platform/drivers/ufshcd/*/hid/progress_ratio
What: /sys/bus/platform/devices/*.ufs/hid/progress_ratio
Date: May 2025
Contact: Huan Tang <tanghuan@vivo.com>
Description:
Defragmentation progress is reported by this attribute,
indicates the ratio of the completed defragmentation size
over the requested defragmentation size.
==== ============================================
1 1%
...
100 100%
==== ============================================
The attribute is read only.
What: /sys/bus/platform/drivers/ufshcd/*/hid/state
What: /sys/bus/platform/devices/*.ufs/hid/state
Date: May 2025
Contact: Huan Tang <tanghuan@vivo.com>
Description:
The HID state is reported by this attribute.
==================== ===========================
idle Idle (analysis required)
analysis_in_progress Analysis in progress
defrag_required Defrag required
defrag_in_progress Defrag in progress
defrag_completed Defrag completed
defrag_not_required Defrag is not required
==================== ===========================
The attribute is read only.

70
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@@ -270,7 +270,7 @@ Description: Shows all enabled kernel features.
inode_checksum, flexible_inline_xattr, quota_ino,
inode_crtime, lost_found, verity, sb_checksum,
casefold, readonly, compression, test_dummy_encryption_v2,
atomic_write, pin_file, encrypted_casefold, linear_lookup.
atomic_write, pin_file, encrypted_casefold.
What: /sys/fs/f2fs/<disk>/inject_rate
Date: May 2016
@@ -311,13 +311,10 @@ Description: Do background GC aggressively when set. Set to 0 by default.
GC approach and turns SSR mode on.
gc urgent low(2): lowers the bar of checking I/O idling in
order to process outstanding discard commands and GC a
little bit aggressively. always uses cost benefit GC approach,
and will override age-threshold GC approach if ATGC is enabled
at the same time.
little bit aggressively. uses cost benefit GC approach.
gc urgent mid(3): does GC forcibly in a period of given
gc_urgent_sleep_time and executes a mid level of I/O idling check.
always uses cost benefit GC approach, and will override
age-threshold GC approach if ATGC is enabled at the same time.
uses cost benefit GC approach.
What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time
Date: August 2017
@@ -734,7 +731,6 @@ Description: Support configuring fault injection type, should be
FAULT_BLKADDR_VALIDITY 0x000040000
FAULT_BLKADDR_CONSISTENCE 0x000080000
FAULT_NO_SEGMENT 0x000100000
FAULT_INCONSISTENT_FOOTER 0x000200000
=========================== ===========
What: /sys/fs/f2fs/<disk>/discard_io_aware_gran
@@ -823,63 +819,3 @@ Description: It controls the valid block ratio threshold not to trigger excessiv
for zoned deivces. The initial value of it is 95(%). F2FS will stop the
background GC thread from intiating GC for sections having valid blocks
exceeding the ratio.
What: /sys/fs/f2fs/<disk>/max_read_extent_count
Date: November 2024
Contact: "Chao Yu" <chao@kernel.org>
Description: It controls max read extent count for per-inode, the value of threshold
is 10240 by default.
What: /sys/fs/f2fs/tuning/reclaim_caches_kb
Date: February 2025
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: It reclaims the given KBs of file-backed pages registered by
ioctl(F2FS_IOC_DONATE_RANGE).
For example, writing N tries to drop N KBs spaces in LRU.
What: /sys/fs/f2fs/<disk>/carve_out
Date: March 2025
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: For several zoned storage devices, vendors will provide extra space which
was used for device level GC than specs and F2FS can use this space for
filesystem level GC. To do that, we can reserve the space using
reserved_blocks. However, it is not enough, since this extra space should
not be shown to users. So, with this new sysfs node, we can hide the space
by substracting reserved_blocks from total bytes.
What: /sys/fs/f2fs/<disk>/encoding_flags
Date: April 2025
Contact: "Chao Yu" <chao@kernel.org>
Description: This is a read-only entry to show the value of sb.s_encoding_flags, the
value is hexadecimal.
============================ ==========
Flag_Name Flag_Value
============================ ==========
SB_ENC_STRICT_MODE_FL 0x00000001
SB_ENC_NO_COMPAT_FALLBACK_FL 0x00000002
============================ ==========
What: /sys/fs/f2fs/<disk>/reserved_pin_section
Date: June 2025
Contact: "Chao Yu" <chao@kernel.org>
Description: This threshold is used to control triggering garbage collection while
fallocating on pinned file, so, it can guarantee there is enough free
reserved section before preallocating on pinned file.
By default, the value is ovp_sections, especially, for zoned ufs, the
value is 1.
What: /sys/fs/f2fs/<disk>/effective_lookup_mode
Date: August 2025
Contact: "Daniel Lee" <chullee@google.com>
Description:
This is a read-only entry to show the effective directory lookup mode
F2FS is currently using for casefolded directories.
This considers both the "lookup_mode" mount option and the on-disk
encoding flag, SB_ENC_NO_COMPAT_FALLBACK_FL.
Possible values are:
- "perf": Hash-only lookup.
- "compat": Hash-based lookup with a linear search fallback enabled
- "auto:perf": lookup_mode is auto and fallback is disabled on-disk
- "auto:compat": lookup_mode is auto and fallback is enabled on-disk

27
Documentation/ABI/testing/sysfs-fs-fuse
View File

@@ -1,27 +0,0 @@
What: /sys/fs/fuse/features/fuse_bpf
Date: December 2022
Contact: Paul Lawrence <paullawrence@google.com>
Description:
Read-only file that contains the word 'supported' if fuse-bpf is
supported, does not exist otherwise
What: /sys/fs/fuse/features/fuse_passthrough
Date: February 2025
Contact: Daniel Rosenberg <drosen@google.com>
Description:
Read-only file that contains the word 'supported' if fuse
passthrough with Android modifications is supported, does not
exist otherwise
What: /sys/fs/fuse/bpf_prog_type_fuse
Date: December 2022
Contact: Paul Lawrence <paullawrence@google.com>
Description:
bpf_prog_type_fuse defines the program type of bpf programs that
may be passed to fuse-bpf. For upstream bpf program types, this
is a constant defined in a contiguous array of constants.
bpf_prog_type_fuse is appended to the end of the list, so it may
change and therefore its value must be read from this file.
Contents is ASCII decimal representation of bpf_prog_type_fuse

70
Documentation/ABI/testing/sysfs-fs-incfs
View File

@@ -1,70 +0,0 @@
What: /sys/fs/incremental-fs/features/corefs
Date: 2019
Contact: Paul Lawrence <paullawrence@google.com>
Description: Reads 'supported'. Always present.
What: /sys/fs/incremental-fs/features/v2
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Reads 'supported'. Present if all v2 features of incfs are
supported.
What: /sys/fs/incremental-fs/features/zstd
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Reads 'supported'. Present if zstd compression is supported
for data blocks.
What: /sys/fs/incremental-fs/features/bugfix_throttling
Date: January 2023
Contact: Paul Lawrence <paullawrence@google.com>
Description: Reads 'supported'. Present if the throttling lock bug is fixed
https://android-review.git.corp.google.com/c/kernel/common/+/2381827
What: /sys/fs/incremental-fs/instances/[name]
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Folder created when incfs is mounted with the sysfs_name=[name]
option. If this option is used, the following values are created
in this folder.
What: /sys/fs/incremental-fs/instances/[name]/reads_delayed_min
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Returns a count of the number of reads that were delayed as a
result of the per UID read timeouts min time setting.
What: /sys/fs/incremental-fs/instances/[name]/reads_delayed_min_us
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Returns total delay time for all files since first mount as a
result of the per UID read timeouts min time setting.
What: /sys/fs/incremental-fs/instances/[name]/reads_delayed_pending
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Returns a count of the number of reads that were delayed as a
result of waiting for a pending read.
What: /sys/fs/incremental-fs/instances/[name]/reads_delayed_pending_us
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Returns total delay time for all files since first mount as a
result of waiting for a pending read.
What: /sys/fs/incremental-fs/instances/[name]/reads_failed_hash_verification
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Returns number of reads that failed because of hash verification
failures.
What: /sys/fs/incremental-fs/instances/[name]/reads_failed_other
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Returns number of reads that failed for reasons other than
timing out or hash failures.
What: /sys/fs/incremental-fs/instances/[name]/reads_failed_timed_out
Date: April 2021
Contact: Paul Lawrence <paullawrence@google.com>
Description: Returns number of reads that timed out.

7
Documentation/ABI/testing/sysfs-kernel-dmaheap
View File

@@ -1,7 +0,0 @@
What: /sys/kernel/dma_heap/total_pools_kb
Date: Feb 2021
KernelVersion: 5.10
Contact: T.J. Mercier <tjmercier@google.com>
Description:
The total_pools_kb file is read-only and specifies how much
memory in KiB is allocated to DMA-BUF heap pools.

16
Documentation/ABI/testing/sysfs-kernel-wakeup_reasons
View File

@@ -1,16 +0,0 @@
What: /sys/kernel/wakeup_reasons/last_resume_reason
Date: February 2014
Contact: Ruchi Kandoi <kandoiruchi@google.com>
Description:
The /sys/kernel/wakeup_reasons/last_resume_reason is
used to report wakeup reasons after system exited suspend.
What: /sys/kernel/wakeup_reasons/last_suspend_time
Date: March 2015
Contact: jinqian <jinqian@google.com>
Description:
The /sys/kernel/wakeup_reasons/last_suspend_time is
used to report time spent in last suspend cycle. It contains
two numbers (in seconds) separated by space. First number is
the time spent in suspend and resume processes. Second number
is the time spent in sleep state.

2
Documentation/RCU/stallwarn.rst
View File

@@ -249,7 +249,7 @@ ticks this GP)" indicates that this CPU has not taken any scheduling-clock
interrupts during the current stalled grace period.
The "idle=" portion of the message prints the dyntick-idle state.
The hex number before the first "/" is the low-order 16 bits of the
The hex number before the first "/" is the low-order 12 bits of the
dynticks counter, which will have an even-numbered value if the CPU
is in dyntick-idle mode and an odd-numbered value otherwise. The hex
number between the two "/"s is the value of the nesting, which will be

10
Documentation/RCU/whatisRCU.rst
View File

@@ -971,16 +971,6 @@ unfortunately any spinlock in a ``SLAB_TYPESAFE_BY_RCU`` object must be
initialized after each and every call to kmem_cache_alloc(), which renders
reference-free spinlock acquisition completely unsafe. Therefore, when
using ``SLAB_TYPESAFE_BY_RCU``, make proper use of a reference counter.
If using refcount_t, the specialized refcount_{add|inc}_not_zero_acquire()
and refcount_set_release() APIs should be used to ensure correct operation
ordering when verifying object identity and when initializing newly
allocated objects. Acquire fence in refcount_{add|inc}_not_zero_acquire()
ensures that identity checks happen *after* reference count is taken.
refcount_set_release() should be called after a newly allocated object is
fully initialized and release fence ensures that new values are visible
*before* refcount can be successfully taken by other users. Once
refcount_set_release() is called, the object should be considered visible
by other tasks.
(Those willing to initialize their locks in a kmem_cache constructor
may also use locking, including cache-friendly sequence locking.)

14
Documentation/accel/qaic/aic080.rst
View File

@@ -1,14 +0,0 @@
.. SPDX-License-Identifier: GPL-2.0-only
===============================
Qualcomm Cloud AI 80 (AIC080)
===============================
Overview
========
The Qualcomm Cloud AI 80/AIC080 family of products are a derivative of AIC100.
The number of NSPs and clock rates are reduced to fit within resource
constrained solutions. The PCIe Product ID is 0xa080.
As a derivative product, all AIC100 documentation applies.

1
Documentation/accel/qaic/index.rst
View File

@@ -10,5 +10,4 @@ accelerator cards.
.. toctree::
qaic
aic080
aic100

2
Documentation/admin-guide/blockdev/zram.rst
View File

@@ -47,8 +47,6 @@ The list of possible return codes:
-ENOMEM zram was not able to allocate enough memory to fulfil your
needs.
-EINVAL invalid input has been provided.
-EAGAIN re-try operation later (e.g. when attempting to run recompress
and writeback simultaneously).
======== =============================================================
If you use 'echo', the returned value is set by the 'echo' utility,

2
Documentation/admin-guide/cgroup-v2.rst
View File

@@ -2954,7 +2954,7 @@ following two functions.
a queue (device) has been associated with the bio and
before submission.
wbc_account_cgroup_owner(@wbc, @folio, @bytes)
wbc_account_cgroup_owner(@wbc, @page, @bytes)
Should be called for each data segment being written out.
While this function doesn't care exactly when it's called
during the writeback session, it's the easiest and most

11
Documentation/admin-guide/device-mapper/verity.rst
View File

@@ -142,15 +142,8 @@ root_hash_sig_key_desc <key_description>
already in the secondary trusted keyring.
try_verify_in_tasklet
If verity hashes are in cache and the IO size does not exceed the limit,
verify data blocks in bottom half instead of workqueue. This option can
reduce IO latency. The size limits can be configured via
/sys/module/dm_verity/parameters/use_bh_bytes. The four parameters
correspond to limits for IOPRIO_CLASS_NONE, IOPRIO_CLASS_RT,
IOPRIO_CLASS_BE and IOPRIO_CLASS_IDLE in turn.
For example:
<none>,<rt>,<be>,<idle>
4096,4096,4096,4096
If verity hashes are in cache, verify data blocks in kernel tasklet instead
of workqueue. This option can reduce IO latency.
Theory of operation
===================

1
Documentation/admin-guide/hw-vuln/index.rst
View File

@@ -22,4 +22,3 @@ are configurable at compile, boot or run time.
srso
gather_data_sampling
reg-file-data-sampling
indirect-target-selection

168
Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
View File

@@ -1,168 +0,0 @@
.. SPDX-License-Identifier: GPL-2.0
Indirect Target Selection (ITS)
===============================
ITS is a vulnerability in some Intel CPUs that support Enhanced IBRS and were
released before Alder Lake. ITS may allow an attacker to control the prediction
of indirect branches and RETs located in the lower half of a cacheline.
ITS is assigned CVE-2024-28956 with a CVSS score of 4.7 (Medium).
Scope of Impact
---------------
- **eIBRS Guest/Host Isolation**: Indirect branches in KVM/kernel may still be
predicted with unintended target corresponding to a branch in the guest.
- **Intra-Mode BTI**: In-kernel training such as through cBPF or other native
gadgets.
- **Indirect Branch Prediction Barrier (IBPB)**: After an IBPB, indirect
branches may still be predicted with targets corresponding to direct branches
executed prior to the IBPB. This is fixed by the IPU 2025.1 microcode, which
should be available via distro updates. Alternatively microcode can be
obtained from Intel's github repository [#f1]_.
Affected CPUs
-------------
Below is the list of ITS affected CPUs [#f2]_ [#f3]_:
======================== ============ ==================== ===============
Common name Family_Model eIBRS Intra-mode BTI
Guest/Host Isolation
======================== ============ ==================== ===============
SKYLAKE_X (step >= 6) 06_55H Affected Affected
ICELAKE_X 06_6AH Not affected Affected
ICELAKE_D 06_6CH Not affected Affected
ICELAKE_L 06_7EH Not affected Affected
TIGERLAKE_L 06_8CH Not affected Affected
TIGERLAKE 06_8DH Not affected Affected
KABYLAKE_L (step >= 12) 06_8EH Affected Affected
KABYLAKE (step >= 13) 06_9EH Affected Affected
COMETLAKE 06_A5H Affected Affected
COMETLAKE_L 06_A6H Affected Affected
ROCKETLAKE 06_A7H Not affected Affected
======================== ============ ==================== ===============
- All affected CPUs enumerate Enhanced IBRS feature.
- IBPB isolation is affected on all ITS affected CPUs, and need a microcode
update for mitigation.
- None of the affected CPUs enumerate BHI_CTRL which was introduced in Golden
Cove (Alder Lake and Sapphire Rapids). This can help guests to determine the
host's affected status.
- Intel Atom CPUs are not affected by ITS.
Mitigation
----------
As only the indirect branches and RETs that have their last byte of instruction
in the lower half of the cacheline are vulnerable to ITS, the basic idea behind
the mitigation is to not allow indirect branches in the lower half.
This is achieved by relying on existing retpoline support in the kernel, and in
compilers. ITS-vulnerable retpoline sites are runtime patched to point to newly
added ITS-safe thunks. These safe thunks consists of indirect branch in the
second half of the cacheline. Not all retpoline sites are patched to thunks, if
a retpoline site is evaluated to be ITS-safe, it is replaced with an inline
indirect branch.
Dynamic thunks
~~~~~~~~~~~~~~
From a dynamically allocated pool of safe-thunks, each vulnerable site is
replaced with a new thunk, such that they get a unique address. This could
improve the branch prediction accuracy. Also, it is a defense-in-depth measure
against aliasing.
Note, for simplicity, indirect branches in eBPF programs are always replaced
with a jump to a static thunk in __x86_indirect_its_thunk_array. If required,
in future this can be changed to use dynamic thunks.
All vulnerable RETs are replaced with a static thunk, they do not use dynamic
thunks. This is because RETs get their prediction from RSB mostly that does not
depend on source address. RETs that underflow RSB may benefit from dynamic
thunks. But, RETs significantly outnumber indirect branches, and any benefit
from a unique source address could be outweighed by the increased icache
footprint and iTLB pressure.
Retpoline
~~~~~~~~~
Retpoline sequence also mitigates ITS-unsafe indirect branches. For this
reason, when retpoline is enabled, ITS mitigation only relocates the RETs to
safe thunks. Unless user requested the RSB-stuffing mitigation.
RSB Stuffing
~~~~~~~~~~~~
RSB-stuffing via Call Depth Tracking is a mitigation for Retbleed RSB-underflow
attacks. And it also mitigates RETs that are vulnerable to ITS.
Mitigation in guests
^^^^^^^^^^^^^^^^^^^^
All guests deploy ITS mitigation by default, irrespective of eIBRS enumeration
and Family/Model of the guest. This is because eIBRS feature could be hidden
from a guest. One exception to this is when a guest enumerates BHI_DIS_S, which
indicates that the guest is running on an unaffected host.
To prevent guests from unnecessarily deploying the mitigation on unaffected
platforms, Intel has defined ITS_NO bit(62) in MSR IA32_ARCH_CAPABILITIES. When
a guest sees this bit set, it should not enumerate the ITS bug. Note, this bit
is not set by any hardware, but is **intended for VMMs to synthesize** it for
guests as per the host's affected status.
Mitigation options
^^^^^^^^^^^^^^^^^^
The ITS mitigation can be controlled using the "indirect_target_selection"
kernel parameter. The available options are:
======== ===================================================================
on (default) Deploy the "Aligned branch/return thunks" mitigation.
If spectre_v2 mitigation enables retpoline, aligned-thunks are only
deployed for the affected RET instructions. Retpoline mitigates
indirect branches.
off Disable ITS mitigation.
vmexit Equivalent to "=on" if the CPU is affected by guest/host isolation
part of ITS. Otherwise, mitigation is not deployed. This option is
useful when host userspace is not in the threat model, and only
attacks from guest to host are considered.
stuff Deploy RSB-fill mitigation when retpoline is also deployed.
Otherwise, deploy the default mitigation. When retpoline mitigation
is enabled, RSB-stuffing via Call-Depth-Tracking also mitigates
ITS.
force Force the ITS bug and deploy the default mitigation.
======== ===================================================================
Sysfs reporting
---------------
The sysfs file showing ITS mitigation status is:
/sys/devices/system/cpu/vulnerabilities/indirect_target_selection
Note, microcode mitigation status is not reported in this file.
The possible values in this file are:
.. list-table::
* - Not affected
- The processor is not vulnerable.
* - Vulnerable
- System is vulnerable and no mitigation has been applied.
* - Vulnerable, KVM: Not affected
- System is vulnerable to intra-mode BTI, but not affected by eIBRS
guest/host isolation.
* - Mitigation: Aligned branch/return thunks
- The mitigation is enabled, affected indirect branches and RETs are
relocated to safe thunks.
* - Mitigation: Retpolines, Stuffing RSB
- The mitigation is enabled using retpoline and RSB stuffing.
References
----------
.. [#f1] Microcode repository - https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
.. [#f2] Affected Processors list - https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
.. [#f3] Affected Processors list (machine readable) - https://github.com/intel/Intel-affected-processor-list

4
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
View File

@@ -157,7 +157,9 @@ This is achieved by using the otherwise unused and obsolete VERW instruction in
combination with a microcode update. The microcode clears the affected CPU
buffers when the VERW instruction is executed.
Kernel does the buffer clearing with x86_clear_cpu_buffers().
Kernel reuses the MDS function to invoke the buffer clearing:
mds_clear_cpu_buffers()
On MDS affected CPUs, the kernel already invokes CPU buffer clear on
kernel/userspace, hypervisor/guest and C-state (idle) transitions. No

105
Documentation/admin-guide/kernel-parameters.txt
View File

@@ -449,9 +449,6 @@
arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory
Set instructions support
arm64.nompam [ARM64] Unconditionally disable Memory Partitioning And
Monitoring support
arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension
support
@@ -1136,10 +1133,6 @@
can be useful when debugging issues that require an SLB
miss to occur.
disable_dma32= [KNL]
Dynamically disable ZONE_DMA32 on kernels compiled with
CONFIG_ZONE_DMA32=y.
disable= [IPV6]
See Documentation/networking/ipv6.rst.
@@ -1541,10 +1534,6 @@
Format: { "fix" }
Permit 'security.evm' to be updated regardless of
current integrity status.
export_pmu_events
[KNL,ARM64] Sets the PMU export bit (PMCR_EL0.X), which enables
the exporting of events over an IMPLEMENTATION DEFINED PMU event
export bus to another device.
early_page_ext [KNL,EARLY] Enforces page_ext initialization to earlier
stages so cover more early boot allocations.
@@ -1919,10 +1908,6 @@
If specified, z/VM IUCV HVC accepts connections
from listed z/VM user IDs only.
hvc_dcc.enable= [ARM,ARM64] Enable DCC driver at runtime. For GKI,
disabled at runtime by default to prevent
crashes in devices which do not support DCC.
hv_nopvspin [X86,HYPER_V,EARLY]
Disables the paravirt spinlock optimizations
which allow the hypervisor to 'idle' the guest
@@ -2164,23 +2149,6 @@
different crypto accelerators. This option can be used
to achieve best performance for particular HW.
indirect_target_selection= [X86,Intel] Mitigation control for Indirect
Target Selection(ITS) bug in Intel CPUs. Updated
microcode is also required for a fix in IBPB.
on: Enable mitigation (default).
off: Disable mitigation.
force: Force the ITS bug and deploy default
mitigation.
vmexit: Only deploy mitigation if CPU is affected by
guest/host isolation part of ITS.
stuff: Deploy RSB-fill mitigation when retpoline is
also deployed. Otherwise, deploy the default
mitigation.
For details see:
Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
init= [KNL]
Format: <full_path>
Run specified binary instead of /sbin/init as init
@@ -2679,7 +2647,7 @@
CONFIG_KUNIT to be set to be fully enabled. The
default value can be overridden via
KUNIT_DEFAULT_ENABLED.
Default is 0 (disabled)
Default is 1 (enabled)
kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
Default is 0 (don't ignore, but inject #GP)
@@ -2763,11 +2731,6 @@
(enabled). Disable by KVM if hardware lacks support
for NPT.
kvm-arm.hyp_lm_size_mb=
[KVM,ARM,EARLY] Maximum amount of contiguous memory mappable in
the pKVM hypervisor linear map, in MB. Any attempt to map more
memory than this into pKVM stage-1 at run-time may be fatal.
kvm-arm.mode=
[KVM,ARM,EARLY] Select one of KVM/arm64's modes of
operation.
@@ -2778,9 +2741,7 @@
protected guests.
protected: nVHE-based mode with support for guests whose
state is kept private from the host. See
Documentation/virt/kvm/arm/pkvm.rst for more
information about this mode of operation.
state is kept private from the host.
nested: VHE-based mode with support for nested
virtualization. Requires at least ARMv8.3
@@ -2791,17 +2752,6 @@
for the host. "nested" is experimental and should be
used with extreme caution.
kvm-arm.protected_modules=
[KVM,ARM] List of pKVM modules to load before the host
is deprevileged.
This option only applies when booting with
kvm-arm.mode=protected.
kvm-arm.protected_prefault=
[KVM,ARM] Minimum order for each protected VM fault.
This range from 0 (default) to 9.
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM,EARLY] Trap guest accesses to GICv3 group-0
system registers
@@ -3078,8 +3028,6 @@
* max_sec_lba48: Set or clear transfer size limit to
65535 sectors.
* external: Mark port as external (hotplug-capable).
* [no]lpm: Enable or disable link power management.
* [no]setxfer: Indicate if transfer speed mode setting
@@ -3560,7 +3508,6 @@
expose users to several CPU vulnerabilities.
Equivalent to: if nokaslr then kpti=0 [ARM64]
gather_data_sampling=off [X86]
indirect_target_selection=off [X86]
kvm.nx_huge_pages=off [X86]
l1tf=off [X86]
mds=off [X86]
@@ -4759,11 +4706,6 @@
pcmv= [HW,PCMCIA] BadgePAD 4
pcp_thp_order= [MM]
Specify the order of the pcp used by THP.
The specified value must be no greater than HPAGE_PMD_ORDER
(default) and greater than 3 (PAGE_ALLOC_COSTLY_ORDER).
pd_ignore_unused
[PM]
Keep all power-domains already enabled by bootloader on,
@@ -4897,14 +4839,6 @@
Format: <bool>
default: 0 (auto_verbose is enabled)
printk.debug_non_panic_cpus=
Allows storing messages from non-panic CPUs into
the printk log buffer during panic(). They are
flushed to consoles by the panic-CPU on
a best-effort basis.
Format: <bool> (1/Y/y=enable, 0/N/n=disable)
Default: disabled
printk.devkmsg={on,off,ratelimit}
Control writing to /dev/kmsg.
on - unlimited logging to /dev/kmsg from userspace
@@ -5568,21 +5502,6 @@
rcutorture.verbose= [KNL]
Enable additional printk() statements.
rcupdate.rcu_boot_end_delay= [KNL]
Minimum time in milliseconds from the start of boot
that must elapse before the boot sequence can be marked
complete from RCU's perspective, after which RCU's
behavior becomes more relaxed. The default value is also
configurable via CONFIG_RCU_BOOT_END_DELAY.
Userspace can also mark the boot as completed
sooner by writing the time in milliseconds, say once
userspace considers the system as booted, to:
/sys/module/rcupdate/parameters/rcu_boot_end_delay
Or even just writing a value of 0 to this sysfs node.
The sysfs node can also be used to extend the delay
to be larger than the default, assuming the marking
of boot complete has not yet occurred.
rcupdate.rcu_cpu_stall_ftrace_dump= [KNL]
Dump ftrace buffer after reporting RCU CPU
stall warning.
@@ -6025,11 +5944,6 @@
sa1100ir [NET]
See drivers/net/irda/sa1100_ir.c.
sched_proxy_exec= [KNL]
Enables or disables "proxy execution" style
solution to mutex-based priority inversion.
Format: <bool>
sched_verbose [KNL,EARLY] Enables verbose scheduler debug messages.
schedstats= [KNL,X86] Enable or disable scheduled statistics.
@@ -6327,8 +6241,6 @@
Selecting 'on' will also enable the mitigation
against user space to user space task attacks.
Selecting specific mitigation does not force enable
user mitigations.
Selecting 'off' will disable both the kernel and
the user space protections.
@@ -7059,19 +6971,6 @@
having this key zero'ed is acceptable. E.g. in testing
scenarios.
tsa= [X86] Control mitigation for Transient Scheduler
Attacks on AMD CPUs. Search the following in your
favourite search engine for more details:
"Technical guidance for mitigating transient scheduler
attacks".
off - disable the mitigation
on - enable the mitigation (default)
user - mitigate only user/kernel transitions
vm - mitigate only guest/host transitions
tsc= Disable clocksource stability checks for TSC.
Format: <string>
[x86] reliable: mark tsc clocksource as reliable, this

10
Documentation/admin-guide/laptops/thinkpad-acpi.rst
View File

@@ -445,10 +445,8 @@ event code Key Notes
0x1008 0x07 FN+F8 IBM: toggle screen expand
Lenovo: configure UltraNav,
or toggle screen expand.
On 2024 platforms replaced by
0x131f (see below) and on newer
platforms (2025 +) keycode is
replaced by 0x1401 (see below).
On newer platforms (2024+)
replaced by 0x131f (see below)
0x1009 0x08 FN+F9 -
@@ -508,11 +506,9 @@ event code Key Notes
0x1019 0x18 unknown
0x131f ... FN+F8 Platform Mode change (2024 systems).
0x131f ... FN+F8 Platform Mode change.
Implemented in driver.
0x1401 ... FN+F8 Platform Mode change (2025 + systems).
Implemented in driver.
... ... ...
0x1020 0x1F unknown

2
Documentation/admin-guide/media/building.rst
View File

@@ -15,7 +15,7 @@ Please notice, however, that, if:
you should use the main media development tree ``master`` branch:
https://git.linuxtv.org/media.git/
https://git.linuxtv.org/media_tree.git/
In this case, you may find some useful information at the
`LinuxTv wiki pages <https://linuxtv.org/wiki>`_:

2
Documentation/admin-guide/media/saa7134.rst
View File

@@ -67,7 +67,7 @@ Changes / Fixes
Please mail to linux-media AT vger.kernel.org unified diffs against
the linux media git tree:
https://git.linuxtv.org/media.git/
https://git.linuxtv.org/media_tree.git/
This is done by committing a patch at a clone of the git tree and
submitting the patch using ``git send-email``. Don't forget to

3
Documentation/admin-guide/mm/pagemap.rst
View File

@@ -21,8 +21,7 @@ There are four components to pagemap:
* Bit 56 page exclusively mapped (since 4.2)
* Bit 57 pte is uffd-wp write-protected (since 5.13) (see
Documentation/admin-guide/mm/userfaultfd.rst)
* Bit 58 pte is a guard region (since 6.15) (see madvise (2) man page)
* Bits 59-60 zero
* Bits 58-60 zero
* Bit 61 page is file-page or shared-anon (since 3.5)
* Bit 62 page swapped
* Bit 63 page present

22
Documentation/admin-guide/sysctl/kernel.rst
View File

@@ -212,17 +212,6 @@ pid>/``).
This value defaults to 0.
core_sort_vma
=============
The default coredump writes VMAs in address order. By setting
``core_sort_vma`` to 1, VMAs will be written from smallest size
to largest size. This is known to break at least elfutils, but
can be handy when dealing with very large (and truncated)
coredumps where the more useful debugging details are included
in the smaller VMAs.
core_uses_pid
=============
@@ -286,17 +275,6 @@ domain names are in general different. For a detailed discussion
see the ``hostname(1)`` man page.
export_pmu_events (arm64 only)
==============================
Controls the PMU export bit (PMCR_EL0.X), which enables the exporting of
events over an IMPLEMENTATION DEFINED PMU event export bus to another device.
0: disables exporting of events (default).
1: enables exporting of events.
firmware_config
===============

22
Documentation/arch/arm64/booting.rst
View File

@@ -285,12 +285,6 @@ Before jumping into the kernel, the following conditions must be met:
- SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
For CPUs with the Fine Grained Traps 2 (FEAT_FGT2) extension present:
- If EL3 is present and the kernel is entered at EL2:
- SCR_EL3.FGTEn2 (bit 59) must be initialised to 0b1.
For CPUs with support for HCRX_EL2 (FEAT_HCX) present:
- If EL3 is present and the kernel is entered at EL2:
@@ -385,22 +379,6 @@ Before jumping into the kernel, the following conditions must be met:
- SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1.
For CPUs with the Performance Monitors Extension (FEAT_PMUv3p9):
- If EL3 is present:
- MDCR_EL3.EnPM2 (bit 7) must be initialised to 0b1.
- If the kernel is entered at EL1 and EL2 is present:
- HDFGRTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1.
- HDFGRTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1.
- HDFGRTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1.
- HDFGWTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1.
- HDFGWTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1.
- HDFGWTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1.
For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS):
- If the kernel is entered at EL1 and EL2 is present:

2
Documentation/arch/arm64/cpu-feature-registers.rst
View File

@@ -152,8 +152,6 @@ infrastructure:
+------------------------------+---------+---------+
| DIT | [51-48] | y |
+------------------------------+---------+---------+
| MPAM | [43-40] | n |
+------------------------------+---------+---------+
| SVE | [35-32] | y |
+------------------------------+---------+---------+
| GIC | [27-24] | n |

39
Documentation/arch/arm64/elf_hwcaps.rst
View File

@@ -174,28 +174,22 @@ HWCAP2_DCPODP
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
HWCAP2_SVE2
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.SVEver == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0001.
HWCAP2_SVEAES
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.AES == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
HWCAP2_SVEPMULL
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.AES == 0b0010.
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010.
HWCAP2_SVEBITPERM
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.BitPerm == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001.
HWCAP2_SVESHA3
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.SHA3 == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001.
HWCAP2_SVESM4
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.SM4 == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
HWCAP2_FLAGM2
Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
@@ -204,20 +198,16 @@ HWCAP2_FRINT
Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
HWCAP2_SVEI8MM
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.I8MM == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001.
HWCAP2_SVEF32MM
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.F32MM == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001.
HWCAP2_SVEF64MM
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.F64MM == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001.
HWCAP2_SVEBF16
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.BF16 == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001.
HWCAP2_I8MM
Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
@@ -283,8 +273,7 @@ HWCAP2_EBF16
Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
HWCAP2_SVE_EBF16
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.BF16 == 0b0010.
Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0010.
HWCAP2_CSSC
Functionality implied by ID_AA64ISAR2_EL1.CSSC == 0b0001.
@@ -293,8 +282,7 @@ HWCAP2_RPRFM
Functionality implied by ID_AA64ISAR2_EL1.RPRFM == 0b0001.
HWCAP2_SVE2P1
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.SVEver == 0b0010.
Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0010.
HWCAP2_SME2
Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0001.
@@ -321,8 +309,7 @@ HWCAP2_HBC
Functionality implied by ID_AA64ISAR2_EL1.BC == 0b0001.
HWCAP2_SVE_B16B16
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.B16B16 == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.B16B16 == 0b0001.
HWCAP2_LRCPC3
Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0011.

7
Documentation/arch/arm64/silicon-errata.rst
View File

@@ -255,11 +255,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip{08,09,09A,10| #162001900 | N/A |
| | ,10C,11} | | |
| | SMMU PMCG | | |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip09 | #162100801 | HISILICON_ERRATUM_162100801 |
| Hisilicon | Hip{08,09,10,10C| #162001900 | N/A |
| | ,11} SMMU PMCG | | |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |

8
Documentation/arch/arm64/sme.rst
View File

@@ -69,8 +69,8 @@ model features for SME is included in Appendix A.
vectors from 0 to VL/8-1 stored in the same endianness invariant format as is
used for SVE vectors.
* On thread creation PSTATE.ZA and TPIDR2_EL0 are preserved unless CLONE_VM
is specified, in which case PSTATE.ZA is set to 0 and TPIDR2_EL0 is set to 0.
* On thread creation TPIDR2_EL0 is preserved unless CLONE_SETTLS is specified,
in which case it is set to 0.
2. Vector lengths
------------------
@@ -115,7 +115,7 @@ be zeroed.
5. Signal handling
-------------------
* Signal handlers are invoked with PSTATE.SM=0, PSTATE.ZA=0, and TPIDR2_EL0=0.
* Signal handlers are invoked with streaming mode and ZA disabled.
* A new signal frame record TPIDR2_MAGIC is added formatted as a struct
tpidr2_context to allow access to TPIDR2_EL0 from signal handlers.
@@ -241,7 +241,7 @@ prctl(PR_SME_SET_VL, unsigned long arg)
length, or calling PR_SME_SET_VL with the PR_SME_SET_VL_ONEXEC flag,
does not constitute a change to the vector length for this purpose.
* Changing the vector length causes PSTATE.ZA to be cleared.
* Changing the vector length causes PSTATE.ZA and PSTATE.SM to be cleared.
Calling PR_SME_SET_VL with vl equal to the thread's current vector
length, or calling PR_SME_SET_VL with the PR_SME_SET_VL_ONEXEC flag,
does not constitute a change to the vector length for this purpose.

17
Documentation/arch/x86/boot.rst
View File

@@ -896,19 +896,10 @@ Offset/size: 0x260/4
The kernel runtime start address is determined by the following algorithm::
if (relocatable_kernel) {
if (load_address < pref_address)
load_address = pref_address;
runtime_start = align_up(load_address, kernel_alignment);
} else {
runtime_start = pref_address;
}
Hence the necessary memory window location and size can be estimated by
a boot loader as::
memory_window_start = runtime_start;
memory_window_size = init_size;
if (relocatable_kernel)
runtime_start = align_up(load_address, kernel_alignment)
else
runtime_start = pref_address
============ ===============
Field name: handover_offset

8
Documentation/arch/x86/mds.rst
View File

@@ -93,7 +93,7 @@ enters a C-state.
The kernel provides a function to invoke the buffer clearing:
x86_clear_cpu_buffers()
mds_clear_cpu_buffers()
Also macro CLEAR_CPU_BUFFERS can be used in ASM late in exit-to-user path.
Other than CFLAGS.ZF, this macro doesn't clobber any registers.
@@ -185,9 +185,9 @@ Mitigation points
idle clearing would be a window dressing exercise and is therefore not
activated.
The invocation is controlled by the static key cpu_buf_idle_clear which is
switched depending on the chosen mitigation mode and the SMT state of the
system.
The invocation is controlled by the static key mds_idle_clear which is
switched depending on the chosen mitigation mode and the SMT state of
the system.
The buffer clear is only invoked before entering the C-State to prevent
that stale data from the idling CPU from spilling to the Hyper-Thread

221
Documentation/block/inline-encryption.rst
View File

@@ -77,10 +77,10 @@ Basic design
============
We introduce ``struct blk_crypto_key`` to represent an inline encryption key and
how it will be used. This includes the type of the key (standard or
hardware-wrapped); the actual bytes of the key; the size of the key; the
algorithm and data unit size the key will be used with; and the number of bytes
needed to represent the maximum data unit number the key will be used with.
how it will be used. This includes the actual bytes of the key; the size of the
key; the algorithm and data unit size the key will be used with; and the number
of bytes needed to represent the maximum data unit number the key will be used
with.
We introduce ``struct bio_crypt_ctx`` to represent an encryption context. It
contains a data unit number and a pointer to a blk_crypto_key. We add pointers
@@ -301,216 +301,3 @@ kernel will pretend that the device does not support hardware inline encryption
When the crypto API fallback is enabled, this means that all bios with and
encryption context will use the fallback, and IO will complete as usual. When
the fallback is disabled, a bio with an encryption context will be failed.
.. _hardware_wrapped_keys:
Hardware-wrapped keys
=====================
Motivation and threat model
---------------------------
Linux storage encryption (dm-crypt, fscrypt, eCryptfs, etc.) traditionally
relies on the raw encryption key(s) being present in kernel memory so that the
encryption can be performed. This traditionally isn't seen as a problem because
the key(s) won't be present during an offline attack, which is the main type of
attack that storage encryption is intended to protect from.
However, there is an increasing desire to also protect users' data from other
types of attacks (to the extent possible), including:
- Cold boot attacks, where an attacker with physical access to a system suddenly
powers it off, then immediately dumps the system memory to extract recently
in-use encryption keys, then uses these keys to decrypt user data on-disk.
- Online attacks where the attacker is able to read kernel memory without fully
compromising the system, followed by an offline attack where any extracted
keys can be used to decrypt user data on-disk. An example of such an online
attack would be if the attacker is able to run some code on the system that
exploits a Meltdown-like vulnerability but is unable to escalate privileges.
- Online attacks where the attacker fully compromises the system, but their data
exfiltration is significantly time-limited and/or bandwidth-limited, so in
order to completely exfiltrate the data they need to extract the encryption
keys to use in a later offline attack.
Hardware-wrapped keys are a feature of inline encryption hardware that is
designed to protect users' data from the above attacks (to the extent possible),
without introducing limitations such as a maximum number of keys.
Note that it is impossible to **fully** protect users' data from these attacks.
Even in the attacks where the attacker "just" gets read access to kernel memory,
they can still extract any user data that is present in memory, including
plaintext pagecache pages of encrypted files. The focus here is just on
protecting the encryption keys, as those instantly give access to **all** user
data in any following offline attack, rather than just some of it (where which
data is included in that "some" might not be controlled by the attacker).
Solution overview
-----------------
Inline encryption hardware typically has "keyslots" into which software can
program keys for the hardware to use; the contents of keyslots typically can't
be read back by software. As such, the above security goals could be achieved
if the kernel simply erased its copy of the key(s) after programming them into
keyslot(s) and thereafter only referred to them via keyslot number.
However, that naive approach runs into the problem that it limits the number of
unlocked keys to the number of keyslots, which typically is a small number. In
cases where there is only one encryption key system-wide (e.g., a full-disk
encryption key), that can be tolerable. However, in general there can be many
logged-in users with many different keys, and/or many running applications with
application-specific encrypted storage areas. This is especially true if
file-based encryption (e.g. fscrypt) is being used.
Thus, it is important for the kernel to still have a way to "remind" the
hardware about a key, without actually having the raw key itself. This would
ensure that the number of hardware keyslots only limits the number of active I/O
requests, not other things such as the number of logged-in users, the number of
running apps, or the number of encrypted storage areas that apps can create.
Somewhat less importantly, it is also desirable that the raw keys are never
visible to software at all, even while being initially unlocked. This would
ensure that a read-only compromise of system memory will never allow a key to be
extracted to be used off-system, even if it occurs when a key is being unlocked.
To solve all these problems, some vendors of inline encryption hardware have
made their hardware support *hardware-wrapped keys*. Hardware-wrapped keys
are encrypted keys that can only be unwrapped (decrypted) and used by hardware
-- either by the inline encryption hardware itself, or by a dedicated hardware
block that can directly provision keys to the inline encryption hardware.
(We refer to them as "hardware-wrapped keys" rather than simply "wrapped keys"
to add some clarity in cases where there could be other types of wrapped keys,
such as in file-based encryption. Key wrapping is a commonly used technique.)
The key which wraps (encrypts) hardware-wrapped keys is a hardware-internal key
that is never exposed to software; it is either a persistent key (a "long-term
wrapping key") or a per-boot key (an "ephemeral wrapping key"). The long-term
wrapped form of the key is what is initially unlocked, but it is erased from
memory as soon as it is converted into an ephemerally-wrapped key. In-use
hardware-wrapped keys are always ephemerally-wrapped, not long-term wrapped.
As inline encryption hardware can only be used to encrypt/decrypt data on-disk,
the hardware also includes a level of indirection; it doesn't use the unwrapped
key directly for inline encryption, but rather derives both an inline encryption
key and a "software secret" from it. Software can use the "software secret" for
tasks that can't use the inline encryption hardware, such as filenames
encryption. The software secret is not protected from memory compromise.
Key hierarchy
-------------
Here is the key hierarchy for a hardware-wrapped key::
Hardware-wrapped key
|
|
<Hardware KDF>
|
-----------------------------
| |
Inline encryption key Software secret
The components are:
- *Hardware-wrapped key*: a key for the hardware's KDF (Key Derivation
Function), in ephemerally-wrapped form. The key wrapping algorithm is a
hardware implementation detail that doesn't impact kernel operation, but a
strong authenticated encryption algorithm such as AES-256-GCM is recommended.
- *Hardware KDF*: a KDF (Key Derivation Function) which the hardware uses to
derive subkeys after unwrapping the wrapped key. The hardware's choice of KDF
doesn't impact kernel operation, but it does need to be known for testing
purposes, and it's also assumed to have at least a 256-bit security strength.
All known hardware uses the SP800-108 KDF in Counter Mode with AES-256-CMAC,
with a particular choice of labels and contexts; new hardware should use this
already-vetted KDF.
- *Inline encryption key*: a derived key which the hardware directly provisions
to a keyslot of the inline encryption hardware, without exposing it to
software. In all known hardware, this will always be an AES-256-XTS key.
However, in principle other encryption algorithms could be supported too.
Hardware must derive distinct subkeys for each supported encryption algorithm.
- *Software secret*: a derived key which the hardware returns to software so
that software can use it for cryptographic tasks that can't use inline
encryption. This value is cryptographically isolated from the inline
encryption key, i.e. knowing one doesn't reveal the other. (The KDF ensures
this.) Currently, the software secret is always 32 bytes and thus is suitable
for cryptographic applications that require up to a 256-bit security strength.
Some use cases (e.g. full-disk encryption) won't require the software secret.
Example: in the case of fscrypt, the fscrypt master key (the key that protects a
particular set of encrypted directories) is made hardware-wrapped. The inline
encryption key is used as the file contents encryption key, while the software
secret (rather than the master key directly) is used to key fscrypt's KDF
(HKDF-SHA512) to derive other subkeys such as filenames encryption keys.
Note that currently this design assumes a single inline encryption key per
hardware-wrapped key, without any further key derivation. Thus, in the case of
fscrypt, currently hardware-wrapped keys are only compatible with the "inline
encryption optimized" settings, which use one file contents encryption key per
encryption policy rather than one per file. This design could be extended to
make the hardware derive per-file keys using per-file nonces passed down the
storage stack, and in fact some hardware already supports this; future work is
planned to remove this limitation by adding the corresponding kernel support.
Kernel support
--------------
The inline encryption support of the kernel's block layer ("blk-crypto") has
been extended to support hardware-wrapped keys as an alternative to standard
keys, when hardware support is available. This works in the following way:
- A ``key_types_supported`` field is added to the crypto capabilities in
``struct blk_crypto_profile``. This allows device drivers to declare that
they support standard keys, hardware-wrapped keys, or both.
- ``struct blk_crypto_key`` can now contain a hardware-wrapped key as an
alternative to a standard key; a ``key_type`` field is added to
``struct blk_crypto_config`` to distinguish between the different key types.
This allows users of blk-crypto to en/decrypt data using a hardware-wrapped
key in a way very similar to using a standard key.
- A new method ``blk_crypto_ll_ops::derive_sw_secret`` is added. Device drivers
that support hardware-wrapped keys must implement this method. Users of
blk-crypto can call ``blk_crypto_derive_sw_secret()`` to access this method.
- The programming and eviction of hardware-wrapped keys happens via
``blk_crypto_ll_ops::keyslot_program`` and
``blk_crypto_ll_ops::keyslot_evict``, just like it does for standard keys. If
a driver supports hardware-wrapped keys, then it must handle hardware-wrapped
keys being passed to these methods.
blk-crypto-fallback doesn't support hardware-wrapped keys. Therefore,
hardware-wrapped keys can only be used with actual inline encryption hardware.
Currently, the kernel only works with hardware-wrapped keys in
ephemerally-wrapped form. No generic kernel interfaces are provided for
generating or importing hardware-wrapped keys in the first place, or converting
them to ephemerally-wrapped form. In Android, SoC vendors are required to
support these operations in their KeyMint implementation (a hardware abstraction
layer in userspace); for details, see the `Android documentation
<https://source.android.com/security/encryption/hw-wrapped-keys>`_.
Testability
-----------
Both the hardware KDF and the inline encryption itself are well-defined
algorithms that don't depend on any secrets other than the unwrapped key.
Therefore, if the unwrapped key is known to software, these algorithms can be
reproduced in software in order to verify the ciphertext that is written to disk
by the inline encryption hardware.
However, the unwrapped key will only be known to software for testing if the
"import" functionality is used. Proper testing is not possible in the
"generate" case where the hardware generates the key itself. The correct
operation of the "generate" mode thus relies on the security and correctness of
the hardware RNG and its use to generate the key, as well as the testing of the
"import" mode as that should cover all parts other than the key generation.
For an example of a test that verifies the ciphertext written to disk in the
"import" mode, see the fscrypt hardware-wrapped key tests in xfstests, or
`Android's vts_kernel_encryption_test
<https://android.googlesource.com/platform/test/vts-testcase/kernel/+/refs/heads/master/encryption/>`_.

8
Documentation/bpf/bpf_devel_QA.rst
View File

@@ -382,14 +382,6 @@ In case of new BPF instructions, once the changes have been accepted
into the Linux kernel, please implement support into LLVM's BPF back
end. See LLVM_ section below for further information.
Q: What "BPF_INTERNAL" symbol namespace is for?
-----------------------------------------------
A: Symbols exported as BPF_INTERNAL can only be used by BPF infrastructure
like preload kernel modules with light skeleton. Most symbols outside
of BPF_INTERNAL are not expected to be used by code outside of BPF either.
Symbols may lack the designation because they predate the namespaces,
or due to an oversight.
Stable submission
=================

71
Documentation/core-api/dma-api.rst
View File

@@ -530,77 +530,6 @@ routines, e.g.:::
....
}
Part Ie - IOVA-based DMA mappings
---------------------------------
These APIs allow a very efficient mapping when using an IOMMU. They are an
optional path that requires extra code and are only recommended for drivers
where DMA mapping performance, or the space usage for storing the DMA addresses
matter. All the considerations from the previous section apply here as well.
::
bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
phys_addr_t phys, size_t size);
Is used to try to allocate IOVA space for mapping operation. If it returns
false this API can't be used for the given device and the normal streaming
DMA mapping API should be used. The ``struct dma_iova_state`` is allocated
by the driver and must be kept around until unmap time.
::
static inline bool dma_use_iova(struct dma_iova_state *state)
Can be used by the driver to check if the IOVA-based API is used after a
call to dma_iova_try_alloc. This can be useful in the unmap path.
::
int dma_iova_link(struct device *dev, struct dma_iova_state *state,
phys_addr_t phys, size_t offset, size_t size,
enum dma_data_direction dir, unsigned long attrs);
Is used to link ranges to the IOVA previously allocated. The start of all
but the first call to dma_iova_link for a given state must be aligned
to the DMA merge boundary returned by ``dma_get_merge_boundary())``, and
the size of all but the last range must be aligned to the DMA merge boundary
as well.
::
int dma_iova_sync(struct device *dev, struct dma_iova_state *state,
size_t offset, size_t size);
Must be called to sync the IOMMU page tables for IOVA-range mapped by one or
more calls to ``dma_iova_link()``.
For drivers that use a one-shot mapping, all ranges can be unmapped and the
IOVA freed by calling:
::
void dma_iova_destroy(struct device *dev, struct dma_iova_state *state,
size_t mapped_len, enum dma_data_direction dir,
unsigned long attrs);
Alternatively drivers can dynamically manage the IOVA space by unmapping
and mapping individual regions. In that case
::
void dma_iova_unlink(struct device *dev, struct dma_iova_state *state,
size_t offset, size_t size, enum dma_data_direction dir,
unsigned long attrs);
is used to unmap a range previously mapped, and
::
void dma_iova_free(struct device *dev, struct dma_iova_state *state);
is used to free the IOVA space. All regions must have been unmapped using
``dma_iova_unlink()`` before calling ``dma_iova_free()``.
Part II - Non-coherent DMA allocations
--------------------------------------

37
Documentation/core-api/refcount-vs-atomic.rst
View File

@@ -86,19 +86,7 @@ Memory ordering guarantee changes:
* none (both fully unordered)
case 2) - non-"Read/Modify/Write" (RMW) ops with release ordering
-----------------------------------------------------------------
Function changes:
* atomic_set_release() --> refcount_set_release()
Memory ordering guarantee changes:
* none (both provide RELEASE ordering)
case 3) - increment-based ops that return no value
case 2) - increment-based ops that return no value
--------------------------------------------------
Function changes:
@@ -110,7 +98,7 @@ Memory ordering guarantee changes:
* none (both fully unordered)
case 4) - decrement-based RMW ops that return no value
case 3) - decrement-based RMW ops that return no value
------------------------------------------------------
Function changes:
@@ -122,7 +110,7 @@ Memory ordering guarantee changes:
* fully unordered --> RELEASE ordering
case 5) - increment-based RMW ops that return a value
case 4) - increment-based RMW ops that return a value
-----------------------------------------------------
Function changes:
@@ -138,20 +126,7 @@ Memory ordering guarantees changes:
result of obtaining pointer to the object!
case 6) - increment-based RMW ops with acquire ordering that return a value
---------------------------------------------------------------------------
Function changes:
* atomic_inc_not_zero() --> refcount_inc_not_zero_acquire()
* no atomic counterpart --> refcount_add_not_zero_acquire()
Memory ordering guarantees changes:
* fully ordered --> ACQUIRE ordering on success
case 7) - generic dec/sub decrement-based RMW ops that return a value
case 5) - generic dec/sub decrement-based RMW ops that return a value
---------------------------------------------------------------------
Function changes:
@@ -164,7 +139,7 @@ Memory ordering guarantees changes:
* fully ordered --> RELEASE ordering + ACQUIRE ordering on success
case 8) other decrement-based RMW ops that return a value
case 6) other decrement-based RMW ops that return a value
---------------------------------------------------------
Function changes:
@@ -179,7 +154,7 @@ Memory ordering guarantees changes:
.. note:: atomic_add_unless() only provides full order on success.
case 9) - lock-based RMW
case 7) - lock-based RMW
------------------------
Function changes:

26
Documentation/core-api/symbol-namespaces.rst
View File

@@ -28,9 +28,6 @@ kernel. As of today, modules that make use of symbols exported into namespaces,
are required to import the namespace. Otherwise the kernel will, depending on
its configuration, reject loading the module or warn about a missing import.
Additionally, it is possible to put symbols into a module namespace, strictly
limiting which modules are allowed to use these symbols.
2. How to define Symbol Namespaces
==================================
@@ -71,7 +68,7 @@ is to define the default namespace in the ``Makefile`` of the subsystem. E.g. to
export all symbols defined in usb-common into the namespace USB_COMMON, add a
line like this to drivers/usb/common/Makefile::
ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE='"USB_COMMON"'
ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_COMMON
That will affect all EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() statements. A
symbol exported with EXPORT_SYMBOL_NS() while this definition is present, will
@@ -82,27 +79,11 @@ A second option to define the default namespace is directly in the compilation
unit as preprocessor statement. The above example would then read::
#undef DEFAULT_SYMBOL_NAMESPACE
#define DEFAULT_SYMBOL_NAMESPACE "USB_COMMON"
#define DEFAULT_SYMBOL_NAMESPACE USB_COMMON
within the corresponding compilation unit before any EXPORT_SYMBOL macro is
used.
2.3 Using the EXPORT_SYMBOL_GPL_FOR_MODULES() macro
===================================================
Symbols exported using this macro are put into a module namespace. This
namespace cannot be imported.
The macro takes a comma separated list of module names, allowing only those
modules to access this symbol. Simple tail-globs are supported.
For example:
EXPORT_SYMBOL_GPL_FOR_MODULES(preempt_notifier_inc, "kvm,kvm-*")
will limit usage of this symbol to modules whoes name matches the given
patterns.
3. How to use Symbols exported in Namespaces
============================================
@@ -174,6 +155,3 @@ in-tree modules::
You can also run nsdeps for external module builds. A typical usage is::
$ make -C <path_to_kernel_src> M=$PWD nsdeps
Note: it will happily generate an import statement for the module namespace;
which will not work and generates build and runtime failures.

184
Documentation/dev-tools/autofdo.rst
View File

@@ -1,184 +0,0 @@
.. SPDX-License-Identifier: GPL-2.0
===================================
Using AutoFDO with the Linux kernel
===================================
This enables AutoFDO build support for the kernel when using
the Clang compiler. AutoFDO (Auto-Feedback-Directed Optimization)
is a type of profile-guided optimization (PGO) used to enhance the
performance of binary executables. It gathers information about the
frequency of execution of various code paths within a binary using
hardware sampling. This data is then used to guide the compiler's
optimization decisions, resulting in a more efficient binary. AutoFDO
is a powerful optimization technique, and data indicates that it can
significantly improve kernel performance. It's especially beneficial
for workloads affected by front-end stalls.
For AutoFDO builds, unlike non-FDO builds, the user must supply a
profile. Acquiring an AutoFDO profile can be done in several ways.
AutoFDO profiles are created by converting hardware sampling using
the "perf" tool. It is crucial that the workload used to create these
perf files is representative; they must exhibit runtime
characteristics similar to the workloads that are intended to be
optimized. Failure to do so will result in the compiler optimizing
for the wrong objective.
The AutoFDO profile often encapsulates the program's behavior. If the
performance-critical codes are architecture-independent, the profile
can be applied across platforms to achieve performance gains. For
instance, using the profile generated on Intel architecture to build
a kernel for AMD architecture can also yield performance improvements.
There are two methods for acquiring a representative profile:
(1) Sample real workloads using a production environment.
(2) Generate the profile using a representative load test.
When enabling the AutoFDO build configuration without providing an
AutoFDO profile, the compiler only modifies the dwarf information in
the kernel without impacting runtime performance. It's advisable to
use a kernel binary built with the same AutoFDO configuration to
collect the perf profile. While it's possible to use a kernel built
with different options, it may result in inferior performance.
One can collect profiles using AutoFDO build for the previous kernel.
AutoFDO employs relative line numbers to match the profiles, offering
some tolerance for source changes. This mode is commonly used in a
production environment for profile collection.
In a profile collection based on a load test, the AutoFDO collection
process consists of the following steps:
#. Initial build: The kernel is built with AutoFDO options
without a profile.
#. Profiling: The above kernel is then run with a representative
workload to gather execution frequency data. This data is
collected using hardware sampling, via perf. AutoFDO is most
effective on platforms supporting advanced PMU features like
LBR on Intel machines, ETM traces on ARM machines.
#. AutoFDO profile generation: Perf output file is converted to
the AutoFDO profile via offline tools.
The support requires a Clang compiler LLVM 17 or later.
Preparation
===========
Configure the kernel with::
CONFIG_AUTOFDO_CLANG=y
Customization
=============
The default CONFIG_AUTOFDO_CLANG setting covers kernel space objects for
AutoFDO builds. One can, however, enable or disable AutoFDO build for
individual files and directories by adding a line similar to the following
to the respective kernel Makefile:
- For enabling a single file (e.g. foo.o) ::
AUTOFDO_PROFILE_foo.o := y
- For enabling all files in one directory ::
AUTOFDO_PROFILE := y
- For disabling one file ::
AUTOFDO_PROFILE_foo.o := n
- For disabling all files in one directory ::
AUTOFDO_PROFILE := n
Workflow
========
Here is an example workflow for AutoFDO kernel:
1) Build the kernel on the host machine with LLVM enabled,
for example, ::
$ make menuconfig LLVM=1
Turn on AutoFDO build config::
CONFIG_AUTOFDO_CLANG=y
With a configuration that with LLVM enabled, use the following command::
$ scripts/config -e AUTOFDO_CLANG
After getting the config, build with ::
$ make LLVM=1
2) Install the kernel on the test machine.
3) Run the load tests. The '-c' option in perf specifies the sample
event period. We suggest using a suitable prime number, like 500009,
for this purpose.
- For Intel platforms::
$ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c <count> -o <perf_file> -- <loadtest>
- For AMD platforms:
The supported systems are: Zen3 with BRS, or Zen4 with amd_lbr_v2. To check,
For Zen3::
$ cat proc/cpuinfo | grep " brs"
For Zen4::
$ cat proc/cpuinfo | grep amd_lbr_v2
The following command generated the perf data file::
$ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a -N -b -c <count> -o <perf_file> -- <loadtest>
- For ARM platforms with ETM trace:
Follow the instructions in the `Linaro OpenCSD document
https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/auto-fdo/autofdo.md`_
to record ETM traces for AutoFDO::
$ perf record -e cs_etm/@tmc_etr0/k -a -o <etm_perf_file> -- <loadtest>
$ perf inject -i <etm_perf_file> -o <perf_file> --itrace=i500009il
For ARM platforms running Android, follow the instructions in the
`Android simpleperf document
<https://android.googlesource.com/platform/system/extras/+/main/simpleperf/doc/collect_etm_data_for_autofdo.md>`_
to record ETM traces for AutoFDO::
$ simpleperf record -e cs-etm:k -a -o <perf_file> -- <loadtest>
4) (Optional) Download the raw perf file to the host machine.
5) To generate an AutoFDO profile, two offline tools are available:
create_llvm_prof and llvm_profgen. The create_llvm_prof tool is part
of the AutoFDO project and can be found on GitHub
(https://github.com/google/autofdo), version v0.30.1 or later.
The llvm_profgen tool is included in the LLVM compiler itself. It's
important to note that the version of llvm_profgen doesn't need to match
the version of Clang. It needs to be the LLVM 19 release of Clang
or later, or just from the LLVM trunk. ::
$ llvm-profgen --kernel --binary=<vmlinux> --perfdata=<perf_file> -o <profile_file>
or ::
$ create_llvm_prof --binary=<vmlinux> --profile=<perf_file> --format=extbinary --out=<profile_file>
Note that multiple AutoFDO profile files can be merged into one via::
$ llvm-profdata merge -o <profile_file> <profile_1> <profile_2> ... <profile_n>
6) Rebuild the kernel using the AutoFDO profile file with the same config as step 1,
(Note CONFIG_AUTOFDO_CLANG needs to be enabled)::
$ make LLVM=1 CLANG_AUTOFDO_PROFILE=<profile_file>

1
Documentation/dev-tools/index.rst
View File

@@ -34,7 +34,6 @@ Documentation/dev-tools/testing-overview.rst
ktap
checkuapi
gpio-sloppy-logic-analyzer
autofdo
.. only:: subproject and html

9
Documentation/dev-tools/kunit/index.rst
View File

@@ -18,15 +18,6 @@ KUnit - Linux Kernel Unit Testing
faq
running_tips
.. warning::
AOSP only supports running tests loaded with modules. Built-in
test execution support has been disabled. In addition, in order
to fully enable running module loaded tests both CONFIG_KUNIT
needs to be enabled and kernel command line argument
`kunit.enable` needs to be set to 1.
The remaining KUnit documentation has been left as-is.
This section details the kernel unit testing framework.
Introduction

99
Documentation/device-mapper/dm-bow.txt
View File

@@ -1,99 +0,0 @@
dm_bow (backup on write)
========================
dm_bow is a device mapper driver that uses the free space on a device to back up
data that is overwritten. The changes can then be committed by a simple state
change, or rolled back by removing the dm_bow device and running a command line
utility over the underlying device.
dm_bow has three states, set by writing ‘1’ or ‘2’ to /sys/block/dm-?/bow/state.
It is only possible to go from state 0 (initial state) to state 1, and then from
state 1 to state 2.
State 0: dm_bow collects all trims to the device and assumes that these mark
free space on the overlying file system that can be safely used. Typically the
mount code would create the dm_bow device, mount the file system, call the
FITRIM ioctl on the file system then switch to state 1. These trims are not
propagated to the underlying device.
State 1: All writes to the device cause the underlying data to be backed up to
the free (trimmed) area as needed in such a way as they can be restored.
However, the writes, with one exception, then happen exactly as they would
without dm_bow, so the device is always in a good final state. The exception is
that sector 0 is used to keep a log of the latest changes, both to indicate that
we are in this state and to allow rollback. See below for all details. If there
isn't enough free space, writes are failed with -ENOSPC.
State 2: The transition to state 2 triggers replacing the special sector 0 with
the normal sector 0, and the freeing of all state information. dm_bow then
becomes a pass-through driver, allowing the device to continue to be used with
minimal performance impact.
Usage
=====
dm-bow takes one command line parameter, the name of the underlying device.
dm-bow will typically be used in the following way. dm-bow will be loaded with a
suitable underlying device and the resultant device will be mounted. A file
system trim will be issued via the FITRIM ioctl, then the device will be
switched to state 1. The file system will now be used as normal. At some point,
the changes can either be committed by switching to state 2, or rolled back by
unmounting the file system, removing the dm-bow device and running the command
line utility. Note that rebooting the device will be equivalent to unmounting
and removing, but the command line utility must still be run
Details of operation in state 1
===============================
dm_bow maintains a type for all sectors. A sector can be any of:
SECTOR0
SECTOR0_CURRENT
UNCHANGED
FREE
CHANGED
BACKUP
SECTOR0 is the first sector on the device, and is used to hold the log of
changes. This is the one exception.
SECTOR0_CURRENT is a sector picked from the FREE sectors, and is where reads and
writes from the true sector zero are redirected to. Note that like any backup
sector, if the sector is written to directly, it must be moved again.
UNCHANGED means that the sector has not been changed since we entered state 1.
Thus if it is written to or trimmed, the contents must first be backed up.
FREE means that the sector was trimmed in state 0 and has not yet been written
to or used for backup. On being written to, a FREE sector is changed to CHANGED.
CHANGED means that the sector has been modified, and can be further modified
without further backup.
BACKUP means that this is a free sector being used as a backup. On being written
to, the contents must first be backed up again.
All backup operations are logged to the first sector. The log sector has the
format:
--------------------------------------------------------
| Magic | Count | Sequence | Log entry | Log entry | …
--------------------------------------------------------
Magic is a magic number. Count is the number of log entries. Sequence is 0
initially. A log entry is
-----------------------------------
| Source | Dest | Size | Checksum |
-----------------------------------
When SECTOR0 is full, the log sector is backed up and another empty log sector
created with sequence number one higher. The first entry in any log entry with
sequence > 0 therefore must be the log of the backing up of the previous log
sector. Note that sequence is not strictly needed, but is a useful sanity check
and potentially limits the time spent trying to restore a corrupted snapshot.
On entering state 1, dm_bow has a list of free sectors. All other sectors are
unchanged. Sector0_current is selected from the free sectors and the contents of
sector 0 are copied there. The sector 0 is backed up, which triggers the first
log entry to be written.

3
Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
View File

@@ -55,7 +55,8 @@ properties:
- const: arm,primecell
reg:
maxItems: 1
minItems: 1
maxItems: 2
clocks:
maxItems: 1

3
Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
View File

@@ -41,7 +41,8 @@ properties:
- const: arm,primecell
reg:
maxItems: 1
minItems: 1
maxItems: 2
qcom,dsb-element-bits:
description:

36
Documentation/devicetree/bindings/cache/qcom,llcc.yaml vendored
View File

@@ -39,11 +39,11 @@ properties:
reg:
minItems: 2
maxItems: 10
maxItems: 9
reg-names:
minItems: 2
maxItems: 10
maxItems: 9
interrupts:
maxItems: 1
@@ -134,36 +134,6 @@ allOf:
- qcom,qdu1000-llcc
- qcom,sc8180x-llcc
- qcom,sc8280xp-llcc
then:
properties:
reg:
items:
- description: LLCC0 base register region
- description: LLCC1 base register region
- description: LLCC2 base register region
- description: LLCC3 base register region
- description: LLCC4 base register region
- description: LLCC5 base register region
- description: LLCC6 base register region
- description: LLCC7 base register region
- description: LLCC broadcast base register region
reg-names:
items:
- const: llcc0_base
- const: llcc1_base
- const: llcc2_base
- const: llcc3_base
- const: llcc4_base
- const: llcc5_base
- const: llcc6_base
- const: llcc7_base
- const: llcc_broadcast_base
- if:
properties:
compatible:
contains:
enum:
- qcom,x1e80100-llcc
then:
properties:
@@ -178,7 +148,6 @@ allOf:
- description: LLCC6 base register region
- description: LLCC7 base register region
- description: LLCC broadcast base register region
- description: LLCC broadcast AND register region
reg-names:
items:
- const: llcc0_base
@@ -190,7 +159,6 @@ allOf:
- const: llcc6_base
- const: llcc7_base
- const: llcc_broadcast_base
- const: llcc_broadcast_and_base
- if:
properties:

22
Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
View File

@@ -26,21 +26,9 @@ properties:
description:
Specifies the reference clock(s) from which the output frequency is
derived. This must either reference one clock if only the first clock
input is connected or two if both clock inputs are connected. The last
clock is the AXI bus clock that needs to be enabled so we can access the
core registers.
minItems: 2
maxItems: 3
clock-names:
oneOf:
- items:
- const: clkin1
- const: s_axi_aclk
- items:
- const: clkin1
- const: clkin2
- const: s_axi_aclk
input is connected or two if both clock inputs are connected.
minItems: 1
maxItems: 2
'#clock-cells':
const: 0
@@ -52,7 +40,6 @@ required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
additionalProperties: false
@@ -63,6 +50,5 @@ examples:
compatible = "adi,axi-clkgen-2.00.a";
#clock-cells = <0>;
reg = <0xff000000 0x1000>;
clocks = <&osc 1>, <&clkc 15>;
clock-names = "clkin1", "s_axi_aclk";
clocks = <&osc 1>;
};

1
Documentation/devicetree/bindings/clock/imx93-clock.yaml
View File

@@ -16,7 +16,6 @@ description: |
properties:
compatible:
enum:
- fsl,imx91-ccm
- fsl,imx93-ccm
reg:

53
Documentation/devicetree/bindings/connector/usb-connector.yaml
View File

@@ -253,53 +253,6 @@ properties:
additionalProperties: false
sink-wait-cap-time-ms:
description: Represents the max time in ms that USB Type-C port (in sink
role) should wait for the port partner (source role) to send source caps.
SinkWaitCap timer starts when port in sink role attaches to the source.
This timer will stop when sink receives PD source cap advertisement before
timeout in which case it'll move to capability negotiation stage. A
timeout leads to a hard reset message by the port.
minimum: 310
maximum: 620
default: 310
ps-source-off-time-ms:
description: Represents the max time in ms that a DRP in source role should
take to turn off power after the PsSourceOff timer starts. PsSourceOff
timer starts when a sink's PHY layer receives EOP of the GoodCRC message
(corresponding to an Accept message sent in response to a PR_Swap or a
FR_Swap request). This timer stops when last bit of GoodCRC EOP
corresponding to the received PS_RDY message is transmitted by the PHY
layer. A timeout shall lead to error recovery in the type-c port.
minimum: 750
maximum: 920
default: 920
cc-debounce-time-ms:
description: Represents the max time in ms that a port shall wait to
determine if it's attached to a partner.
minimum: 100
maximum: 200
default: 200
sink-bc12-completion-time-ms:
description: Represents the max time in ms that a port in sink role takes
to complete Battery Charger (BC1.2) Detection. BC1.2 detection is a
hardware mechanism, which in some TCPC implementations, can run in
parallel once the Type-C connection state machine reaches the "potential
connect as sink" state. In TCPCs where this causes delays to respond to
the incoming PD messages, sink-bc12-completion-time-ms is used to delay
PD negotiation till BC1.2 detection completes.
default: 0
pd-revision:
description: Specifies the maximum USB PD revision and version supported by
the connector. This property is specified in the following order;
<revision_major, revision_minor, version_major, version_minor>.
$ref: /schemas/types.yaml#/definitions/uint8-array
maxItems: 4
dependencies:
sink-vdos-v1: [ sink-vdos ]
sink-vdos: [ sink-vdos-v1 ]
@@ -427,7 +380,7 @@ examples:
};
# USB-C connector attached to a typec port controller(ptn5110), which has
# power delivery support, explicitly defines time properties and enables drp.
# power delivery support and enables drp.
- |
#include <dt-bindings/usb/pd.h>
typec: ptn5110 {
@@ -440,10 +393,6 @@ examples:
sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)
PDO_VAR(5000, 12000, 2000)>;
op-sink-microwatt = <10000000>;
sink-wait-cap-time-ms = <465>;
ps-source-off-time-ms = <835>;
cc-debounce-time-ms = <101>;
sink-bc12-completion-time-ms = <500>;
};
};

48
Documentation/devicetree/bindings/cpufreq/qemu,virtual-cpufreq.yaml
View File

@@ -1,48 +0,0 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/cpufreq/qemu,virtual-cpufreq.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Virtual CPUFreq
maintainers:
- David Dai <davidai@google.com>
- Saravana Kannan <saravanak@google.com>
description:
Virtual CPUFreq is a virtualized driver in guest kernels that sends performance
selection of its vCPUs as a hint to the host through MMIO regions. Each vCPU
is associated with a performance domain which can be shared with other vCPUs.
Each performance domain has its own set of registers for performance controls.
properties:
compatible:
const: qemu,virtual-cpufreq
reg:
maxItems: 1
description:
Address and size of region containing performance controls for each of the
performance domains. Regions for each performance domain is placed
contiguously and contain registers for controlling DVFS(Dynamic Frequency
and Voltage) characteristics. The size of the region is proportional to
total number of performance domains.
required:
- compatible
- reg
additionalProperties: false
examples:
- |
soc {
#address-cells = <1>;
#size-cells = <1>;
cpufreq@1040000 {
compatible = "qemu,virtual-cpufreq";
reg = <0x1040000 0x2000>;
};
};

2
Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
View File

@@ -90,7 +90,7 @@ properties:
adi,dsi-lanes:
description: Number of DSI data lanes connected to the DSI host.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 2, 3, 4 ]
enum: [ 1, 2, 3, 4 ]
"#sound-dai-cells":
const: 0

49
Documentation/devicetree/bindings/firmware/gunyah-cma-mem.yaml
View File

@@ -1,49 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/gunyah-cma-mem.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Contiguous memory allocator for Virtual Machines
maintainers:
- Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
- Elliot Berman <quic_eberman@quicinc.com>
description: |+
gunyah-cma-mem is a CMA memory manager that allows VMMs to use
contiguous memory to backup Virtual Machines running on Gunyah. These
regions are pre-defined by the firmware to have special attributes
like memory encryption.
properties:
compatible:
- const: gunyah-cma-vm-mem
memory-region:
$ref: '/schemas/types.yaml#/definitions/phandle'
items:
- description: |
Describes the specific reserved memory region that this allocator
will allocate memory from for a Virtual Machine. Refer to
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
for more information.
memory-region-names:
$ref: /schemas/types.yaml#/definitions/string-array
items:
- description: Name of the memory-region to be used by VMM for operation
required:
- compatible
- memory-region
- memory-region-names
example:
- |
gunyah-cma-mem {
compatible = "gunyah-cma-vm-mem";
memory-region = <&trust_ui_vm_mem &oem_vm_mem>;
memory-region-names = "trustedvm_cma" , "oemvm_cma";
};

82
Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
View File

@@ -1,82 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/gunyah-hypervisor.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Gunyah Hypervisor
maintainers:
- Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
- Elliot Berman <quic_eberman@quicinc.com>
description: |+
Gunyah virtual machines use this information to determine the capability IDs
of the message queues used to communicate with the Gunyah Resource Manager.
See also: https://github.com/quic/gunyah-resource-manager/blob/develop/src/vm_creation/dto_construct.c
properties:
compatible:
const: gunyah-hypervisor
"#address-cells":
description: Number of cells needed to represent 64-bit capability IDs.
const: 2
"#size-cells":
description: must be 0, because capability IDs are not memory address
ranges and do not have a size.
const: 0
patternProperties:
"^gunyah-resource-mgr(@.*)?":
type: object
description:
Resource Manager node which is required to communicate to Resource
Manager VM using Gunyah Message Queues.
properties:
compatible:
const: gunyah-resource-manager
reg:
items:
- description: Gunyah capability ID of the TX message queue
- description: Gunyah capability ID of the RX message queue
interrupts:
items:
- description: Interrupt for the TX message queue
- description: Interrupt for the RX message queue
additionalProperties: false
required:
- compatible
- reg
- interrupts
additionalProperties: false
required:
- compatible
- "#address-cells"
- "#size-cells"
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
hypervisor {
#address-cells = <2>;
#size-cells = <0>;
compatible = "gunyah-hypervisor";
gunyah-resource-mgr@0 {
compatible = "gunyah-resource-manager";
interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>, /* TX allowed IRQ */
<GIC_SPI 4 IRQ_TYPE_EDGE_RISING>; /* RX requested IRQ */
reg = <0x00000000 0x00000000>, /* TX capability ID */
<0x00000000 0x00000001>; /* RX capability ID */
};
};

34
Documentation/devicetree/bindings/firmware/mediatek,geniezone.yaml
View File

@@ -1,34 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/mediatek,geniezone.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek GenieZone hypervisor
maintainers:
- Yingshiuan Pan <yingshiuan.pan@mediatek.com>
description:
GenieZone is a proprietary type-I hypervisor firmware developed by MediaTek,
providing an isolated execution environment for mTEE (MediaTek Trusted
Execution Environment) and AVF (Android Virtualization Framework) virtual
machines. This binding facilitates the integration of GenieZone into the
Android Virtualization Framework (AVF) with Crosvm as the VMM. The driver
exposes hypervisor control interfaces to the VMM for managing virtual
machine lifecycles and assisting virtual device emulation.
properties:
compatible:
const: mediatek,geniezone
required:
- compatible
additionalProperties: false
examples:
- |
hypervisor {
compatible = "mediatek,geniezone";
};

24
Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
View File

@@ -97,10 +97,7 @@ properties:
resets:
items:
- description:
Module reset. This property is optional for controllers in Tegra194,
Tegra234 etc where an internal software reset is available as an
alternative.
- description: module reset
reset-names:
items:
@@ -119,13 +116,6 @@ properties:
- const: rx
- const: tx
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml
- if:
@@ -179,18 +169,6 @@ allOf:
properties:
power-domains: false
- if:
not:
properties:
compatible:
contains:
enum:
- nvidia,tegra194-i2c
then:
required:
- resets
- reset-names
unevaluatedProperties: false
examples:

2
Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml
View File

@@ -30,7 +30,7 @@ properties:
maxItems: 1
spi-max-frequency:
maximum: 66000000
maximum: 30000000
reset-gpios:
maxItems: 1

52
Documentation/devicetree/bindings/iommu/pkvm,pviommu.yaml
View File

@@ -1,52 +0,0 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
title: pKVM pvIOMMU
maintainers:
- Mostafa Saleh <smostafa@google.org>
description: |+
pvIOMMU is a paravirtual IOMMU implemented through arm64 hypercalls (HVC).
What distinguishes it from other paravirtual IOMMUs (virtio-iommu)
is that it has very simple transport which makes it easy for
hypervisors with a small TCB as in confidential computing to implement
it without complexity and with lower performance overhead.
pvIOMMU was initially developed for protected KVM (pKVM), but it has no
KVM specific interface, so it can be implemented by other hypervisors
also.
properties:
$nodename:
pattern: "^iommu@[0-9a-f]*"
compatible:
const: pkvm,pviommu
id:
maxItems: 1
'#iommu-cells':
enum: [ 1, 2 ]
description: |
See Documentation/devicetree/bindings/iommu/iommu.txt for details. With a
value of 1, each IOMMU specifier represents a distinct stream ID emitted
by that device into the relevant SMMU.
pvIOMMU would assume each device belongs to a different group, to describe
iommu groups, it is optionally passed in the second field of "iommus", where
devices having the same ID are part of the same group.
required:
- compatible
- id
- '#iommu-cells'
additionalProperties: false
examples:
- |+
iommu@55 {
compatible = "pkvm,pviommu";
id = <0x55>;
#iommu-cells = <1>;
};

2
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
View File

@@ -27,7 +27,7 @@ properties:
description: |
For multicolor LED support this property should be defined as either
LED_COLOR_ID_RGB or LED_COLOR_ID_MULTI which can be found in
include/dt-bindings/leds/common.h.
include/linux/leds/common.h.
enum: [ 8, 9 ]
required:

2
Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml
View File

@@ -71,7 +71,7 @@ properties:
description:
Any lane can be inverted or not.
minItems: 1
maxItems: 3
maxItems: 2
required:
- data-lanes

20
Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml
View File

@@ -50,15 +50,15 @@ properties:
minimum: 0
maximum: 1
rohm,charger-sense-resistor-micro-ohms:
minimum: 10000
maximum: 50000
rohm,charger-sense-resistor-ohms:
minimum: 10000000
maximum: 50000000
description: |
BD71815 has SAR ADC for measuring charging currents. External sense
resistor (RSENSE in data sheet) should be used. If something other
but a 30 mOhm resistor is used the resistance value should be given
here in micro Ohms.
default: 30000
BD71827 and BD71828 have SAR ADC for measuring charging currents.
External sense resistor (RSENSE in data sheet) should be used. If
something other but 30MOhm resistor is used the resistance value
should be given here in Ohms.
default: 30000000
regulators:
$ref: /schemas/regulator/rohm,bd71815-regulator.yaml
@@ -67,7 +67,7 @@ properties:
gpio-reserved-ranges:
description: |
Usage of BD71815 GPIO pins can be changed via OTP. This property can be
Usage of BD71828 GPIO pins can be changed via OTP. This property can be
used to mark the pins which should not be configured for GPIO. Please see
the ../gpio/gpio.txt for more information.
@@ -113,7 +113,7 @@ examples:
gpio-controller;
#gpio-cells = <2>;
rohm,charger-sense-resistor-micro-ohms = <10000>;
rohm,charger-sense-resistor-ohms = <10000000>;
regulators {
buck1: buck1 {

2
Documentation/devicetree/bindings/mmc/mmc-controller.yaml
View File

@@ -25,7 +25,7 @@ properties:
"#address-cells":
const: 1
description: |
The cell is the SDIO function number if a function subnode is used.
The cell is the slot ID if a function subnode is used.
"#size-cells":
const: 0

2
Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
View File

@@ -170,7 +170,7 @@ allOf:
const: renesas,r8a779h0-canfd
then:
patternProperties:
"^channel[4-7]$": false
"^channel[5-7]$": false
else:
if:
not:

7
Documentation/devicetree/bindings/net/fsl,fec.yaml
View File

@@ -183,13 +183,6 @@ properties:
description:
Register bits of stop mode control, the format is <&gpr req_gpr req_bit>.
fsl,pps-channel:
$ref: /schemas/types.yaml#/definitions/uint32
default: 0
description:
Specifies to which timer instance the PPS signal is routed.
enum: [0, 1, 2, 3]
mdio:
$ref: mdio.yaml#
unevaluatedProperties: false

5
Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
View File

@@ -149,7 +149,7 @@ allOf:
then:
properties:
clocks:
minItems: 6
minItems: 4
clock-names:
items:
@@ -178,7 +178,7 @@ allOf:
then:
properties:
clocks:
minItems: 6
minItems: 4
clock-names:
items:
@@ -207,7 +207,6 @@ allOf:
properties:
clocks:
minItems: 4
maxItems: 4
clock-names:
items:

3
Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
View File

@@ -58,7 +58,8 @@ properties:
fsl,phy-tx-vboost-level-microvolt:
description:
Adjust the boosted transmit launch pk-pk differential amplitude
enum: [844, 1008, 1156]
minimum: 880
maximum: 1120
fsl,phy-comp-dis-tune-percent:
description:

19
Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
View File

@@ -91,17 +91,14 @@ allOf:
- if:
properties:
compatible:
oneOf:
# Match without "contains", to skip newer variants which are still
# compatible with samsung,exynos7-wakeup-eint
- enum:
- samsung,exynos4210-wakeup-eint
- samsung,exynos7-wakeup-eint
- samsung,s5pv210-wakeup-eint
- contains:
enum:
- samsung,exynos5433-wakeup-eint
- samsung,exynos7885-wakeup-eint
# Match without "contains", to skip newer variants which are still
# compatible with samsung,exynos7-wakeup-eint
enum:
- samsung,s5pv210-wakeup-eint
- samsung,exynos4210-wakeup-eint
- samsung,exynos5433-wakeup-eint
- samsung,exynos7-wakeup-eint
- samsung,exynos7885-wakeup-eint
then:
properties:
interrupts:

21
Documentation/devicetree/bindings/pwm/adi,axi-pwmgen.yaml
View File

@@ -27,31 +27,22 @@ properties:
maxItems: 1
"#pwm-cells":
const: 3
const: 2
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: axi
- const: ext
maxItems: 1
required:
- reg
- clocks
- clock-names
unevaluatedProperties: false
examples:
- |
pwm@44b00000 {
compatible = "adi,axi-pwmgen-2.00.a";
reg = <0x44b00000 0x1000>;
clocks = <&fpga_clk>, <&spi_clk>;
clock-names = "axi", "ext";
#pwm-cells = <3>;
compatible = "adi,axi-pwmgen-2.00.a";
reg = <0x44b00000 0x1000>;
clocks = <&spi_clk>;
#pwm-cells = <2>;
};

8
Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml
View File

@@ -35,8 +35,8 @@ additionalProperties: false
examples:
- |
pwm: pwm@f0408000 {
compatible = "brcm,bcm7038-pwm";
reg = <0xf0408000 0x28>;
#pwm-cells = <2>;
clocks = <&upg_fixed>;
compatible = "brcm,bcm7038-pwm";
reg = <0xf0408000 0x28>;
#pwm-cells = <2>;
clocks = <&upg_fixed>;
};

8
Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml
View File

@@ -43,9 +43,9 @@ examples:
#include <dt-bindings/clock/bcm281xx.h>
pwm@3e01a000 {
compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
reg = <0x3e01a000 0xcc>;
clocks = <&slave_ccu BCM281XX_SLAVE_CCU_PWM>;
#pwm-cells = <3>;
compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
reg = <0x3e01a000 0xcc>;
clocks = <&slave_ccu BCM281XX_SLAVE_CCU_PWM>;
#pwm-cells = <3>;
};
...

12
Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml
View File

@@ -33,7 +33,7 @@ patternProperties:
"^ldo-v(camio18|aud28|aux18|io18|io28|rf12|rf18|cn18|cn28|fe28)$":
type: object
$ref: regulator.yaml#
$ref: fixed-regulator.yaml#
unevaluatedProperties: false
description:
Properties for single fixed LDO regulator.
@@ -112,6 +112,7 @@ examples:
regulator-enable-ramp-delay = <220>;
};
mt6357_vfe28_reg: ldo-vfe28 {
compatible = "regulator-fixed";
regulator-name = "vfe28";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
@@ -124,12 +125,14 @@ examples:
regulator-enable-ramp-delay = <110>;
};
mt6357_vrf18_reg: ldo-vrf18 {
compatible = "regulator-fixed";
regulator-name = "vrf18";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-enable-ramp-delay = <110>;
};
mt6357_vrf12_reg: ldo-vrf12 {
compatible = "regulator-fixed";
regulator-name = "vrf12";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
@@ -154,12 +157,14 @@ examples:
regulator-enable-ramp-delay = <264>;
};
mt6357_vcn28_reg: ldo-vcn28 {
compatible = "regulator-fixed";
regulator-name = "vcn28";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-enable-ramp-delay = <264>;
};
mt6357_vcn18_reg: ldo-vcn18 {
compatible = "regulator-fixed";
regulator-name = "vcn18";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
@@ -178,6 +183,7 @@ examples:
regulator-enable-ramp-delay = <264>;
};
mt6357_vcamio_reg: ldo-vcamio18 {
compatible = "regulator-fixed";
regulator-name = "vcamio";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
@@ -206,24 +212,28 @@ examples:
regulator-always-on;
};
mt6357_vaux18_reg: ldo-vaux18 {
compatible = "regulator-fixed";
regulator-name = "vaux18";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-enable-ramp-delay = <264>;
};
mt6357_vaud28_reg: ldo-vaud28 {
compatible = "regulator-fixed";
regulator-name = "vaud28";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-enable-ramp-delay = <264>;
};
mt6357_vio28_reg: ldo-vio28 {
compatible = "regulator-fixed";
regulator-name = "vio28";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-enable-ramp-delay = <264>;
};
mt6357_vio18_reg: ldo-vio18 {
compatible = "regulator-fixed";
regulator-name = "vio18";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;

6
Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
View File

@@ -35,6 +35,10 @@ properties:
$ref: regulator.yaml#
unevaluatedProperties: false
properties:
regulator-compatible:
pattern: "^vbuck[1-4]$"
additionalProperties: false
required:
@@ -52,6 +56,7 @@ examples:
regulators {
vbuck1 {
regulator-compatible = "vbuck1";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1193750>;
regulator-enable-ramp-delay = <256>;
@@ -59,6 +64,7 @@ examples:
};
vbuck3 {
regulator-compatible = "vbuck3";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1193750>;
regulator-enable-ramp-delay = <256>;

2
Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
View File

@@ -22,7 +22,7 @@ description:
Each sub-node is identified using the node's name, with valid values listed
for each of the pmics below.
For mp5496, s1, s2, l2, l5
For mp5496, s1, s2
For pm2250, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22

2
Documentation/devicetree/bindings/serial/8250.yaml
View File

@@ -45,7 +45,7 @@ allOf:
- ns16550
- ns16550a
then:
oneOf:
anyOf:
- required: [ clock-frequency ]
- required: [ clocks ]

19
Documentation/devicetree/bindings/serial/rs485.yaml
View File

@@ -18,15 +18,16 @@ properties:
description: prop-encoded-array <a b>
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- description: Delay between rts signal and beginning of data sent in
milliseconds. It corresponds to the delay before sending data.
default: 0
maximum: 100
- description: Delay between end of data sent and rts signal in milliseconds.
It corresponds to the delay after sending data and actual release
of the line.
default: 0
maximum: 100
items:
- description: Delay between rts signal and beginning of data sent in
milliseconds. It corresponds to the delay before sending data.
default: 0
maximum: 100
- description: Delay between end of data sent and rts signal in milliseconds.
It corresponds to the delay after sending data and actual release
of the line.
default: 0
maximum: 100
rs485-rts-active-high:
description: drive RTS high when sending (this is the default).

2
Documentation/devicetree/bindings/soc/fsl/fsl,ls1028a-reset.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale Layerscape Reset Registers Module
maintainers:
- Frank Li <Frank.Li@nxp.com>
- Frank Li
description:
Reset Module includes chip reset, service processor control and Reset Control

4
Documentation/devicetree/bindings/soc/fsl/fsl,qman-fqd.yaml
View File

@@ -50,7 +50,7 @@ required:
- compatible
allOf:
- $ref: /schemas/reserved-memory/reserved-memory.yaml
- $ref: reserved-memory.yaml
unevaluatedProperties: false
@@ -61,7 +61,7 @@ examples:
#size-cells = <2>;
qman-fqd {
compatible = "fsl,qman-fqd";
compatible = "shared-dma-pool";
size = <0 0x400000>;
alignment = <0 0x400000>;
no-map;

10
Documentation/devicetree/bindings/sound/mt6359.yaml
View File

@@ -23,8 +23,8 @@ properties:
Indicates how many data pins are used to transmit two channels of PDM
signal. 0 means two wires, 1 means one wire. Default value is 0.
enum:
- 0 # two wires
- 1 # one wire
- 0 # one wire
- 1 # two wires
mediatek,mic-type-0:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -53,9 +53,9 @@ additionalProperties: false
examples:
- |
mt6359codec: audio-codec {
mediatek,dmic-mode = <0>;
mediatek,mic-type-0 = <2>;
mt6359codec: mt6359codec {
mediatek,dmic-mode = <0>;
mediatek,mic-type-0 = <2>;
};
...

2
Documentation/devicetree/bindings/sound/realtek,rt5645.yaml
View File

@@ -51,7 +51,7 @@ properties:
description: Power supply for AVDD, providing 1.8V.
cpvdd-supply:
description: Power supply for CPVDD, providing 1.8V.
description: Power supply for CPVDD, providing 3.5V.
hp-detect-gpios:
description:

6
Documentation/devicetree/bindings/sram/sram.yaml
View File

@@ -101,12 +101,6 @@ patternProperties:
IO mem address range, relative to the SRAM range.
maxItems: 1
reg-io-width:
description:
The size (in bytes) of the IO accesses that should be performed on the
SRAM.
enum: [1, 2, 4, 8]
pool:
description:
Indicates that the particular reserved SRAM area is addressable

19
Documentation/devicetree/bindings/usb/cypress,hx3.yaml
View File

@@ -14,22 +14,9 @@ allOf:
properties:
compatible:
oneOf:
- enum:
- usb4b4,6504
- usb4b4,6506
- items:
- enum:
- usb4b4,6500
- usb4b4,6508
- const: usb4b4,6504
- items:
- enum:
- usb4b4,6502
- usb4b4,6503
- usb4b4,6507
- usb4b4,650a
- const: usb4b4,6506
enum:
- usb4b4,6504
- usb4b4,6506
reg: true

2
Documentation/devicetree/bindings/usb/maxim,max33359.yaml
View File

@@ -69,8 +69,6 @@ examples:
PDO_FIXED_DATA_SWAP |
PDO_FIXED_DUAL_ROLE)
PDO_FIXED(9000, 2000, 0)>;
sink-bc12-completion-time-ms = <500>;
pd-revision = /bits/ 8 <0x03 0x01 0x01 0x08>;
};
};
};

6
Documentation/devicetree/bindings/vendor-prefixes.yaml
View File

@@ -581,8 +581,6 @@ patternProperties:
description: GlobalTop Technology, Inc.
"^gmt,.*":
description: Global Mixed-mode Technology, Inc.
"^gocontroll,.*":
description: GOcontroll Modular Embedded Electronics B.V.
"^goldelico,.*":
description: Golden Delicious Computers GmbH & Co. KG
"^goodix,.*":
@@ -846,8 +844,6 @@ patternProperties:
description: Linux-specific binding
"^linx,.*":
description: Linx Technologies
"^liontron,.*":
description: Shenzhen Liontron Technology Co., Ltd
"^liteon,.*":
description: LITE-ON Technology Corp.
"^litex,.*":
@@ -1017,8 +1013,6 @@ patternProperties:
description: Shanghai Neardi Technology Co., Ltd.
"^nec,.*":
description: NEC LCD Technologies, Ltd.
"^neofidelity,.*":
description: Neofidelity Inc.
"^neonode,.*":
description: Neonode Inc.
"^netgear,.*":

9
Documentation/driver-api/crypto/iaa/iaa-crypto.rst
View File

@@ -272,7 +272,7 @@ The available attributes are:
echo async_irq > /sys/bus/dsa/drivers/crypto/sync_mode
Async mode without interrupts (caller must poll) can be enabled by
writing 'async' to it (please see Caveat)::
writing 'async' to it::
echo async > /sys/bus/dsa/drivers/crypto/sync_mode
@@ -283,13 +283,6 @@ The available attributes are:
The default mode is 'sync'.
Caveat: since the only mechanism that iaa_crypto currently implements
for async polling without interrupts is via the 'sync' mode as
described earlier, writing 'async' to
'/sys/bus/dsa/drivers/crypto/sync_mode' will internally enable the
'sync' mode. This is to ensure correct iaa_crypto behavior until true
async polling without interrupts is enabled in iaa_crypto.
.. _iaa_default_config:
IAA Default Configuration

23
Documentation/driver-api/vfio.rst
View File

@@ -670,29 +670,6 @@ This implementation has some specifics:
-------------------------------------------------------------------------------
pvIOMMU implementation note
-------------------------------
1) pKVM provides mutual distrust between host kernel and protected VMs(pVM)
One solution to provide DMA isolation in this model, is to move the IOMMU
control to the hypervisor and para-virtualize the IOMMU interface for
the host and guest kernels. (none of them have direct access to IOMMU
programming interface).
2) In the case of device assignment, the host can't map memory for the
guest kernel in the IOMMU (as it is not trusted).
3) To statify these requirements a new VFIO IOMMU container type is added
VFIO_PKVM_IOMMU which attaches the device to a blocking domain, and
denies any MAP_DMA/UNMAP_DMA IOCTLs.
4) The guest IOMMU is configured by the host (virtual toplogy) but the mappings
are controlled by the guest, you can find more about this in:
- Documentation/virt/kvm/devices/vfio.rst
- Documentation/virt/kvm/arm/pviommu.rst
So, a new container type is added: `VFIO_PKVM_IOMMU`
-------------------------------------------------------------------------------
.. [1] VFIO was originally an acronym for "Virtual Function I/O" in its
initial implementation by Tom Lyon while as Cisco. We've since
outgrown the acronym, but it's catchy.

1
Documentation/filesystems/erofs.rst
View File

@@ -128,7 +128,6 @@ device=%s Specify a path to an extra device to be used together.
fsid=%s Specify a filesystem image ID for Fscache back-end.
domain_id=%s Specify a domain ID in fscache mode so that different images
with the same blobs under a given domain ID can share storage.
fsoffset=%llu Specify block-aligned filesystem offset for the primary device.
=================== =========================================================
Sysfs Entries

66
Documentation/filesystems/f2fs.rst
View File

@@ -206,7 +206,6 @@ fault_type=%d Support configuring fault injection type, should be
FAULT_BLKADDR_VALIDITY 0x000040000
FAULT_BLKADDR_CONSISTENCE 0x000080000
FAULT_NO_SEGMENT 0x000100000
FAULT_INCONSISTENT_FOOTER 0x000200000
=========================== ===========
mode=%s Control block allocation mode which supports "adaptive"
and "lfs". In "lfs" mode, there should be no random
@@ -366,27 +365,6 @@ errors=%s Specify f2fs behavior on critical errors. This supports modes:
pending node write drop keep N/A
pending meta write keep keep N/A
====================== =============== =============== ========
nat_bits Enable nat_bits feature to enhance full/empty nat blocks access,
by default it's disabled.
lookup_mode=%s Control the directory lookup behavior for casefolded
directories. This option has no effect on directories
that do not have the casefold feature enabled.
================== ========================================
Value Description
================== ========================================
perf (Default) Enforces a hash-only lookup.
The linear search fallback is always
disabled, ignoring the on-disk flag.
compat Enables the linear search fallback for
compatibility with directory entries
created by older kernel that used a
different case-folding algorithm.
This mode ignores the on-disk flag.
auto F2FS determines the mode based on the
on-disk `SB_ENC_NO_COMPAT_FALLBACK_FL`
flag.
================== ========================================
======================== ============================================================
Debugfs Entries
@@ -965,47 +943,3 @@ NVMe Zoned Namespace devices
can start before the zone-capacity and span across zone-capacity boundary.
Such spanning segments are also considered as usable segments. All blocks
past the zone-capacity are considered unusable in these segments.
Device aliasing feature
-----------------------
f2fs can utilize a special file called a "device aliasing file." This file allows
the entire storage device to be mapped with a single, large extent, not using
the usual f2fs node structures. This mapped area is pinned and primarily intended
for holding the space.
Essentially, this mechanism allows a portion of the f2fs area to be temporarily
reserved and used by another filesystem or for different purposes. Once that
external usage is complete, the device aliasing file can be deleted, releasing
the reserved space back to F2FS for its own use.
<use-case>
# ls /dev/vd*
/dev/vdb (32GB) /dev/vdc (32GB)
# mkfs.ext4 /dev/vdc
# mkfs.f2fs -c /dev/vdc@vdc.file /dev/vdb
# mount /dev/vdb /mnt/f2fs
# ls -l /mnt/f2fs
vdc.file
# df -h
/dev/vdb 64G 33G 32G 52% /mnt/f2fs
# mount -o loop /dev/vdc /mnt/ext4
# df -h
/dev/vdb 64G 33G 32G 52% /mnt/f2fs
/dev/loop7 32G 24K 30G 1% /mnt/ext4
# umount /mnt/ext4
# f2fs_io getflags /mnt/f2fs/vdc.file
get a flag on /mnt/f2fs/vdc.file ret=0, flags=nocow(pinned),immutable
# f2fs_io setflags noimmutable /mnt/f2fs/vdc.file
get a flag on noimmutable ret=0, flags=800010
set a flag on /mnt/f2fs/vdc.file ret=0, flags=noimmutable
# rm /mnt/f2fs/vdc.file
# df -h
/dev/vdb 64G 753M 64G 2% /mnt/f2fs
So, the key idea is, user can do any file operations on /dev/vdc, and
reclaim the space after the use, while the space is counted as /data.
That doesn't require modifying partition size and filesystem format.

85
Documentation/filesystems/incfs.rst
View File

@@ -1,85 +0,0 @@
.. SPDX-License-Identifier: GPL-2.0
=================================================
incfs: A stacked incremental filesystem for Linux
=================================================
/sys/fs interface
=================
Please update Documentation/ABI/testing/sysfs-fs-incfs if you update this
section.
incfs creates the following files in /sys/fs.
Features
--------
/sys/fs/incremental-fs/features/corefs
Reads 'supported'. Always present.
/sys/fs/incremental-fs/features/v2
Reads 'supported'. Present if all v2 features of incfs are supported. These
are:
fs-verity support
inotify support
ioclts:
INCFS_IOC_SET_READ_TIMEOUTS
INCFS_IOC_GET_READ_TIMEOUTS
INCFS_IOC_GET_BLOCK_COUNT
INCFS_IOC_CREATE_MAPPED_FILE
.incomplete folder
.blocks_written pseudo file
report_uid mount option
/sys/fs/incremental-fs/features/zstd
Reads 'supported'. Present if zstd compression is supported for data blocks.
/sys/fs/incremental-fs/features/bugfix_throttling
Reads 'supported'. Present if the throttling lock bug is fixed
Optional per mount
------------------
For each incfs mount, the mount option sysfs_name=[name] creates a /sys/fs
node called:
/sys/fs/incremental-fs/instances/[name]
This will contain the following files:
/sys/fs/incremental-fs/instances/[name]/reads_delayed_min
Returns a count of the number of reads that were delayed as a result of the
per UID read timeouts min time setting.
/sys/fs/incremental-fs/instances/[name]/reads_delayed_min_us
Returns total delay time for all files since first mount as a result of the
per UID read timeouts min time setting.
/sys/fs/incremental-fs/instances/[name]/reads_delayed_pending
Returns a count of the number of reads that were delayed as a result of
waiting for a pending read.
/sys/fs/incremental-fs/instances/[name]/reads_delayed_pending_us
Returns total delay time for all files since first mount as a result of
waiting for a pending read.
/sys/fs/incremental-fs/instances/[name]/reads_failed_hash_verification
Returns number of reads that failed because of hash verification failures.
/sys/fs/incremental-fs/instances/[name]/reads_failed_other
Returns number of reads that failed for reasons other than timing out or
hash failures.
/sys/fs/incremental-fs/instances/[name]/reads_failed_timed_out
Returns number of reads that timed out.
For reads_delayed_*** settings, note that a file can count for both
reads_delayed_min and reads_delayed_pending if incfs first waits for a pending
read then has to wait further for the min time. In that case, the time spent
waiting is split between reads_delayed_pending_us, which is increased by the
time spent waiting for the pending read, and reads_delayed_min_us, which is
increased by the remainder of the time spent waiting.
Reads that timed out are not added to the reads_delayed_pending or the
reads_delayed_pending_us counters.

3
Documentation/filesystems/mount_api.rst
View File

@@ -770,8 +770,7 @@ process the parameters it is given.
* ::
bool fs_validate_description(const char *name,
const struct fs_parameter_description *desc);
bool fs_validate_description(const struct fs_parameter_description *desc);
This performs some validation checks on a parameter description. It
returns true if the description is good and false if it is not. It will

2
Documentation/filesystems/overlayfs.rst
View File

@@ -204,7 +204,7 @@ handle it in two different ways:
1. return EXDEV error: this error is returned by rename(2) when trying to
move a file or directory across filesystem boundaries. Hence
applications are usually prepared to hande this error (mv(1) for example
applications are usually prepared to handle this error (mv(1) for example
recursively copies the directory tree). This is the default behavior.
2. If the "redirect_dir" feature is enabled, then the directory will be

26
Documentation/firmware-guide/acpi/dsd/data-node-references.rst
View File

@@ -12,14 +12,11 @@ ACPI in general allows referring to device objects in the tree only.
Hierarchical data extension nodes may not be referred to directly, hence this
document defines a scheme to implement such references.
A reference to a _DSD hierarchical data node is a string consisting of a
device object reference followed by a dot (".") and a relative path to a data
node object. Do not use non-string references as this will produce a copy of
the hierarchical data node, not a reference!
The hierarchical data extension node which is referred to shall be located
directly under its parent object i.e. either the device object or another
hierarchical data extension node [dsd-guide].
A reference consist of the device object name followed by one or more
hierarchical data extension [dsd-guide] keys. Specifically, the hierarchical
data extension node which is referred to by the key shall lie directly under
the parent object i.e. either the device object or another hierarchical data
extension node.
The keys in the hierarchical data nodes shall consist of the name of the node,
"@" character and the number of the node in hexadecimal notation (without pre-
@@ -36,9 +33,11 @@ extension key.
Example
=======
In the ASL snippet below, the "reference" _DSD property contains a string
reference to a hierarchical data extension node ANOD under DEV0 under the parent
of DEV1. ANOD is also the final target node of the reference.
In the ASL snippet below, the "reference" _DSD property contains a
device object reference to DEV0 and under that device object, a
hierarchical data extension key "node@1" referring to the NOD1 object
and lastly, a hierarchical data extension key "anothernode" referring to
the ANOD object which is also the final target node of the reference.
::
Device (DEV0)
@@ -77,7 +76,10 @@ of DEV1. ANOD is also the final target node of the reference.
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reference", "^DEV0.ANOD" }
Package () {
"reference", Package () {
^DEV0, "node@1", "anothernode"
}
},
}
})

11
Documentation/firmware-guide/acpi/dsd/graph.rst
View File

@@ -66,9 +66,12 @@ of that port shall be zero. Similarly, if a port may only have a single
endpoint, the number of that endpoint shall be zero.
The endpoint reference uses property extension with "remote-endpoint" property
name followed by a string reference in the same package. [data-node-ref]::
name followed by a reference in the same package. Such references consist of
the remote device reference, the first package entry of the port data extension
reference under the device and finally the first package entry of the endpoint
data extension reference under the port. Individual references thus appear as::
"device.datanode"
Package() { device, "port@X", "endpoint@Y" }
In the above example, "X" is the number of the port and "Y" is the number of
the endpoint.
@@ -106,7 +109,7 @@ A simple example of this is show below::
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0 },
Package () { "remote-endpoint", "\\_SB.PCI0.ISP.EP40" },
Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } },
}
})
}
@@ -138,7 +141,7 @@ A simple example of this is show below::
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0 },
Package () { "remote-endpoint", "\\_SB.PCI0.I2C2.CAM0.EP00" },
Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } },
}
})
}

7
Documentation/firmware-guide/acpi/dsd/leds.rst
View File

@@ -15,6 +15,11 @@ Referring to LEDs in Device tree is documented in [video-interfaces], in
"flash-leds" property documentation. In short, LEDs are directly referred to by
using phandles.
While Device tree allows referring to any node in the tree [devicetree], in
ACPI references are limited to device nodes only [acpi]. For this reason using
the same mechanism on ACPI is not possible. A mechanism to refer to non-device
ACPI nodes is documented in [data-node-ref].
ACPI allows (as does DT) using integer arguments after the reference. A
combination of the LED driver device reference and an integer argument,
referring to the "reg" property of the relevant LED, is used to identify
@@ -69,7 +74,7 @@ omitted. ::
Package () {
Package () {
"flash-leds",
Package () { "^LED.LED0", "^LED.LED1" },
Package () { ^LED, "led@0", ^LED, "led@1" },
}
}
})

3
Documentation/gpu/drm-kms-helpers.rst
View File

@@ -230,9 +230,6 @@ Panel Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
:export:
.. kernel-doc:: drivers/gpu/drm/drm_panel_backlight_quirks.c
:export:
Panel Self Refresh Helper Reference
===================================

1
Documentation/gpu/xe/index.rst
View File

@@ -16,7 +16,6 @@ DG2, etc is provided to prototype the driver.
xe_migrate
xe_cs
xe_pm
xe_gt_freq
xe_pcode
xe_gt_mcr
xe_wa

14
Documentation/gpu/xe/xe_gt_freq.rst
View File

@@ -1,14 +0,0 @@
.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
==========================
Xe GT Frequency Management
==========================
.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_freq.c
:doc: Xe GT Frequency Management
Internal API
============
.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_freq.c
:internal:

14
Documentation/hwmon/dell-smm-hwmon.rst
View File

@@ -32,12 +32,12 @@ Temperature sensors and fans can be queried and set via the standard
=============================== ======= =======================================
Name Perm Description
=============================== ======= =======================================
fan[1-4]_input RO Fan speed in RPM.
fan[1-4]_label RO Fan label.
fan[1-4]_min RO Minimal Fan speed in RPM
fan[1-4]_max RO Maximal Fan speed in RPM
fan[1-4]_target RO Expected Fan speed in RPM
pwm[1-4] RW Control the fan PWM duty-cycle.
fan[1-3]_input RO Fan speed in RPM.
fan[1-3]_label RO Fan label.
fan[1-3]_min RO Minimal Fan speed in RPM
fan[1-3]_max RO Maximal Fan speed in RPM
fan[1-3]_target RO Expected Fan speed in RPM
pwm[1-3] RW Control the fan PWM duty-cycle.
pwm1_enable WO Enable or disable automatic BIOS fan
control (not supported on all laptops,
see below for details).
@@ -93,7 +93,7 @@ Again, when you find new codes, we'd be happy to have your patches!
---------------------------
The driver also exports the fans as thermal cooling devices with
``type`` set to ``dell-smm-fan[1-4]``. This allows for easy fan control
``type`` set to ``dell-smm-fan[1-3]``. This allows for easy fan control
using one of the thermal governors.
Module parameters

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