linuxmsm/laptops-kernel
0
0 Fork 0
mirror of https://github.com/linux-msm/laptops-kernel.git synced 2026-08-13 14:19:53 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge drm/drm-next into drm-misc-next

Browse Source 
Backmerging to get fixes and features of v6.18-rc2.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
This commit is contained in:
Thomas Zimmermann committed 2025-10-24 14:45:08 +02:00
2 parents 57fe8285dc 098456f314
commit 5efbe8ff98
593 files changed
+8484 -4314
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

.mailmap
+1
View File
@@ -228,6 +228,7 @@ Dmitry Safonov <0x7f454c46@gmail.com> <dima@arista.com>
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
Domen Puncer <domen@coderock.org>
Dong Aisheng <aisheng.dong@nxp.com> <b29396@freescale.com>
Douglas Gilbert <dougg@torque.net>
Drew Fustini <fustini@kernel.org> <drew@pdp7.com>
<duje@dujemihanovic.xyz> <duje.mihanovic@skole.hr>
Documentation/devicetree/bindings/i2c/apm,xgene-slimpro-i2c.yaml
+36
View File
@@ -0,0 +1,36 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/apm,xgene-slimpro-i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: APM X-Gene SLIMpro Mailbox I2C
maintainers:
- Khuong Dinh <khuong@os.amperecomputing.com>
description:
An I2C controller accessed over the "SLIMpro" mailbox.
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
const: apm,xgene-slimpro-i2c
mboxes:
maxItems: 1
required:
- compatible
- mboxes
unevaluatedProperties: false
examples:
- |
i2c {
compatible = "apm,xgene-slimpro-i2c";
mboxes = <&mailbox 0>;
};
Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
-15
View File
@@ -1,15 +0,0 @@
APM X-Gene SLIMpro Mailbox I2C Driver
An I2C controller accessed over the "SLIMpro" mailbox.
Required properties :
- compatible : should be "apm,xgene-slimpro-i2c"
- mboxes : use the label reference for the mailbox as the first parameter.
The second parameter is the channel number.
Example :
i2cslimpro {
compatible = "apm,xgene-slimpro-i2c";
mboxes = <&mailbox 0>;
};
Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml
+1
View File
@@ -79,6 +79,7 @@ properties:
- fsl,imx-audio-nau8822
- fsl,imx-audio-sgtl5000
- fsl,imx-audio-si476x
- fsl,imx-audio-tlv320
- fsl,imx-audio-tlv320aic31xx
- fsl,imx-audio-tlv320aic32x4
- fsl,imx-audio-wm8524
Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
+1
View File
@@ -33,6 +33,7 @@ properties:
- qcom,apq8096-sndcard
- qcom,glymur-sndcard
- qcom,qcm6490-idp-sndcard
- qcom,qcs615-sndcard
- qcom,qcs6490-rb3gen2-sndcard
- qcom,qcs8275-sndcard
- qcom,qcs9075-sndcard
Documentation/devicetree/bindings/sound/ti,tas2781.yaml
+37 -6
View File
@@ -24,10 +24,10 @@ description: |
Instruments Smart Amp speaker protection algorithm. The
integrated speaker voltage and current sense provides for real time
monitoring of loudspeaker behavior.
The TAS5825/TAS5827 is a stereo, digital input Class-D audio
amplifier optimized for efficiently driving high peak power into
small loudspeakers. An integrated on-chip DSP supports Texas
Instruments Smart Amp speaker protection algorithm.
The TAS5802/TAS5815/TAS5825/TAS5827/TAS5828 is a stereo, digital input
Class-D audio amplifier optimized for efficiently driving high peak
power into small loudspeakers. An integrated on-chip DSP supports
Texas Instruments Smart Amp speaker protection algorithm.
Specifications about the audio amplifier can be found at:
https://www.ti.com/lit/gpn/tas2120
@@ -35,8 +35,10 @@ description: |
https://www.ti.com/lit/gpn/tas2563
https://www.ti.com/lit/gpn/tas2572
https://www.ti.com/lit/gpn/tas2781
https://www.ti.com/lit/gpn/tas5815
https://www.ti.com/lit/gpn/tas5825m
https://www.ti.com/lit/gpn/tas5827
https://www.ti.com/lit/gpn/tas5828m
properties:
compatible:
@@ -65,11 +67,21 @@ properties:
Protection and Audio Processing, 16/20/24/32bit stereo I2S or
multichannel TDM.
ti,tas5802: 22-W, Inductor-Less, Digital Input, Closed-Loop Class-D
Audio Amplifier with 96-Khz Extended Processing and Low Idle Power
Dissipation.
ti,tas5815: 30-W, Digital Input, Stereo, Closed-loop Class-D Audio
Amplifier with 96 kHz Enhanced Processing
ti,tas5825: 38-W Stereo, Inductor-Less, Digital Input, Closed-Loop 4.5V
to 26.4V Class-D Audio Amplifier with 192-kHz Extended Audio Processing.
ti,tas5827: 47-W Stereo, Digital Input, High Efficiency Closed-Loop Class-D
Amplifier with Class-H Algorithm
ti,tas5827: 47-W Stereo, Digital Input, High Efficiency Closed-Loop
Class-D Amplifier with Class-H Algorithm
ti,tas5828: 50-W Stereo, Digital Input, High Efficiency Closed-Loop
Class-D Amplifier with Hybrid-Pro Algorithm
oneOf:
- items:
- enum:
@@ -80,8 +92,11 @@ properties:
- ti,tas2563
- ti,tas2570
- ti,tas2572
- ti,tas5802
- ti,tas5815
- ti,tas5825
- ti,tas5827
- ti,tas5828
- const: ti,tas2781
- enum:
- ti,tas2781
@@ -177,12 +192,28 @@ allOf:
minimum: 0x38
maximum: 0x3f
- if:
properties:
compatible:
contains:
enum:
- ti,tas5802
- ti,tas5815
then:
properties:
reg:
maxItems: 4
items:
minimum: 0x54
maximum: 0x57
- if:
properties:
compatible:
contains:
enum:
- ti,tas5827
- ti,tas5828
then:
properties:
reg:
Documentation/filesystems/ext4/directory.rst
+31 -30
View File
@@ -183,10 +183,10 @@ in the place where the name normally goes. The structure is
- det_checksum
- Directory leaf block checksum.
The leaf directory block checksum is calculated against the FS UUID, the
directory's inode number, the directory's inode generation number, and
the entire directory entry block up to (but not including) the fake
directory entry.
The leaf directory block checksum is calculated against the FS UUID (or
the checksum seed, if that feature is enabled for the fs), the directory's
inode number, the directory's inode generation number, and the entire
directory entry block up to (but not including) the fake directory entry.
Hash Tree Directories
~~~~~~~~~~~~~~~~~~~~~
@@ -196,12 +196,12 @@ new feature was added to ext3 to provide a faster (but peculiar)
balanced tree keyed off a hash of the directory entry name. If the
EXT4_INDEX_FL (0x1000) flag is set in the inode, this directory uses a
hashed btree (htree) to organize and find directory entries. For
backwards read-only compatibility with ext2, this tree is actually
hidden inside the directory file, masquerading as “empty” directory data
blocks! It was stated previously that the end of the linear directory
entry table was signified with an entry pointing to inode 0; this is
(ab)used to fool the old linear-scan algorithm into thinking that the
rest of the directory block is empty so that it moves on.
backwards read-only compatibility with ext2, interior tree nodes are actually
hidden inside the directory file, masquerading as “empty” directory entries
spanning the whole block. It was stated previously that directory entries
with the inode set to 0 are treated as unused entries; this is (ab)used to
fool the old linear-scan algorithm into skipping over those blocks containing
the interior tree node data.
The root of the tree always lives in the first data block of the
directory. By ext2 custom, the '.' and '..' entries must appear at the
@@ -209,24 +209,24 @@ beginning of this first block, so they are put here as two
``struct ext4_dir_entry_2`` s and not stored in the tree. The rest of
the root node contains metadata about the tree and finally a hash->block
map to find nodes that are lower in the htree. If
``dx_root.info.indirect_levels`` is non-zero then the htree has two
levels; the data block pointed to by the root node's map is an interior
node, which is indexed by a minor hash. Interior nodes in this tree
contains a zeroed out ``struct ext4_dir_entry_2`` followed by a
minor_hash->block map to find leafe nodes. Leaf nodes contain a linear
array of all ``struct ext4_dir_entry_2``; all of these entries
(presumably) hash to the same value. If there is an overflow, the
entries simply overflow into the next leaf node, and the
least-significant bit of the hash (in the interior node map) that gets
us to this next leaf node is set.
``dx_root.info.indirect_levels`` is non-zero then the htree has that many
levels and the blocks pointed to by the root node's map are interior nodes.
These interior nodes have a zeroed out ``struct ext4_dir_entry_2`` followed by
a hash->block map to find nodes of the next level. Leaf nodes look like
classic linear directory blocks, but all of its entries have a hash value
equal or greater than the indicated hash of the parent node.
To traverse the directory as a htree, the code calculates the hash of
the desired file name and uses it to find the corresponding block
number. If the tree is flat, the block is a linear array of directory
entries that can be searched; otherwise, the minor hash of the file name
is computed and used against this second block to find the corresponding
third block number. That third block number will be a linear array of
directory entries.
The actual hash value for an entry name is only 31 bits, the least-significant
bit is set to 0. However, if there is a hash collision between directory
entries, the least-significant bit may get set to 1 on interior nodes in the
case where these two (or more) hash-colliding entries do not fit into one leaf
node and must be split across multiple nodes.
To look up a name in such a htree, the code calculates the hash of the desired
file name and uses it to find the leaf node with the range of hash values the
calculated hash falls into (in other words, a lookup works basically the same
as it would in a B-Tree keyed by the hash value), and possibly also scanning
the leaf nodes that follow (in tree order) in case of hash collisions.
To traverse the directory as a linear array (such as the old code does),
the code simply reads every data block in the directory. The blocks used
@@ -319,7 +319,8 @@ of a data block:
* - 0x24
- __le32
- block
- The block number (within the directory file) that goes with hash=0.
- The block number (within the directory file) that lead to the left-most
leaf node, i.e. the leaf containing entries with the lowest hash values.
* - 0x28
- struct dx_entry
- entries[0]
@@ -442,7 +443,7 @@ The dx_tail structure is 8 bytes long and looks like this:
* - 0x0
- u32
- dt_reserved
- Zero.
- Unused (but still part of the checksum curiously).
* - 0x4
- __le32
- dt_checksum
@@ -450,4 +451,4 @@ The dx_tail structure is 8 bytes long and looks like this:
The checksum is calculated against the FS UUID, the htree index header
(dx_root or dx_node), all of the htree indices (dx_entry) that are in
use, and the tail block (dx_tail).
use, and the tail block (dx_tail) with the dt_checksum initially set to 0.
Documentation/gpu/xe/index.rst
+1
View File
@@ -14,6 +14,7 @@ DG2, etc is provided to prototype the driver.
xe_mm
xe_map
xe_migrate
xe_exec_queue
xe_cs
xe_pm
xe_gt_freq
Documentation/gpu/xe/xe_exec_queue.rst
+20
View File
@@ -0,0 +1,20 @@
.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
===============
Execution Queue
===============
.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue.c
:doc: Execution Queue
Internal API
============
.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue_types.h
:internal:
.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue.h
:internal:
.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue.c
:internal:
Documentation/networking/can.rst
+67 -4
View File
@@ -1398,10 +1398,9 @@ second bit timing has to be specified in order to enable the CAN FD bitrate.
Additionally CAN FD capable CAN controllers support up to 64 bytes of
payload. The representation of this length in can_frame.len and
canfd_frame.len for userspace applications and inside the Linux network
layer is a plain value from 0 .. 64 instead of the CAN 'data length code'.
The data length code was a 1:1 mapping to the payload length in the Classical
CAN frames anyway. The payload length to the bus-relevant DLC mapping is
only performed inside the CAN drivers, preferably with the helper
layer is a plain value from 0 .. 64 instead of the Classical CAN length
which ranges from 0 to 8. The payload length to the bus-relevant DLC mapping
is only performed inside the CAN drivers, preferably with the helper
functions can_fd_dlc2len() and can_fd_len2dlc().
The CAN netdevice driver capabilities can be distinguished by the network
@@ -1465,6 +1464,70 @@ Example when 'fd-non-iso on' is added on this switchable CAN FD adapter::
can <FD,FD-NON-ISO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
Transmitter Delay Compensation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At high bit rates, the propagation delay from the TX pin to the RX pin of
the transceiver might become greater than the actual bit time causing
measurement errors: the RX pin would still be measuring the previous bit.
The Transmitter Delay Compensation (thereafter, TDC) resolves this problem
by introducing a Secondary Sample Point (SSP) equal to the distance, in
minimum time quantum, from the start of the bit time on the TX pin to the
actual measurement on the RX pin. The SSP is calculated as the sum of two
configurable values: the TDC Value (TDCV) and the TDC offset (TDCO).
TDC, if supported by the device, can be configured together with CAN-FD
using the ip tool's "tdc-mode" argument as follow:
**omitted**
When no "tdc-mode" option is provided, the kernel will automatically
decide whether TDC should be turned on, in which case it will
calculate a default TDCO and use the TDCV as measured by the
device. This is the recommended method to use TDC.
**"tdc-mode off"**
TDC is explicitly disabled.
**"tdc-mode auto"**
The user must provide the "tdco" argument. The TDCV will be
automatically calculated by the device. This option is only
available if the device supports the TDC-AUTO CAN controller mode.
**"tdc-mode manual"**
The user must provide both the "tdco" and "tdcv" arguments. This
option is only available if the device supports the TDC-MANUAL CAN
controller mode.
Note that some devices may offer an additional parameter: "tdcf" (TDC Filter
window). If supported by your device, this can be added as an optional
argument to either "tdc-mode auto" or "tdc-mode manual".
Example configuring a 500 kbit/s arbitration bitrate, a 5 Mbit/s data
bitrate, a TDCO of 15 minimum time quantum and a TDCV automatically measured
by the device::
$ ip link set can0 up type can bitrate 500000 \
fd on dbitrate 4000000 \
tdc-mode auto tdco 15
$ ip -details link show can0
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP \
mode DEFAULT group default qlen 10
link/can promiscuity 0 allmulti 0 minmtu 72 maxmtu 72
can <FD,TDC-AUTO> state ERROR-ACTIVE restart-ms 0
bitrate 500000 sample-point 0.875
tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 10 brp 1
ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 \
brp_inc 1
dbitrate 4000000 dsample-point 0.750
dtq 12 dprop-seg 7 dphase-seg1 7 dphase-seg2 5 dsjw 2 dbrp 1
tdco 15 tdcf 0
ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 \
dbrp_inc 1
tdco 0..127 tdcf 0..127
clock 80000000
Supported CAN Hardware
----------------------
Documentation/networking/seg6-sysctl.rst
+3
View File
@@ -25,6 +25,9 @@ seg6_require_hmac - INTEGER
Default is 0.
/proc/sys/net/ipv6/seg6_* variables:
====================================
seg6_flowlabel - INTEGER
Controls the behaviour of computing the flowlabel of outer
IPv6 header in case of SR T.encaps
Documentation/rust/coding-guidelines.rst
+75
View File
@@ -38,6 +38,81 @@ Like ``clang-format`` for the rest of the kernel, ``rustfmt`` works on
individual files, and does not require a kernel configuration. Sometimes it may
even work with broken code.
Imports
~~~~~~~
``rustfmt``, by default, formats imports in a way that is prone to conflicts
while merging and rebasing, since in some cases it condenses several items into
the same line. For instance:
.. code-block:: rust
// Do not use this style.
use crate::{
example1,
example2::{example3, example4, example5},
example6, example7,
example8::example9,
};
Instead, the kernel uses a vertical layout that looks like this:
.. code-block:: rust
use crate::{
example1,
example2::{
example3,
example4,
example5, //
},
example6,
example7,
example8::example9, //
};
That is, each item goes into its own line, and braces are used as soon as there
is more than one item in a list.
The trailing empty comment allows to preserve this formatting. Not only that,
``rustfmt`` will actually reformat imports vertically when the empty comment is
added. That is, it is possible to easily reformat the original example into the
expected style by running ``rustfmt`` on an input like:
.. code-block:: rust
// Do not use this style.
use crate::{
example1,
example2::{example3, example4, example5, //
},
example6, example7,
example8::example9, //
};
The trailing empty comment works for nested imports, as shown above, as well as
for single item imports -- this can be useful to minimize diffs within patch
series:
.. code-block:: rust
use crate::{
example1, //
};
The trailing empty comment works in any of the lines within the braces, but it
is preferred to keep it in the last item, since it is reminiscent of the
trailing comma in other formatters. Sometimes it may be simpler to avoid moving
the comment several times within a patch series due to changes in the list.
There may be cases where exceptions may need to be made, i.e. none of this is
a hard rule. There is also code that is not migrated to this style yet, but
please do not introduce code in other styles.
Eventually, the goal is to get ``rustfmt`` to support this formatting style (or
a similar one) automatically in a stable release without requiring the trailing
empty comment. Thus, at some point, the goal is to remove those comments.
Comments
--------
Documentation/virt/kvm/api.rst
+17 -3
View File
@@ -1229,6 +1229,9 @@ It is not possible to read back a pending external abort (injected via
KVM_SET_VCPU_EVENTS or otherwise) because such an exception is always delivered
directly to the virtual CPU).
Calling this ioctl on a vCPU that hasn't been initialized will return
-ENOEXEC.
::
struct kvm_vcpu_events {
@@ -1309,6 +1312,8 @@ exceptions by manipulating individual registers using the KVM_SET_ONE_REG API.
See KVM_GET_VCPU_EVENTS for the data structure.
Calling this ioctl on a vCPU that hasn't been initialized will return
-ENOEXEC.
4.33 KVM_GET_DEBUGREGS
----------------------
@@ -6432,9 +6437,18 @@ most one mapping per page, i.e. binding multiple memory regions to a single
guest_memfd range is not allowed (any number of memory regions can be bound to
a single guest_memfd file, but the bound ranges must not overlap).
When the capability KVM_CAP_GUEST_MEMFD_MMAP is supported, the 'flags' field
supports GUEST_MEMFD_FLAG_MMAP. Setting this flag on guest_memfd creation
enables mmap() and faulting of guest_memfd memory to host userspace.
The capability KVM_CAP_GUEST_MEMFD_FLAGS enumerates the `flags` that can be
specified via KVM_CREATE_GUEST_MEMFD. Currently defined flags:
============================ ================================================
GUEST_MEMFD_FLAG_MMAP Enable using mmap() on the guest_memfd file
descriptor.
GUEST_MEMFD_FLAG_INIT_SHARED Make all memory in the file shared during
KVM_CREATE_GUEST_MEMFD (memory files created
without INIT_SHARED will be marked private).
Shared memory can be faulted into host userspace
page tables. Private memory cannot.
============================ ================================================
When the KVM MMU performs a PFN lookup to service a guest fault and the backing
guest_memfd has the GUEST_MEMFD_FLAG_MMAP set, then the fault will always be
Documentation/virt/kvm/devices/arm-vgic-v3.rst
+2 -1
View File
@@ -13,7 +13,8 @@ will act as the VM interrupt controller, requiring emulated user-space devices
to inject interrupts to the VGIC instead of directly to CPUs. It is not
possible to create both a GICv3 and GICv2 on the same VM.
Creating a guest GICv3 device requires a host GICv3 as well.
Creating a guest GICv3 device requires a host GICv3 host, or a GICv5 host with
support for FEAT_GCIE_LEGACY.
Groups:
MAINTAINERS
+11
View File
@@ -4805,6 +4805,7 @@ F: drivers/net/ethernet/broadcom/b44.*
BROADCOM B53/SF2 ETHERNET SWITCH DRIVER
M: Florian Fainelli <florian.fainelli@broadcom.com>
M: Jonas Gorski <jonas.gorski@gmail.com>
L: netdev@vger.kernel.org
L: openwrt-devel@lists.openwrt.org (subscribers-only)
S: Supported
@@ -18014,6 +18015,16 @@ X: net/rfkill/
X: net/wireless/
X: tools/testing/selftests/net/can/
NETWORKING [IOAM]
M: Justin Iurman <justin.iurman@uliege.be>
S: Maintained
F: Documentation/networking/ioam6*
F: include/linux/ioam6*
F: include/net/ioam6*
F: include/uapi/linux/ioam6*
F: net/ipv6/ioam6*
F: tools/testing/selftests/net/ioam6*
NETWORKING [IPSEC]
M: Steffen Klassert <steffen.klassert@secunet.com>
M: Herbert Xu <herbert@gondor.apana.org.au>
Makefile
+1 -1
View File
@@ -2,7 +2,7 @@
VERSION = 6
PATCHLEVEL = 18
SUBLEVEL = 0
EXTRAVERSION = -rc1
EXTRAVERSION = -rc2
NAME = Baby Opossum Posse
# *DOCUMENTATION*
arch/Kconfig
+1
View File
@@ -965,6 +965,7 @@ config HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC
def_bool y
depends on HAVE_CFI_ICALL_NORMALIZE_INTEGERS
depends on RUSTC_VERSION >= 107900
depends on ARM64 || X86_64
# With GCOV/KASAN we need this fix: https://github.com/rust-lang/rust/pull/129373
depends on (RUSTC_LLVM_VERSION >= 190103 && RUSTC_VERSION >= 108200) || \
(!GCOV_KERNEL && !KASAN_GENERIC && !KASAN_SW_TAGS)
arch/arc/configs/axs101_defconfig
+1 -1
View File
@@ -88,7 +88,7 @@ CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_DW=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=y
arch/arc/configs/axs103_defconfig
+1 -1
View File
@@ -86,7 +86,7 @@ CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_DW=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=y
arch/arc/configs/axs103_smp_defconfig
+1 -1
View File
@@ -88,7 +88,7 @@ CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_DW=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=y
Loaded 20 of 593 files, more files were not shown because too many files have changed in this diff. Show more