* [PATCH v2 0/4] dt-bindings: remove redundant .txt redirect stubs
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
Several .txt files under Documentation/devicetree/bindings/ contain
only a redirect notice pointing to a .yaml schema with the same base
filename in the same directory. These stubs were useful during the
.txt to .yaml transition but are now redundant, since the .yaml is
discoverable by name. Meanwhile, other documentation still references
some of these stubs, forcing readers through an unnecessary extra hop
to reach the actual schema.
This series removes four such stubs and updates all remaining
cross-references to point directly to the .yaml schemas.
Other redirect stubs in the tree were evaluated and intentionally
kept:
- Stubs pointing to .yaml files with different names (e.g.,
spi-bus.txt -> spi-controller.yaml) serve as breadcrumbs for
the renamed schema.
- Stubs pointing to multiple .yaml files (e.g., nvmem.txt ->
nvmem.yaml and nvmem-consumer.yaml) convey that the content
was split.
- Stubs pointing to .yaml files in a different directory (e.g.,
reset/st,stm32-rcc.txt -> clock/st,stm32-rcc.yaml) serve as
cross-directory pointers.
Two additional same-name, same-directory stubs (leds/common.txt,
regulator/regulator.txt) have significantly more cross references
and will be addressed in a follow-up series.
v2:
- Patch 4/4: corrected commit message (eight references in six files, not
eight files), Sashiko review.
https://sashiko.dev/#/patchset/20260529052246.4934-1-akash.sukhavasi@gmail.com?part=4
v1: https://lore.kernel.org/all/20260529052246.4934-1-akash.sukhavasi@gmail.com/
Patch 1 supersedes my earlier standalone submission:
https://lore.kernel.org/all/20260523004223.3045-1-akash.sukhavasi@gmail.com/
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Akash Sukhavasi (4):
dt-bindings: net: remove obsolete mdio.txt
dt-bindings: media: remove obsolete rc.txt
dt-bindings: net: dsa: remove obsolete dsa.txt
dt-bindings: input: remove obsolete matrix-keymap.txt
Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/clps711x-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/matrix-keymap.txt | 1 -
Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | 2 +-
Documentation/devicetree/bindings/input/pxa27x-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/st-keyscan.txt | 2 +-
Documentation/devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
Documentation/devicetree/bindings/media/rc.txt | 1 -
Documentation/devicetree/bindings/mfd/tc3589x.txt | 6 +++---
Documentation/devicetree/bindings/net/dsa/dsa.txt | 4 ----
Documentation/devicetree/bindings/net/dsa/lan9303.txt | 2 +-
Documentation/devicetree/bindings/net/mdio.txt | 1 -
Documentation/networking/dsa/dsa.rst | 2 +-
13 files changed, 11 insertions(+), 18 deletions(-)
---
base-commit: b7bee4ca5688e30ca50fbc87b1b8f7eed7006c17
change-id: 20260603-b4-remove-redirect-stubs-899afc8fa7d6
Best regards,
--
Akash Sukhavasi <akash.sukhavasi@gmail.com>
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: net: remove obsolete mdio.txt
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
mdio.txt has been a single-line redirect to mdio.yaml since
commit 62d77ff7ecbf ("dt-bindings: net: Add a YAML schemas for the
generic MDIO options"), which introduced the .yaml schema and reduced
the .txt to a stub in the same change. The .yaml has the same filename
in the same directory, making this redirect unnecessary for
discoverability.
No files in the tree reference mdio.txt and it has not been touched
since June 2019. Remove the obsolete stub.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Documentation/devicetree/bindings/net/mdio.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/mdio.txt b/Documentation/devicetree/bindings/net/mdio.txt
deleted file mode 100644
index cf8a0105488e..000000000000
--- a/Documentation/devicetree/bindings/net/mdio.txt
+++ /dev/null
@@ -1 +0,0 @@
-This file has moved to mdio.yaml.
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: media: remove obsolete rc.txt
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
rc.txt has been a single-line redirect to rc.yaml since
commit 7c31b9d67342 ("media: dt-bindings: media: Add YAML schemas for
the generic RC bindings"), which introduced the .yaml schema and
reduced the .txt to a stub in the same change. The .yaml has the same
filename in the same directory, making this redirect unnecessary
for discoverability.
One file still references rc.txt, forcing readers through an extra
hop to reach the .yaml. The stub has not been touched since August
2019. Update the reference in hix5hd2-ir.txt to point directly to
rc.yaml and remove the stub.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Documentation/devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
Documentation/devicetree/bindings/media/rc.txt | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
index ca4cf774662e..f777c2707e65 100644
--- a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
+++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
@@ -11,7 +11,7 @@ Required properties:
- clocks: clock phandle and specifier pair.
Optional properties:
- - linux,rc-map-name: see rc.txt file in the same directory.
+ - linux,rc-map-name: see rc.yaml file in the same directory.
- hisilicon,power-syscon: DEPRECATED. Don't use this in new dts files.
Provide correct clocks instead.
diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt
deleted file mode 100644
index be629f7fa77e..000000000000
--- a/Documentation/devicetree/bindings/media/rc.txt
+++ /dev/null
@@ -1 +0,0 @@
-This file has been moved to rc.yaml.
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: net: dsa: remove obsolete dsa.txt
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
dsa.txt has been a redirect to dsa.yaml since commit bce58590d1bd
("dt-bindings: net: dsa: Add DSA yaml binding") introduced the .yaml
schema. The .yaml has the same filename in the same directory, making
this redirect unnecessary for discoverability.
Two files still reference dsa.txt, forcing readers through an extra
hop to reach the .yaml. The stub has not been touched since August
2020. Update references in lan9303.txt and
Documentation/networking/dsa/dsa.rst to point directly to dsa.yaml
and remove the stub.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Documentation/devicetree/bindings/net/dsa/dsa.txt | 4 ----
Documentation/devicetree/bindings/net/dsa/lan9303.txt | 2 +-
Documentation/networking/dsa/dsa.rst | 2 +-
3 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.txt b/Documentation/devicetree/bindings/net/dsa/dsa.txt
deleted file mode 100644
index dab208b5c7c7..000000000000
--- a/Documentation/devicetree/bindings/net/dsa/dsa.txt
+++ /dev/null
@@ -1,4 +0,0 @@
-Distributed Switch Architecture Device Tree Bindings
-----------------------------------------------------
-
-See Documentation/devicetree/bindings/net/dsa/dsa.yaml for the documentation.
diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
index 46a732087f5c..0337c2ccfa9a 100644
--- a/Documentation/devicetree/bindings/net/dsa/lan9303.txt
+++ b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
@@ -16,7 +16,7 @@ Optional properties:
Subnodes:
The integrated switch subnode should be specified according to the binding
-described in dsa/dsa.txt. The CPU port of this switch is always port 0.
+described in dsa/dsa.yaml. The CPU port of this switch is always port 0.
Note: always use 'reg = <0/1/2>;' for the three DSA ports, even if the device is
configured to use 1/2/3 instead. This hardware configuration will be
diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst
index fd3c254ced1d..42a99f5dfa2e 100644
--- a/Documentation/networking/dsa/dsa.rst
+++ b/Documentation/networking/dsa/dsa.rst
@@ -509,7 +509,7 @@ Device Tree
-----------
DSA features a standardized binding which is documented in
-``Documentation/devicetree/bindings/net/dsa/dsa.txt``. PHY/MDIO library helper
+``Documentation/devicetree/bindings/net/dsa/dsa.yaml``. PHY/MDIO library helper
functions such as ``of_get_phy_mode()``, ``of_phy_connect()`` are also used to query
per-port PHY specific details: interface connection, MDIO bus location, etc.
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/4] dt-bindings: input: remove obsolete matrix-keymap.txt
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
matrix-keymap.txt has been a single-line redirect to
matrix-keymap.yaml since commit 639d6eda3b80 ("dt-bindings: input:
Convert matrix-keymap to json-schema"), which introduced the .yaml
schema and reduced the .txt to a stub in the same change. The .yaml
has the same filename in the same directory, making this redirect
unnecessary for discoverability.
Eight instances across six files still reference matrix-keymap.txt,
forcing readers through an extra hop to reach the .yaml. The stub has
not been touched since June 2020. Update all references across input
and mfd binding documentation to point directly to matrix-keymap.yaml
and remove the stub.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
v2:
- Patch 4/4: corrected commit message (eight references in six files,
not eight files), Sashiko review.
https://sashiko.dev/#/patchset/20260529052246.4934-1-akash.sukhavasi@gmail.com?part=4
v1: https://lore.kernel.org/all/20260529052246.4934-5-akash.sukhavasi@gmail.com/
---
Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/clps711x-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/matrix-keymap.txt | 1 -
Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | 2 +-
Documentation/devicetree/bindings/input/pxa27x-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/st-keyscan.txt | 2 +-
Documentation/devicetree/bindings/mfd/tc3589x.txt | 6 +++---
7 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
index 262deab73588..33514eba0c9c 100644
--- a/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
+++ b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
@@ -59,7 +59,7 @@ Board Specific Properties:
subsystem (optional).
- linux,keymap: The keymap for keys as described in the binding document
- devicetree/bindings/input/matrix-keymap.txt.
+ devicetree/bindings/input/matrix-keymap.yaml.
Example:
#include "dt-bindings/input/input.h"
diff --git a/Documentation/devicetree/bindings/input/clps711x-keypad.txt b/Documentation/devicetree/bindings/input/clps711x-keypad.txt
index 3eed8819d05d..5f4514c0cd5f 100644
--- a/Documentation/devicetree/bindings/input/clps711x-keypad.txt
+++ b/Documentation/devicetree/bindings/input/clps711x-keypad.txt
@@ -5,7 +5,7 @@ Required Properties:
- row-gpios: List of GPIOs used as row lines.
- poll-interval: Poll interval time in milliseconds.
- linux,keymap: The definition can be found at
- bindings/input/matrix-keymap.txt.
+ bindings/input/matrix-keymap.yaml.
Optional Properties:
- autorepeat: Enable autorepeat feature.
diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt
deleted file mode 100644
index 79f6d01aecaa..000000000000
--- a/Documentation/devicetree/bindings/input/matrix-keymap.txt
+++ /dev/null
@@ -1 +0,0 @@
-This file has been moved to matrix-keymap.yaml
diff --git a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
index 1faa7292e21f..460b64d332cd 100644
--- a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
+++ b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
@@ -12,7 +12,7 @@ Required properties:
- nvidia,kbc-col-pins: The KBC pins which are configured as column. This is an
array of pin numbers which is used as column.
- linux,keymap: The keymap for keys as described in the binding document
- devicetree/bindings/input/matrix-keymap.txt.
+ devicetree/bindings/input/matrix-keymap.yaml.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each entry in reset-names.
diff --git a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
index f8674f7e5ea5..a727d66eece4 100644
--- a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
+++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
@@ -10,7 +10,7 @@ Required Properties
interval for matrix key. The value is in binary number of 2ms
Optional Properties For Matrix Keyes
-Please refer to matrix-keymap.txt
+Please refer to matrix-keymap.yaml
Optional Properties for Direct Keyes
- marvell,direct-key-count : How many direct keyes are used.
diff --git a/Documentation/devicetree/bindings/input/st-keyscan.txt b/Documentation/devicetree/bindings/input/st-keyscan.txt
index 51eb428e5c85..fd88f40faebf 100644
--- a/Documentation/devicetree/bindings/input/st-keyscan.txt
+++ b/Documentation/devicetree/bindings/input/st-keyscan.txt
@@ -17,7 +17,7 @@ Required properties:
See ../pinctrl/pinctrl-bindings.txt for details.
- linux,keymap: The keymap for keys as described in the binding document
- devicetree/bindings/input/matrix-keymap.txt.
+ devicetree/bindings/input/matrix-keymap.yaml.
- keypad,num-rows: Number of row lines connected to the keypad controller.
diff --git a/Documentation/devicetree/bindings/mfd/tc3589x.txt b/Documentation/devicetree/bindings/mfd/tc3589x.txt
index 4f22b2b07dc5..a6d356e90f42 100644
--- a/Documentation/devicetree/bindings/mfd/tc3589x.txt
+++ b/Documentation/devicetree/bindings/mfd/tc3589x.txt
@@ -48,11 +48,11 @@ Optional nodes:
- compatible : must be "toshiba,tc3589x-keypad"
- debounce-delay-ms : debounce interval in milliseconds
- keypad,num-rows : number of rows in the matrix, see
- bindings/input/matrix-keymap.txt
+ bindings/input/matrix-keymap.yaml
- keypad,num-columns : number of columns in the matrix, see
- bindings/input/matrix-keymap.txt
+ bindings/input/matrix-keymap.yaml
- linux,keymap: the definition can be found in
- bindings/input/matrix-keymap.txt
+ bindings/input/matrix-keymap.yaml
- linux,no-autorepeat: do no enable autorepeat feature.
- wakeup-source: use any event on keypad as wakeup event.
(Legacy property supported: "linux,wakeup")
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] arm64: Document SVE constraints on new hwcaps
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-doc,
linux-kernel
In-Reply-To: <20260522-arm64-elf-hwcaps-sve-cleanup-v1-1-07b0cedfc6fa@kernel.org>
On Fri, 22 May 2026 18:50:28 +0100, Mark Brown wrote:
> Two of the SVE hwcaps added for the SVE features in the 2025 dpISA did
> not explicitly call out their dependency on SVE in the ABI documentation.
> Do so.
>
> While we're here reorder the SVE and fature specific ID registers for
> HWCAP3_SVE_LUT6 which did have the SVE dependency but listed it second
> unlike the other SVE specific ID registers.
>
> [...]
Applied to arm64 (for-next/cpufeature), thanks!
[1/1] arm64: Document SVE constraints on new hwcaps
https://git.kernel.org/arm64/c/f20f8fe086b2
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v4 0/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: vladimir.murzin, xuwei5, broonie, ryan.roberts, corbet,
catalin.marinas, oupton, kevin.brodsky, maz, yeoreum.yun, skhan,
yangyicong, thuth, kuninori.morimoto.gx, lucaswei, lpieralisi,
miko.lenczewski, mark.rutland, james.clark, Zeng Heng
Cc: kernel-team, Will Deacon, wangkefeng.wang, linux-arm-kernel,
linux-kernel, linux-doc, zengheng4
In-Reply-To: <20260603062025.1504083-1-zengheng@huaweicloud.com>
On Wed, 03 Jun 2026 14:20:23 +0800, Zeng Heng wrote:
> v3: https://lore.kernel.org/all/20260601112000.1145391-1-zengheng@huaweicloud.com/
> v2: https://lore.kernel.org/all/20260529063132.766491-1-zengheng@huaweicloud.com/
> v1: https://lore.kernel.org/all/20260526015720.206854-1-zengheng@huaweicloud.com/
>
> Changes in v4:
> - Keep orthogonality for CONFIG_NVIDIA_CARMEL_CNP_ERRATUM and
> CONFIG_HISILICON_ERRATUM_162100125 within the cnp_erratum_cpus array.
>
> [...]
Applied to arm64 (for-next/errata), thanks!
[1/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
https://git.kernel.org/arm64/c/25996982ebcf
[2/2] arm64: kernel: Disable CNP on HiSilicon HIP09
https://git.kernel.org/arm64/c/f64328ecf4bf
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* [PATCH v2 1/1] dt-bindings: net: dsa: Convert lan9303.txt to yaml format
From: Frank.Li @ 2026-06-03 21:09 UTC (permalink / raw)
To: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan, Frank Li,
open list:NETWORKING DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:DOCUMENTATION
Cc: imx
From: Frank Li <Frank.Li@nxp.com>
Convert lan9303.txt to yaml format to fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx53-kp-hsc.dtb: /soc/bus@50000000/i2c@53fec000/switch@a: failed to match any schema with compatible: ['smsc,lan9303-i2c']
Additional changes:
- rename switch-phy to switch in example.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2:
- fix typo Additional in commit message
- add rob's reviewed-by tags
- fix doc ref problem
---
.../devicetree/bindings/net/dsa/lan9303.txt | 100 --------------
.../bindings/net/dsa/smsc,lan9303.yaml | 123 ++++++++++++++++++
Documentation/networking/dsa/lan9303.rst | 2 +-
3 files changed, 124 insertions(+), 101 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/dsa/lan9303.txt
create mode 100644 Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
deleted file mode 100644
index 46a732087f5ca..0000000000000
--- a/Documentation/devicetree/bindings/net/dsa/lan9303.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-SMSC/MicroChip LAN9303 three port ethernet switch
--------------------------------------------------
-
-Required properties:
-
-- compatible: should be
- - "smsc,lan9303-i2c" for I2C managed mode
- or
- - "smsc,lan9303-mdio" for mdio managed mode
-
-Optional properties:
-
-- reset-gpios: GPIO to be used to reset the whole device
-- reset-duration: reset duration in milliseconds, defaults to 200 ms
-
-Subnodes:
-
-The integrated switch subnode should be specified according to the binding
-described in dsa/dsa.txt. The CPU port of this switch is always port 0.
-
-Note: always use 'reg = <0/1/2>;' for the three DSA ports, even if the device is
-configured to use 1/2/3 instead. This hardware configuration will be
-auto-detected and mapped accordingly.
-
-Example:
-
-I2C managed mode:
-
- master: masterdevice@X {
-
- fixed-link { /* RMII fixed link to LAN9303 */
- speed = <100>;
- full-duplex;
- };
- };
-
- switch: switch@a {
- compatible = "smsc,lan9303-i2c";
- reg = <0xa>;
- reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
- reset-duration = <200>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 { /* RMII fixed link to master */
- reg = <0>;
- ethernet = <&master>;
- };
-
- port@1 { /* external port 1 */
- reg = <1>;
- label = "lan1";
- };
-
- port@2 { /* external port 2 */
- reg = <2>;
- label = "lan2";
- };
- };
- };
-
-MDIO managed mode:
-
- master: masterdevice@X {
- phy-handle = <&switch>;
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- switch: switch-phy@0 {
- compatible = "smsc,lan9303-mdio";
- reg = <0>;
- reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
- reset-duration = <100>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- ethernet = <&master>;
- };
-
- port@1 { /* external port 1 */
- reg = <1>;
- label = "lan1";
- };
-
- port@2 { /* external port 2 */
- reg = <2>;
- label = "lan2";
- };
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml b/Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
new file mode 100644
index 0000000000000..42f8473538a07
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/smsc,lan9303.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SMSC/MicroChip LAN9303 three port ethernet switch
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The LAN9303 is a three port ethernet switch with integrated PHYs for the
+ two external ports. The third port is an RMII/MII interface to a host
+ processor. The device can be managed via I2C or MDIO.
+
+ Note - always use 'reg = <0/1/2>;' for the three DSA ports, even if the
+ device is configured to use 1/2/3 instead. This hardware configuration
+ will be auto-detected and mapped accordingly.
+
+properties:
+ compatible:
+ enum:
+ - smsc,lan9303-i2c
+ - smsc,lan9303-mdio
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ GPIO to be used to reset the whole device
+ maxItems: 1
+
+ reset-duration:
+ description:
+ Reset duration in milliseconds
+ default: 200
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: dsa.yaml#
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ /* I2C managed mode */
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@a {
+ compatible = "smsc,lan9303-i2c";
+ reg = <0xa>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <200>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ /* MDIO managed mode */
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "smsc,lan9303-mdio";
+ reg = <0>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <100>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+ };
diff --git a/Documentation/networking/dsa/lan9303.rst b/Documentation/networking/dsa/lan9303.rst
index ab81b4e0139e3..776572be265e1 100644
--- a/Documentation/networking/dsa/lan9303.rst
+++ b/Documentation/networking/dsa/lan9303.rst
@@ -12,7 +12,7 @@ Driver details
The driver is implemented as a DSA driver, see ``Documentation/networking/dsa/dsa.rst``.
-See ``Documentation/devicetree/bindings/net/dsa/lan9303.txt`` for device tree
+See ``Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml`` for device tree
binding.
The LAN9303 can be managed both via MDIO and I2C, both supported by this driver.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v7 00/42] guest_memfd: In-place conversion support
From: Ackerley Tng @ 2026-06-03 21:27 UTC (permalink / raw)
To: Ackerley Tng via B4 Relay, aik, andrew.jones, binbin.wu, brauner,
chao.p.peng, david, ira.weiny, jmattson, jthoughton, michael.roth,
oupton, pankaj.gupta, qperret, rick.p.edgecombe, rientjes,
shivankg, steven.price, tabba, willy, wyihan, yan.y.zhao,
forkloop, pratyush, suzuki.poulose, aneesh.kumar, liam,
Paolo Bonzini, Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka
Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260522-gmem-inplace-conversion-v7-0-2f0fae496530@google.com>
Ackerley Tng via B4 Relay <devnull+ackerleytng.google.com@kernel.org>
writes:
> This is v7 of guest_memfd in-place conversion support.
>
Here's the outstanding items after going over everyone's comments
including Sashiko's:
+ KVM: TDX: Make source page optional for KVM_TDX_INIT_MEM_REGION
+ Need to move page clearing into __kvm_gmem_get_pfn to resolve
leak where populate can put initialized kernel memory into TDX
guest
+ See suggested fix at [1]
+ KVM: guest_memfd: Only prepare folios for private pages,
+ s/non-CoCo/CoCo in commit message "INIT_SHARED is about to be
supported for non-CoCo VMs in a later patch in this series
+ Use Suggested-by: Michael Roth <michael.roth@amd.com>
+ KVM: selftests: Test that shared/private status is consistent across
processes
+ Improve test reliability using pthread_mutex
+ I have a fixup patch offline.
I would like feedback on these:
+ KVM: selftests: Test conversion with elevated page refcount
+ Askar pointed out that soon vmsplice may not pin pages. Should I
pin pages through CONFIG_GUP_TEST like in [2]? I prefer not to
take a dependency on CONFIG_GUP_TEST.
+ KVM: selftests: Add script to exercise private_mem_conversions_test
+ Would like to know what people think of a wrapper script before
I address Sashiko's comments.
[1] https://lore.kernel.org/all/CAEvNRgEVC=fFuKVgZYvWyZD7t_zvUZihFG8hrACjvtkD5cwugw@mail.gmail.com/
[2] https://lore.kernel.org/all/baa8838f623102931e755cf34c86314b305af49c.1747264138.git.ackerleytng@google.com/
>
> [...snip...]
>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: net: remove obsolete mdio.txt
From: Rob Herring (Arm) @ 2026-06-03 22:19 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Heiner Kallweit, David S. Miller, Vladimir Oltean, linux-media,
linux-tegra, Dmitry Torokhov, linux-doc, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-kernel, Mauro Carvalho Chehab,
devicetree, Simon Horman, Andrew Lunn, Paolo Abeni, Lee Jones,
Krzysztof Kozlowski, netdev, Eric Dumazet, linux-input,
Russell King, Thierry Reding, Jonathan Hunter, Jakub Kicinski
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-1-c8c19876ab64@gmail.com>
On Wed, 03 Jun 2026 15:42:18 -0500, Akash Sukhavasi wrote:
> mdio.txt has been a single-line redirect to mdio.yaml since
> commit 62d77ff7ecbf ("dt-bindings: net: Add a YAML schemas for the
> generic MDIO options"), which introduced the .yaml schema and reduced
> the .txt to a stub in the same change. The .yaml has the same filename
> in the same directory, making this redirect unnecessary for
> discoverability.
>
> No files in the tree reference mdio.txt and it has not been touched
> since June 2019. Remove the obsolete stub.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> Documentation/devicetree/bindings/net/mdio.txt | 1 -
> 1 file changed, 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: media: remove obsolete rc.txt
From: Rob Herring (Arm) @ 2026-06-03 22:20 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Jakub Kicinski, Jonathan Hunter, Paolo Abeni, linux-kernel,
linux-input, Heiner Kallweit, Eric Dumazet, devicetree,
Simon Horman, Mauro Carvalho Chehab, linux-media, linux-tegra,
David S. Miller, Jonathan Corbet, Shuah Khan, Conor Dooley,
Lee Jones, Andrew Lunn, Krzysztof Kozlowski, Russell King,
linux-doc, netdev, Vladimir Oltean, Dmitry Torokhov,
Thierry Reding
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-2-c8c19876ab64@gmail.com>
On Wed, 03 Jun 2026 15:42:19 -0500, Akash Sukhavasi wrote:
> rc.txt has been a single-line redirect to rc.yaml since
> commit 7c31b9d67342 ("media: dt-bindings: media: Add YAML schemas for
> the generic RC bindings"), which introduced the .yaml schema and
> reduced the .txt to a stub in the same change. The .yaml has the same
> filename in the same directory, making this redirect unnecessary
> for discoverability.
>
> One file still references rc.txt, forcing readers through an extra
> hop to reach the .yaml. The stub has not been touched since August
> 2019. Update the reference in hix5hd2-ir.txt to point directly to
> rc.yaml and remove the stub.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> Documentation/devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
> Documentation/devicetree/bindings/media/rc.txt | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: net: dsa: remove obsolete dsa.txt
From: Rob Herring (Arm) @ 2026-06-03 22:20 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Dmitry Torokhov, linux-media, Thierry Reding, linux-input,
Eric Dumazet, linux-tegra, Shuah Khan, David S. Miller,
Krzysztof Kozlowski, Conor Dooley, devicetree,
Mauro Carvalho Chehab, Heiner Kallweit, Andrew Lunn, Simon Horman,
Jakub Kicinski, netdev, linux-kernel, Jonathan Hunter, Lee Jones,
Russell King, Paolo Abeni, Vladimir Oltean, Jonathan Corbet,
linux-doc
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-3-c8c19876ab64@gmail.com>
On Wed, 03 Jun 2026 15:42:20 -0500, Akash Sukhavasi wrote:
> dsa.txt has been a redirect to dsa.yaml since commit bce58590d1bd
> ("dt-bindings: net: dsa: Add DSA yaml binding") introduced the .yaml
> schema. The .yaml has the same filename in the same directory, making
> this redirect unnecessary for discoverability.
>
> Two files still reference dsa.txt, forcing readers through an extra
> hop to reach the .yaml. The stub has not been touched since August
> 2020. Update references in lan9303.txt and
> Documentation/networking/dsa/dsa.rst to point directly to dsa.yaml
> and remove the stub.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> Documentation/devicetree/bindings/net/dsa/dsa.txt | 4 ----
> Documentation/devicetree/bindings/net/dsa/lan9303.txt | 2 +-
> Documentation/networking/dsa/dsa.rst | 2 +-
> 3 files changed, 2 insertions(+), 6 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/4] dt-bindings: remove redundant .txt redirect stubs
From: Rob Herring @ 2026-06-03 22:21 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Vladimir Oltean,
Simon Horman, Jonathan Corbet, Shuah Khan, Dmitry Torokhov,
Thierry Reding, Jonathan Hunter, Lee Jones, netdev, devicetree,
linux-kernel, linux-media, linux-doc, linux-input, linux-tegra
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
On Wed, Jun 03, 2026 at 03:42:17PM -0500, Akash Sukhavasi wrote:
> Several .txt files under Documentation/devicetree/bindings/ contain
> only a redirect notice pointing to a .yaml schema with the same base
> filename in the same directory. These stubs were useful during the
> .txt to .yaml transition but are now redundant, since the .yaml is
> discoverable by name. Meanwhile, other documentation still references
> some of these stubs, forcing readers through an unnecessary extra hop
> to reach the actual schema.
>
> This series removes four such stubs and updates all remaining
> cross-references to point directly to the .yaml schemas.
>
> Other redirect stubs in the tree were evaluated and intentionally
> kept:
>
> - Stubs pointing to .yaml files with different names (e.g.,
> spi-bus.txt -> spi-controller.yaml) serve as breadcrumbs for
> the renamed schema.
>
> - Stubs pointing to multiple .yaml files (e.g., nvmem.txt ->
> nvmem.yaml and nvmem-consumer.yaml) convey that the content
> was split.
>
> - Stubs pointing to .yaml files in a different directory (e.g.,
> reset/st,stm32-rcc.txt -> clock/st,stm32-rcc.yaml) serve as
> cross-directory pointers.
>
> Two additional same-name, same-directory stubs (leds/common.txt,
> regulator/regulator.txt) have significantly more cross references
> and will be addressed in a follow-up series.
>
> v2:
> - Patch 4/4: corrected commit message (eight references in six files, not
> eight files), Sashiko review.
> https://sashiko.dev/#/patchset/20260529052246.4934-1-akash.sukhavasi@gmail.com?part=4
>
> v1: https://lore.kernel.org/all/20260529052246.4934-1-akash.sukhavasi@gmail.com/
>
> Patch 1 supersedes my earlier standalone submission:
> https://lore.kernel.org/all/20260523004223.3045-1-akash.sukhavasi@gmail.com/
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> Akash Sukhavasi (4):
> dt-bindings: net: remove obsolete mdio.txt
> dt-bindings: media: remove obsolete rc.txt
> dt-bindings: net: dsa: remove obsolete dsa.txt
> dt-bindings: input: remove obsolete matrix-keymap.txt
This goes to 3 different subsystems, so it should be 3 different series.
No need to resend just for that.
Rob
^ permalink raw reply
* Re: [PATCH v2 4/4] dt-bindings: input: remove obsolete matrix-keymap.txt
From: Rob Herring (Arm) @ 2026-06-03 22:26 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: Conor Dooley, David S. Miller, Andrew Lunn, linux-tegra,
linux-input, Mauro Carvalho Chehab, Heiner Kallweit,
Thierry Reding, linux-media, Krzysztof Kozlowski, Jakub Kicinski,
Vladimir Oltean, linux-doc, linux-kernel, Eric Dumazet,
Dmitry Torokhov, Jonathan Hunter, Simon Horman, devicetree,
Paolo Abeni, Lee Jones, netdev, Shuah Khan, Russell King,
Jonathan Corbet
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-4-c8c19876ab64@gmail.com>
On Wed, 03 Jun 2026 15:42:21 -0500, Akash Sukhavasi wrote:
> matrix-keymap.txt has been a single-line redirect to
> matrix-keymap.yaml since commit 639d6eda3b80 ("dt-bindings: input:
> Convert matrix-keymap to json-schema"), which introduced the .yaml
> schema and reduced the .txt to a stub in the same change. The .yaml
> has the same filename in the same directory, making this redirect
> unnecessary for discoverability.
>
> Eight instances across six files still reference matrix-keymap.txt,
> forcing readers through an extra hop to reach the .yaml. The stub has
> not been touched since June 2020. Update all references across input
> and mfd binding documentation to point directly to matrix-keymap.yaml
> and remove the stub.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> v2:
> - Patch 4/4: corrected commit message (eight references in six files,
> not eight files), Sashiko review.
> https://sashiko.dev/#/patchset/20260529052246.4934-1-akash.sukhavasi@gmail.com?part=4
>
> v1: https://lore.kernel.org/all/20260529052246.4934-5-akash.sukhavasi@gmail.com/
> ---
> Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt | 2 +-
> Documentation/devicetree/bindings/input/clps711x-keypad.txt | 2 +-
> Documentation/devicetree/bindings/input/matrix-keymap.txt | 1 -
> Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | 2 +-
> Documentation/devicetree/bindings/input/pxa27x-keypad.txt | 2 +-
> Documentation/devicetree/bindings/input/st-keyscan.txt | 2 +-
> Documentation/devicetree/bindings/mfd/tc3589x.txt | 6 +++---
> 7 files changed, 8 insertions(+), 9 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next] docs: exclude driver and netdevsim bugs
From: Jacob Keller @ 2026-06-03 22:54 UTC (permalink / raw)
To: Johannes Berg, Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
workflows, linux-doc
In-Reply-To: <c78c1ff315ec96795461f100064bc42c524a67e3.camel@sipsolutions.net>
On 6/3/2026 1:12 PM, Johannes Berg wrote:
> On Wed, 2026-06-03 at 09:29 -0700, Jakub Kicinski wrote:
>>
>> +Additionally, netdev does not consider bugs to be ``net``-worthy
>> +if they fulfill **all** of the following criteria:
>> + - bug is in a hardware device driver;
>> + - bug is either a missing error handling or is part of the error handling flow;
>
> Do you really want to be this specific?
>
I agree, this does feel a little overly specific. Perhaps there is
better wording to clarify the intent such that it could cover your
example as well? Hmm.
> Take this fix for example that I mentioned the other day:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260531145435.701703-1-runyu.xiao@seu.edu.cn/
>
> It doesn't formally fall under that definition, but I think it should,
> it's a silly thing to send to stable etc.
>
> This isn't even a USB device where you could reasonably argue that
> someone might plug in a random one and it could be programmed to look
> like the device in question and misbehave. Sure, you can build PCIe
> hardware too that can do that, technically, and there's technically
> external PCIe via Thunderbolt, but it's still far harder to actually do
> anything with.
>
>> + - bug was discovered by a static analysis / AI tool;
>
> I'm not (yet?) convinced that this bullet point is right.
>
> It risks getting into an argument about how much the LLM did to discover
> it, or if the actual discovery was a manual process after the LLM
> pointed out issues, or whatever ...
>
> Maybe more importantly, why should that even change the result?
>
> It's true that today the reason to start spelling this out more clearly
> is AI related, but that's really because of (a) the scale, and (b) many
> of the people running the LLMs not being aware of (and frankly often not
> really caring about) the community norms. I'm not convinced that the
> "silliness" of a change should be measured by how it originated.
>
Right. The point to me seems that "fixes" made purely to resolve tool
hits (static analysis, checkpatch, LLM, whatever) have lower value than
fixes which have a stronger motivation such as user reports.
I'm not sure I have a better wording, and perhaps you could remove this
bit entirely.
>> + - bug was triggered/observed only with kernel changes or fault injection.
>
> Given this fourth bullet point, we'd still accept fixes for such driver
> problems that people actually run into, while excluding "theoretical"
> things that are discovered by "reading the code".
>
Right. One could argue that some race conditions are difficult to
trigger because a window is very narrow, and fault injection could make
it much easier... But we could still accept such fixes as development
improvement rather than through the "net" tree, so I think this criteria
is good.
> johannes
>
^ permalink raw reply
* Re: [PATCH v4 1/3] mm/swap: colocate page-cluster sysctl with swap readahead
From: Barry Song @ 2026-06-04 0:14 UTC (permalink / raw)
To: Jianyue Wu
Cc: Andrew Morton, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Youngjun Park, Qi Zheng, Shakeel Butt, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Johannes Weiner, David Hildenbrand,
Michal Hocko, Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Hugh Dickins,
Baolin Wang, Jonathan Corbet, Shuah Khan, linux-mm, linux-kernel,
linux-doc
In-Reply-To: <20260603-ch-swap-series-plus-folio-lru-cleanup-v4-1-ce0219e100d9@gmail.com>
On Wed, Jun 3, 2026 at 9:05 PM Jianyue Wu <wujianyue000@gmail.com> wrote:
>
> page_cluster and the vm.page-cluster sysctl are only used by swap-in
> readahead in swap_state.c. Move them out of swap.c together with
> swap_readahead_setup(), and make page_cluster static to that file.
>
> Rename swap_setup() while moving it as well. The helper is internal to
> MM and now only sets up swap readahead defaults and its sysctl hook, so
> the more specific name matches its reduced scope.
>
> swap_setup() previously lived in mm/swap.c, which is built
> unconditionally, so the vm.page-cluster sysctl was registered also on
> CONFIG_SWAP=n kernels. swap_readahead_setup() is now a no-op stub when
> CONFIG_SWAP is disabled, so vm.page-cluster is no longer registered
> there. The knob only tunes swap-in readahead and had no effect without
> swap.
>
> Suggested-by: Baoquan He <bhe@redhat.com>
> Suggested-by: Barry Song <baohua@kernel.org>
> Signed-off-by: Jianyue Wu <wujianyue000@gmail.com>
> ---
Reviewed-by: Barry Song <baohua@kernel.org>
^ permalink raw reply
* [PATCH] docs: pt_BR: update "Purpose of Defconfigs" section in maintainer-soc.rst
From: Amanda Corrêa @ 2026-06-04 0:22 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Amanda Corrêa
This update includes the "Purpose of Defconfigs" section translated
to Brazilian Portuguese.
Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
---
.../translations/pt_BR/process/maintainer-soc.rst | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-soc.rst b/Documentation/translations/pt_BR/process/maintainer-soc.rst
index 5a3ae213e..96dc9a130 100644
--- a/Documentation/translations/pt_BR/process/maintainer-soc.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-soc.rst
@@ -8,7 +8,7 @@ Visão Geral
-----------
O subsistema SoC é um local de agregação para códigos específicos de SoC
-System on Chip). Os principais componentes do subsistema são:
+(System on Chip). Os principais componentes do subsistema são:
* Devicetrees (DTS) para ARM de 32 e 64 bits e RISC-V.
* Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*).
@@ -220,3 +220,13 @@ A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita
usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve
descrição resumindo as alterações no pull request. Para mais detalhes sobre o
envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``.
+
+Propósito do Defconfigs
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
+distribuições têm suas próprias configurações. Uma mudança que adiciona novas
+opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
+em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
+suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
+para máquinas não upstream não deve ser aceito.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 11/12] ima: Support staging and deleting N measurements records
From: steven chen @ 2026-06-04 0:25 UTC (permalink / raw)
To: Roberto Sassu, corbet, skhan, zohar, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu, steven chen
In-Reply-To: <20260602111401.1706052-12-roberto.sassu@huaweicloud.com>
On 6/2/2026 4:14 AM, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Add support for sending a value N between 1 and ULONG_MAX to the IMA
> original measurement interface. This value represents the number of
> measurements that should be deleted from the current measurements list. In
> this case, measurements are staged in an internal non-user visible list,
> and immediately deleted.
>
> This staging method allows the remote attestation agents to easily separate
> the measurements that were verified (staged and deleted) from those that
> weren't due to the race between taking a TPM quote and reading the
> measurements list.
>
> In order to minimize the locking time of ima_extend_list_mutex, deleting
> N records is realized by doing a lockless walk in the current measurements
> list to determine the N-th entry to cut, to cut the current measurements
> list under the lock, and by deleting the excess records after releasing the
> lock.
>
> Flushing the hash table is not supported for N records, since it would
> require removing the N records one by one from the hash table under the
> ima_extend_list_mutex lock, which would increase the locking time.
>
> Link: https://github.com/linux-integrity/linux/issues/1
> Co-developed-by: Steven Chen <chenste@linux.microsoft.com>
Signed-off-by: Steven Chen <chenste@linux.microsoft.com>
> Co-developed-by: Roberto Sassu <roberto.sassu@huawei.com>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> ---
> security/integrity/ima/Kconfig | 3 ++
> security/integrity/ima/ima.h | 1 +
> security/integrity/ima/ima_fs.c | 32 +++++++++++++--
> security/integrity/ima/ima_queue.c | 63 ++++++++++++++++++++++++++++++
> 4 files changed, 96 insertions(+), 3 deletions(-)
>
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 02436670f746..f4d25e045808 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -341,6 +341,9 @@ config IMA_STAGING
> It allows user space to stage the measurements list for deletion and
> to delete the staged measurements after confirmation.
>
> + Or, alternatively, it allows user space to specify N measurements
> + records to stage internally, so that they can be immediately deleted.
> +
> On kexec, staging is aborted and any staged measurement records are
> copied to the secondary kernel.
>
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index d2e740c8ff75..7a1b2d6a8b59 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -320,6 +320,7 @@ struct ima_template_desc *lookup_template_desc(const char *name);
> bool ima_template_has_modsig(const struct ima_template_desc *ima_template);
> int ima_queue_stage(void);
> int ima_queue_staged_delete_all(void);
> +int ima_queue_delete_partial(unsigned long req_value);
> int ima_restore_measurement_entry(struct ima_template_entry *entry);
> int ima_restore_measurement_list(loff_t bufsize, void *buf);
> int ima_measurements_show(struct seq_file *m, void *v);
> diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
> index 96d7503a605b..174a94740da1 100644
> --- a/security/integrity/ima/ima_fs.c
> +++ b/security/integrity/ima/ima_fs.c
> @@ -28,6 +28,7 @@
> * Requests:
> * 'A\n': stage the entire measurements list
> * 'D\n': delete all staged measurements
> + * '[1, ULONG_MAX]\n' delete N measurements records
> */
> #define STAGED_REQ_LENGTH 21
>
> @@ -343,6 +344,7 @@ static ssize_t _ima_measurements_write(struct file *file,
> loff_t *ppos, bool staged_interface)
> {
> char req[STAGED_REQ_LENGTH];
> + unsigned long req_value;
> int ret;
>
> if (datalen < 2 || datalen > STAGED_REQ_LENGTH)
> @@ -370,7 +372,24 @@ static ssize_t _ima_measurements_write(struct file *file,
> ret = ima_queue_staged_delete_all();
> break;
> default:
> - ret = -EINVAL;
> + if (staged_interface)
> + return -EINVAL;
> +
> + if (ima_flush_htable) {
> + pr_debug("Deleting staged N measurements not supported when flushing the hash table is requested\n");
> + return -EINVAL;
> + }
> +
> + ret = kstrtoul(req, 10, &req_value);
> + if (ret < 0)
> + return ret;
> +
> + if (req_value == 0) {
> + pr_debug("Must delete at least one entry\n");
> + return -EINVAL;
> + }
> +
> + ret = ima_queue_delete_partial(req_value);
> }
>
> if (ret < 0)
> @@ -379,6 +398,12 @@ static ssize_t _ima_measurements_write(struct file *file,
> return datalen;
> }
>
> +static ssize_t ima_measurements_write(struct file *file, const char __user *buf,
> + size_t datalen, loff_t *ppos)
> +{
> + return _ima_measurements_write(file, buf, datalen, ppos, false);
> +}
> +
> static ssize_t ima_measurements_staged_write(struct file *file,
> const char __user *buf,
> size_t datalen, loff_t *ppos)
> @@ -389,6 +414,7 @@ static ssize_t ima_measurements_staged_write(struct file *file,
> static const struct file_operations ima_measurements_ops = {
> .open = ima_measurements_open,
> .read = seq_read,
> + .write = ima_measurements_write,
> .llseek = seq_lseek,
> .release = ima_measurements_release,
> };
> @@ -470,6 +496,7 @@ static int ima_ascii_measurements_open(struct inode *inode, struct file *file)
> static const struct file_operations ima_ascii_measurements_ops = {
> .open = ima_ascii_measurements_open,
> .read = seq_read,
> + .write = ima_measurements_write,
> .llseek = seq_lseek,
> .release = ima_measurements_release,
> };
> @@ -603,14 +630,13 @@ static int __init create_securityfs_measurement_lists(bool staging)
> {
> const struct file_operations *ascii_ops = &ima_ascii_measurements_ops;
> const struct file_operations *binary_ops = &ima_measurements_ops;
> - umode_t permissions = (S_IRUSR | S_IRGRP);
> + umode_t permissions = (S_IRUSR | S_IRGRP | S_IWUSR | S_IWGRP);
> const char *file_suffix = "";
> int count = NR_BANKS(ima_tpm_chip);
>
> if (staging) {
> ascii_ops = &ima_ascii_measurements_staged_ops;
> binary_ops = &ima_measurements_staged_ops;
> - permissions |= (S_IWUSR | S_IWGRP);
> file_suffix = "_staged";
> }
>
> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
> index af0502f27d57..718991ba8bcd 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -405,6 +405,69 @@ int ima_queue_staged_delete_all(void)
> return 0;
> }
>
> +/**
> + * ima_queue_delete_partial - Delete current measurements
> + * @req_value: Number of measurements to delete
> + *
> + * Delete the requested number of measurements from the current measurements
> + * list, and update the number of records and the binary run-time size
> + * accordingly.
> + *
> + * Refuse to delete current measurements if measurement is suspended, so that
> + * dump can be done in a lockless way and user space is notified about current
> + * measurements being carried over to the secondary kernel, so that it does not
> + * save them twice.
> + *
> + * Return: Zero on success, a negative value otherwise.
> + */
> +int ima_queue_delete_partial(unsigned long req_value)
> +{
> + unsigned long req_value_copy = req_value;
> + unsigned long size_to_remove = 0, num_to_remove = 0;
> + LIST_HEAD(ima_measurements_trim);
> + struct ima_queue_entry *qe;
> + int ret = 0;
> +
> + /*
> + * list_for_each_entry_rcu() without rcu_read_lock() is fine because
> + * only list append can happen concurrently. No list replace due to the
> + * staging/delete writers mutual exclusion.
> + */
> + list_for_each_entry_rcu(qe, &ima_measurements, later, true) {
> + size_to_remove += get_binary_runtime_size(qe->entry);
> + num_to_remove++;
> +
> + if (--req_value_copy == 0)
> + break;
> + }
> +
> + /* Not enough records to delete. */
> + if (req_value_copy > 0)
> + return -ENOENT;
> +
> + mutex_lock(&ima_extend_list_mutex);
> + if (ima_measurements_suspended) {
> + mutex_unlock(&ima_extend_list_mutex);
> + return -ESTALE;
> + }
> +
> + /*
> + * qe remains valid because ima_fs.c enforces single-writer exclusion.
> + */
> + __list_cut_position(&ima_measurements_trim, &ima_measurements,
> + &qe->later);
> +
> + atomic_long_sub(num_to_remove, &ima_num_records[BINARY]);
> +
> + if (IS_ENABLED(CONFIG_IMA_KEXEC))
> + binary_runtime_size[BINARY] -= size_to_remove;
> +
> + mutex_unlock(&ima_extend_list_mutex);
> +
> + ima_queue_delete(&ima_measurements_trim, false);
> + return ret;
> +}
> +
> /**
> * ima_queue_delete - Delete measurements
> * @head: List head measurements are deleted from
^ permalink raw reply
* Re: [PATCH net-next V2 7/7] devlink: Add eswitch mode boot defaults
From: Mark Bloch @ 2026-06-04 1:16 UTC (permalink / raw)
To: Randy Dunlap, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, David S. Miller
Cc: Jonathan Corbet, Shuah Khan, Jiri Pirko, Simon Horman,
Sunil Goutham, Linu Cherian, Geetha sowjanya, hariprasad,
Subbaraya Sundeep, Bharat Bhushan, Saeed Mahameed,
Leon Romanovsky, Tariq Toukan, Borislav Petkov (AMD),
Andrew Morton, Peter Zijlstra (Intel), Thomas Gleixner,
Petr Mladek, Tejun Heo, Vlastimil Babka, Feng Tang, Dave Hansen,
Christian Brauner, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, Li RongQing, Paul E. McKenney, Ethan Nelson-Moore,
linux-doc, linux-kernel, netdev, linux-rdma
In-Reply-To: <d276e842-dd8f-40b7-806b-71572503005e@infradead.org>
On 03/06/2026 23:06, Randy Dunlap wrote:
> Hi.
>
> On 6/3/26 12:32 PM, Mark Bloch wrote:
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 063c11ca33e5..7af9f2898d92 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1264,6 +1264,31 @@ Kernel parameters
>> dell_smm_hwmon.fan_max=
>> [HW] Maximum configurable fan speed.
>>
>> + devlink_eswitch_mode=
>> + [NET]
>> + Format:
>> + [<selector>]:<mode>
>
> It appears (please correct me if I am mistaken) that the '[' and ']'
> above don't mean "optional" but instead they are required characters...
>
>> +
>> + <selector>:
>> + * | <handle>[,<handle>...]
>
> while here they mean "optional".
>
> That is confusing (inconsistent). Also, if the square brackets are
> always required around the <selector>, what purpose do they serve?
Yes, you are right, this is confusing. The outer square brackets are part of
the syntax and are required, while the brackets in "[,<handle>...]" mean that
additional handles are optional.
I couldn't find a better way to describe this. What I want to say is that the
selector is always wrapped in square brackets. Inside the brackets it can either
be "*" to match all devices, or a comma separated list of handles. If "*" is
not used, then at least one handle has to be provided.
Maybe it would be clearer to spell it out explicitly, something like:
Format:
[<selector>]:<mode>
The '[' and ']' characters are literal and required.
<selector>:
* | <handle>[,<handle>...]
If '*' is not used, <selector> must contain at least one <handle>.
Does that sound like a reasonable way to document it?
Mark
>
>> +
>> + <handle>:
>> + <bus-name>/<dev-name>
>> +
>> + Configure default devlink eswitch mode for matching
>> + devlink instances during device initialization.
>> +
>> + <mode>:
>> + legacy | switchdev | switchdev_inactive
>> +
>> + Examples:
>> + devlink_eswitch_mode=[*]:switchdev
>> + devlink_eswitch_mode=[pci/0000:08:00.0]:switchdev
>> + devlink_eswitch_mode=[pci/0000:08:00.0,pci/0000:09:00.1]:legacy
>> +
>> + See Documentation/networking/devlink/devlink-defaults.rst
>> + for the full syntax.
>> +
>> dfltcc= [HW,S390]
>> Format: { on | off | def_only | inf_only | always }
>> on: s390 zlib hardware support for compression on
>
>
^ permalink raw reply
* Re: [PATCH v3 1/4] mm/zswap: Make shrink_worker writeback cursor per-memcg
From: Hao Jia @ 2026-06-04 1:58 UTC (permalink / raw)
To: Yosry Ahmed
Cc: akpm, tj, hannes, shakeel.butt, mhocko, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin, cgroups, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <aiBpibRNi0BcM1Zu@google.com>
On 2026/6/4 01:53, Yosry Ahmed wrote:
> On Wed, Jun 03, 2026 at 11:02:54AM +0800, Hao Jia wrote:
>>
>>
>> On 2026/6/3 07:19, Yosry Ahmed wrote:
>>>>>>>> Proactive writeback also wants a similar per-memcg cursor that is
>>>>>>>> scoped to the specified memcg, so that repeated invocations against
>>>>>>>> the same memcg make forward progress across its descendant memcgs
>>>>>>>> instead of restarting from the first child memcg each time.
>>>>>>>
>>>>>>> Is this a problem in practice?
>>>>>>>
>>>>>>> Is the concern the overhead of scanning memcgs repeatedly, or lack of
>>>>>>> fairness? I wonder if we should just do writeback in batches from all
>>>>>>> memcgs, similar to how reclaim does it, then evaluate at the end if we
>>>>>>> need to start over?
>>>>>>>
>>>>>>
>>>>>> Not using a per-cgroup cursor will cause issues for "repeated small-budget
>>>>>> calls" cases. For example, repeatedly triggering a 2MB writeback might
>>>>>> result in only writing back pages from the first few child memcgs every
>>>>>> time. In the worst-case scenario (where the writeback amount is less than
>>>>>> WB_BATCH), it might only ever write back from the first child memcg.
>>>>>
>>>>> Right, so a fairness concern?
>>>>>
>>>>> I wonder if we should just reclaim a batch from each memcg, then check
>>>>> if we reached the goal, otherwise start over. If the batch size is small
>>>>> enough that should work?
>>>>
>>>> Even with a small batch size, for small writeback requests triggered by
>>>> user-space (e.g., 2MB, which is batch size * N), it might still repeatedly
>>>> write back from only the first N child memcgs.
>>>
>>> Yes, I understand, I am asking if this is a problem in practice. For
>>> this to be a problem we'd need to trigger small writeback requests and
>>> have many memcgs.
>>>
>>>> This could cause the user-space agent to prematurely give up on zswap
>>>> writeback.
>>>
>>> Why? The kernel should not return before trying to writeback from all
>>> memcgs. If we scan the first N child memcgs and did not writeback
>>> enough, we should keep going, right?
>>>
>>
>> Yes, this issue is not caused by the kernel, but rather by our user-space
>> agent itself.
>>
>> For instance, suppose a parent memcg has two children, memcg1 and memcg2,
>> each with 200MB of zswap (100MB inactive). Triggering proactive writeback on
>> the parent memcg will exhaust memcg1's inactive zswap pages. After that,
>> even though memcg2 still has plenty of inactive zswap pages, it will
>> continue to write back memcg1's active zswap pages. Writing back active
>> zswap pages causes the user-space agent to prematurely abort the writeback
>> because it detects that certain memcg metrics have exceeded predefined
>> thresholds.
>
> This will only happen if the reclaim size is smaller than the batch
> size, right? Otherwise the kernel should reclaim more or less equally
> from both memcgs?
>
I gave it some thought. Not using a cursor could lead to unfairness
issues with certain writeback sizes:
- If the writeback size is an odd multiple of WB_BATCH (e.g.,
triggering a writeback of 3 * WB_BATCH), with 2 child cgroups, the
writeback ratio might end up being 2:1.
- If a memcg has 5 child cgroups and a writeback of 2 * WB_BATCH is
triggered, it might repeatedly write back from only the first 2 child
cgroups.
Although setting a smaller WB_BATCH might mitigate this unfairness, it
could hurt writeback efficiency. Let's just use per-memcg cursors to
completely fix these corner cases.
Thanks,
Hao
>> Of course, real-world scenarios are much more complex, and this kind of case
>> is extremely rare in our environment.
>>
>> That being said, your suggestion of using the global lock for the per-memcg
>> cursors makes the writeback fairer and would resolve these corner cases.
>
> Right, but I'd rather not do per-memcg cursors at all if we can avoid
> it. Will using batches help make reclaim fair over all memcgs without a
> cursor?
>
> We can always add the cursor later if needed.
^ permalink raw reply
* Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback
From: Hao Jia @ 2026-06-04 2:11 UTC (permalink / raw)
To: Nhat Pham, Yosry Ahmed
Cc: Johannes Weiner, akpm, tj, shakeel.butt, mhocko, mkoutny,
chengming.zhou, muchun.song, roman.gushchin, cgroups, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <CAKEwX=OhxUxRCEfvZMnWzXy=Fa4jgzL3DuP-RmaVzdK65m4bew@mail.gmail.com>
On 2026/6/4 02:14, Nhat Pham wrote:
> On Wed, Jun 3, 2026 at 10:58 AM Yosry Ahmed <yosry@kernel.org> wrote:
>>
>> On Wed, Jun 03, 2026 at 07:22:36PM +0800, Hao Jia wrote:
>>>
>>>
>>> On 2026/5/30 09:40, Yosry Ahmed wrote:
>>>> On Fri, May 29, 2026 at 12:58:09PM -0700, Nhat Pham wrote:
>>>>> On Tue, May 26, 2026 at 4:46 AM Hao Jia <jiahao.kernel@gmail.com> wrote:
>>>>>>
>>>>>> From: Hao Jia <jiahao1@lixiang.com>
>>>>>>
>>>>>> Zswap currently writes back pages to backing swap reactively, triggered
>>>>>> either by the shrinker or when the pool reaches its size limit. There is
>>>>>> no mechanism to control the amount of writeback for a specific memory
>>>>>> cgroup. However, users may want to proactively write back zswap pages,
>>>>>> e.g., to free up memory for other applications or to prepare for
>>>>>> memory-intensive workloads.
>>>>>>
>>>>>> Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup
>>>>>> interface. When specified, this key bypasses standard memory reclaim
>>>>>> and exclusively performs proactive zswap writeback up to the requested
>>>>>> budget. If omitted, the default reclaim behavior remains unchanged.
>>>>>>
>>>>>> Example usage:
>>>>>> # Write back 100MB of pages from zswap to the backing swap
>>>>>> echo "100M zswap_writeback_only" > memory.reclaim
>>>>>
>>>>> Hmmm, so this 100MB is the pre-compression size? i.e if this 100 MB
>>>>> compresses to 25 MB, then you're only freeing 25 MB?
>>>>>
>>>>> I'm ok-ish with this, but can you document it?
>>>>
>>>> That's a good point. I think pre-compressed size doesn't make sense to
>>>> be honest. We should care about how much memory we are actually trying
>>>> to save by doing writeback here.
>>>>
>>>> The pre-compressed size is only useful in determining the blast radius,
>>>> how many actual pages are going to have slower page faults now. But
>>>> then, I don't think there's a reasonable way for userspace to decide
>>>> that.
>>>>
>>>> I understand passing in the compressed size is tricky because we need to
>>>> keep track of the size of the compressed pages we end up writing back,
>>>> but it should be doable.
>>>
>>> Agreed. Using pre-compressed size is probably easier to implement. IIRC,
>>> interfaces like ZRAM writeback_limit are also calculated using the
>>> pre-compressed size.
>>>
>>> I'll clarify this in the documentation in the next version.
>>>
>>>>
>>>> If we really want pre-compressed size here, then yes we need to make it
>>>> very clear, and I vote that we use a separate interface in this case
>>>> because memory.reclaim having different meanings for the amount of
>>>> memory written to it is extremely counter-intuitive.
>>>>
>>> Agree. This would indeed break the semantics of memory.reclaim. I will use a
>>> separate interface for proactive writeback in the next version.
>>
>> But doesn't it make more sense to specify the compressed size, which is
>> ultimately the amount of memory you actually want to reclaim.
>>
>
> I personally prefer compressed size to pre-compressed size. That's
> kinda what user cares about, no?
>
> One thing we can do is let users prescribe a compressed size, but
> internally, we can multiply that by the average compression ratio.
> That gives us a guesstimate of how many pages we need to reclaim, and
> you can follow the rest of your implementation as is (perhaps with
> short-circuit when we reach the goal with fewer pages reclaimed).
Got it. I will change it to use the compressed size in the next version.
Yosry, Nhat, should we continue using the zswap_writeback_only key to
trigger proactive writeback?
Thanks,
Hao
^ permalink raw reply
* Re: [PATCH] docs: pt_BR: update "Purpose of Defconfigs" section in maintainer-soc.rst
From: Daniel Pereira @ 2026-06-04 2:51 UTC (permalink / raw)
To: Amanda Corrêa; +Cc: linux-doc
In-Reply-To: <20260604002212.42092-1-amandacorreasilvax@gmail.com>
Em qua., 3 de jun. de 2026 às 21:22, Amanda Corrêa
<amandacorreasilvax@gmail.com> escreveu:
> +Propósito do Defconfigs
> +~~~~~~~~~~~~~~~~~~~~~~~
I notice that the phrase "Propósito do Defconfigs" is grammatically
incorrect because "defconfigs" is plural.
In my view, the correct form should be "Propósito dos Defconfigs" to
maintain proper plural agreement.
> +Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
> +distribuições têm suas próprias configurações. Uma mudança que adiciona novas
> +opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
> +em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
> +suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
> +para máquinas não upstream não deve ser aceito.
The original text explicitly states "upstream-supported
machine/board". It is fundamental to include the term
"no upstream" in the Portuguese translation to make it clear that the
machine or device must already be accepted in the main development
tree.
Additionally, I suggest using "dispositivo" instead of "placa", as
translating "board" literally to "placa"
in Portuguese can sound ambiguous (often confused with an expansion
card like a GPU). In our technical jargon, "dispositivo"
is much more precise for embedded hardware.
^ permalink raw reply
* [PATCH v2] docs: pt_BR: update "Purpose of Defconfigs" section in maintainer-soc.rst
From: Amanda Corrêa @ 2026-06-04 3:02 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Amanda Corrêa
This update includes the "Purpose of Defconfigs" section translated
to Brazilian Portuguese.
Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
---
v2:
- Adjust translation of section title to "Propósito dos Defconfigs"
for better clarity in Portuguese.
.../translations/pt_BR/process/maintainer-soc.rst | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-soc.rst b/Documentation/translations/pt_BR/process/maintainer-soc.rst
index 5a3ae213e..eb8040a62 100644
--- a/Documentation/translations/pt_BR/process/maintainer-soc.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-soc.rst
@@ -8,7 +8,7 @@ Visão Geral
-----------
O subsistema SoC é um local de agregação para códigos específicos de SoC
-System on Chip). Os principais componentes do subsistema são:
+(System on Chip). Os principais componentes do subsistema são:
* Devicetrees (DTS) para ARM de 32 e 64 bits e RISC-V.
* Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*).
@@ -220,3 +220,13 @@ A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita
usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve
descrição resumindo as alterações no pull request. Para mais detalhes sobre o
envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``.
+
+Propósito dos Defconfigs
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
+distribuições têm suas próprias configurações. Uma mudança que adiciona novas
+opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
+em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
+suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
+para máquinas não upstream não deve ser aceito.
--
2.43.0
^ permalink raw reply related
* [PATCH v3] docs: pt_BR: update "Purpose of Defconfigs" section in maintainer-soc.rst
From: Amanda Corrêa @ 2026-06-04 3:18 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Amanda Corrêa
This update includes the "Purpose of Defconfigs" section translated
to Brazilian Portuguese.
Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
---
v2:
- Adjust translation of section title to "Propósito dos Defconfigs"
for better clarity in Portuguese.
v3:
- Fix plural agreement in section title
- Clarify that the referenced device must be supported by upstream
.../translations/pt_BR/process/maintainer-soc.rst | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-soc.rst b/Documentation/translations/pt_BR/process/maintainer-soc.rst
index 5a3ae213e..eb8040a62 100644
--- a/Documentation/translations/pt_BR/process/maintainer-soc.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-soc.rst
@@ -8,7 +8,7 @@ Visão Geral
-----------
O subsistema SoC é um local de agregação para códigos específicos de SoC
-System on Chip). Os principais componentes do subsistema são:
+(System on Chip). Os principais componentes do subsistema são:
* Devicetrees (DTS) para ARM de 32 e 64 bits e RISC-V.
* Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*).
@@ -220,3 +220,13 @@ A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita
usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve
descrição resumindo as alterações no pull request. Para mais detalhes sobre o
envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``.
+
+Propósito dos Defconfigs
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
+distribuições têm suas próprias configurações. Uma mudança que adiciona novas
+opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
+em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
+suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
+para máquinas não upstream não deve ser aceito.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next V2 7/7] devlink: Add eswitch mode boot defaults
From: Randy Dunlap @ 2026-06-04 3:53 UTC (permalink / raw)
To: Mark Bloch, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, David S. Miller
Cc: Jonathan Corbet, Shuah Khan, Jiri Pirko, Simon Horman,
Sunil Goutham, Linu Cherian, Geetha sowjanya, hariprasad,
Subbaraya Sundeep, Bharat Bhushan, Saeed Mahameed,
Leon Romanovsky, Tariq Toukan, Borislav Petkov (AMD),
Andrew Morton, Peter Zijlstra (Intel), Thomas Gleixner,
Petr Mladek, Tejun Heo, Vlastimil Babka, Feng Tang, Dave Hansen,
Christian Brauner, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, Li RongQing, Paul E. McKenney, Ethan Nelson-Moore,
linux-doc, linux-kernel, netdev, linux-rdma
In-Reply-To: <e4aada53-fb80-41a8-9a8e-d19414f6466b@nvidia.com>
On 6/3/26 6:16 PM, Mark Bloch wrote:
>
>
> On 03/06/2026 23:06, Randy Dunlap wrote:
>> Hi.
>>
>> On 6/3/26 12:32 PM, Mark Bloch wrote:
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>>> index 063c11ca33e5..7af9f2898d92 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -1264,6 +1264,31 @@ Kernel parameters
>>> dell_smm_hwmon.fan_max=
>>> [HW] Maximum configurable fan speed.
>>>
>>> + devlink_eswitch_mode=
>>> + [NET]
>>> + Format:
>>> + [<selector>]:<mode>
>>
>> It appears (please correct me if I am mistaken) that the '[' and ']'
>> above don't mean "optional" but instead they are required characters...
>>
>>> +
>>> + <selector>:
>>> + * | <handle>[,<handle>...]
>>
>> while here they mean "optional".
>>
>> That is confusing (inconsistent). Also, if the square brackets are
>> always required around the <selector>, what purpose do they serve?
>
> Yes, you are right, this is confusing. The outer square brackets are part of
> the syntax and are required, while the brackets in "[,<handle>...]" mean that
> additional handles are optional.
>
> I couldn't find a better way to describe this. What I want to say is that the
> selector is always wrapped in square brackets. Inside the brackets it can either
> be "*" to match all devices, or a comma separated list of handles. If "*" is
> not used, then at least one handle has to be provided.
>
> Maybe it would be clearer to spell it out explicitly, something like:
>
> Format:
> [<selector>]:<mode>
>
> The '[' and ']' characters are literal and required.
>
> <selector>:
> * | <handle>[,<handle>...]
>
> If '*' is not used, <selector> must contain at least one <handle>.
>
> Does that sound like a reasonable way to document it?
Yes, that helps a little bit. Better than nothing.
But why are they required at all?
>>> +
>>> + <handle>:
>>> + <bus-name>/<dev-name>
>>> +
>>> + Configure default devlink eswitch mode for matching
>>> + devlink instances during device initialization.
>>> +
>>> + <mode>:
>>> + legacy | switchdev | switchdev_inactive
>>> +
>>> + Examples:
>>> + devlink_eswitch_mode=[*]:switchdev
>>> + devlink_eswitch_mode=[pci/0000:08:00.0]:switchdev
>>> + devlink_eswitch_mode=[pci/0000:08:00.0,pci/0000:09:00.1]:legacy
>>> +
>>> + See Documentation/networking/devlink/devlink-defaults.rst
>>> + for the full syntax.
>>> +
>>> dfltcc= [HW,S390]
>>> Format: { on | off | def_only | inf_only | always }
>>> on: s390 zlib hardware support for compression on
>>
>>
>
--
~Randy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox