The number of SYN + MPC retransmissions before falling back to TCP was
fixed to 2. This is certainly a good default value, but having a fixed
number can be a problem in some environments.

The current behaviour means that if all packets are dropped, there will
be:

- The initial SYN + MPC

- 2 retransmissions with MPC

- The next ones will be without MPTCP.

So typically ~3 seconds before falling back to TCP. In some networks
where some temporally blackholes are unfortunately frequent, or when a
client tries to initiate connections while the network is not ready yet,
this can cause new connections not to have MPTCP connections.

In such environments, it is now possible to increase the number of SYN
retransmissions with MPTCP options to make sure MPTCP is used.

Interesting values are:

- 0: the first retransmission will be done without MPTCP options: quite
     aggressive, but also a higher risk of detecting false-positive
     MPTCP blackholes.

- >= 128: all SYN retransmissions will keep the MPTCP options: back to
          the < 6.12 behaviour.

The default behaviour is not changed here.

Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20250117-net-next-mptcp-syn_retrans_before_tcp_fallback-v1-1-ab4b187099b0@kernel.org


Signed-off-by: Jakub Kicinski <kuba@kernel.org>

For packets with two-step timestamp requests, the hardware timestamp
comes back to the driver through a confirmation mechanism of sorts,
which allows the driver to confidently bump the successful "pkts"
counter.

For one-step PTP, the NIC is supposed to autonomously insert its
hardware TX timestamp in the packet headers while simultaneously
transmitting it. There may be a confirmation that this was done
successfully, or there may not.

None of the current drivers which implement ethtool_ops :: get_ts_stats()
also support HWTSTAMP_TX_ONESTEP_SYNC or HWTSTAMP_TX_ONESTEP_SYNC, so it
is a bit unclear which model to follow. But there are NICs, such as DSA,
where there is no transmit confirmation at all. Here, it would be wrong /
misleading to increment the successful "pkts" counter, because one-step
PTP packets can be dropped on TX just like any other packets.

So introduce a special counter which signifies "yes, an attempt was made,
but we don't know whether it also exited the port or not". I expect that
for one-step PTP packets where a confirmation is available, the "pkts"
counter would be bumped.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20250116104628.123555-2-vladimir.oltean@nxp.com


Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Introduce a new property to describe the power budget of the regulator.
This property will allow power management support for regulator consumers
like PSE controllers, enabling them to make decisions based on the
available power capacity.

Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20250115-feature_regulator_pw_budget-v2-2-0a44b949e6bc@bootlin.com


Signed-off-by: Mark Brown <broonie@kernel.org>

Problem: The x86_64 UEFI doc references Elilo which is an
unmaintained/orphaned bootloader project. Also, on x86_64 a bootloader
is technically not actually required since there is support for the
Linux EFI stub.

Solution: Remove the references to Elilo from the doc and refer to the
EFI stub doc page, update steps accordingly, and add more details about
creation of the EFI partition to improve clarity.

Signed-off-by: Nir Lichtman <nir@lichtman.org>
Link: https://lore.kernel.org/r/20250108113522.GA897677@lichtman.org


Signed-off-by: Jonathan Corbet <corbet@lwn.net>

There is no mention of timer_migration in the docs. Add
a short description.

Signed-off-by: Phil Auld <pauld@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250114190525.169022-1-pauld@redhat.com

"zone_t" doesn't exist in current code base anymore, remove the
description of it.

Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250115070355.41769-1-richard120310@gmail.com

The hds-thresh option configures the threshold value of
the header-data-split.
If a received packet size is larger than this threshold value, a packet
will be split into header and payload.
The header indicates TCP and UDP header, but it depends on driver spec.
The bnxt_en driver supports HDS(Header-Data-Split) configuration at
FW level, affecting TCP and UDP too.
So, If hds-thresh is set, it affects UDP and TCP packets.

Example:
   # ethtool -G <interface name> hds-thresh <value>

   # ethtool -G enp14s0f0np0 tcp-data-split on hds-thresh 256
   # ethtool -g enp14s0f0np0
   Ring parameters for enp14s0f0np0:
   Pre-set maximums:
   ...
   HDS thresh:  1023
   Current hardware settings:
   ...
   TCP data split:         on
   HDS thresh:  256

The default/min/max values are not defined in the ethtool so the drivers
should define themself.
The 0 value means that all TCP/UDP packets' header and payload
will be split.

Tested-by: Stanislav Fomichev <sdf@fomichev.me>
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Link: https://patch.msgid.link/20250114142852.3364986-3-ap420073@gmail.com


Signed-off-by: Jakub Kicinski <kuba@kernel.org>

We are now using the on-chip PMU node for power sequencing to manage the
enable/disable functionality of Bluetooth. Consequently, the inputs
previously marked as required under the Bluetooth node can be removed.

For instance, the enable GPIO is now managed by the PMU node with the
property bt-enable-gpios.

Signed-off-by: Janaki Ramaiah Thota <quic_janathot@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Expand the firmware-name property to specify the names of NVM and
rampatch firmware to load. This update will support loading specific
firmware (nvm and rampatch) for certain chips, like the QCA6698
Bluetooth chip, which shares the same IP core as the WCN6855 but has
different RF components and RAM sizes, requiring new firmware files.

We might use different connectivity boards on the same platform. For
example, QCA6698-based boards can support either a two-antenna or
three-antenna solution, both of which work on the sa8775p-ride platform.
Due to differences in connectivity boards and variations in RF
performance from different foundries, different NVM configurations are
used based on the board ID.

So In firmware-name, if the NVM file has an extension, the NVM file will
be used. Otherwise, the system will first try the .bNN (board ID) file,
and if that fails, it will fall back to the .bin file.

Possible configurations:
firmware-name = "QCA6698/hpnv21.bin", "QCA6698/hpbtfw21.tlv";
firmware-name = "QCA6698/hpnv21", "QCA6698/hpbtfw21.tlv";
firmware-name = "QCA6698/hpnv21.bin";

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Cheng Jiang <quic_chejiang@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

This compatible was only added to the list for compatibility with older
dtschema (<2024.02). Add it to the other list also so both new and old
tools work.

Fixes: 0d078d47 ("dt-bindings: mfd: syscon: Add ti,j784s4-acspcie-proxy-ctrl compatible")
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Link: https://lore.kernel.org/r/20250103174524.28768-2-afd@ti.com


Signed-off-by: Lee Jones <lee@kernel.org>

This compatible seems to be missing the last 'e', looks to be a typo
when creating this file. Noticed this when diff'ing the two compatible
lists (which should stay in sync).

Fixes: f97b0435 ("dt-bindings: mfd: syscon: Split and enforce documenting MFD children")
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250103174524.28768-4-afd@ti.com


Signed-off-by: Lee Jones <lee@kernel.org>

These are flags to be passed when linking proc macros for the Rust
toolchain. If unset, it defaults to $(KBUILD_HOSTLDFLAGS).

This is needed because the list of flags to link hostprogs is not
necessarily the same as the list of flags used to link libmacros.so.
When we build proc macros, we need the latter, not the former (e.g. when
using a Rust compiler binary linked to a different C library than host
programs).

To distinguish between the two, introduce this new variable to stand
out from KBUILD_HOSTLDFLAGS used to link other host progs.

Signed-off-by: HONG Yifan <elsk@google.com>
Link: https://lore.kernel.org/r/20241017210430.2401398-2-elsk@google.com


[ v3:

  - `export`ed the variable. Otherwise it would not be visible in
    `rust/Makefile`.

  - Removed "additional" from the documentation and commit message,
    since this actually replaces the other flags, unlike other cases.

  - Added example of use case to documentation and commit message.
    Thanks Alice for the details on what Google needs!

  - Instead of `HOSTLDFLAGS`, used `KBUILD_HOSTLDFLAGS` as the fallback
    to preserve the previous behavior as much as possible, as discussed
    with Alice/Yifan. Thus moved the variable down too (currently we
    do not modify `KBUILD_HOSTLDFLAGS` elsewhere) and avoided
    mentioning `HOSTLDFLAGS` directly in the documentation.

  - Fixed documentation header formatting.

  - Reworded slightly.

         - Miguel ]
Tested-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: HONG Yifan <elsk@google.com>
Acked-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20241112184455.855133-1-ojeda@kernel.org


Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Commit b168ed45 ("kernel/cgroup: Add "dmem" memory accounting
cgroup") introduced a new documentation file, with a shorter than
expected underline. This results in a documentation build warning. Fix
that underline length.

Fixes: b168ed45 ("kernel/cgroup: Add "dmem" memory accounting cgroup")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/r/20250113154611.624256bf@canb.auug.org.au/


Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20250113092608.1349287-4-mripard@kernel.org


Signed-off-by: Maxime Ripard <mripard@kernel.org>

Commit b168ed45 ("kernel/cgroup: Add "dmem" memory accounting
cgroup") introduced a new documentation file, but didn't link it
anywhere. It was thus triggering a documentation build warning. Make
sure it's included as part of the DRM documentation.

Fixes: b168ed45 ("kernel/cgroup: Add "dmem" memory accounting cgroup")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/r/20250113155000.4a99e7b0@canb.auug.org.au/


Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20250113092608.1349287-3-mripard@kernel.org


Signed-off-by: Maxime Ripard <mripard@kernel.org>

As announced back in April, require running upstream tests
to maintain Supported status for NIC drivers:

  https://lore.kernel.org/20240425114200.3effe773@kernel.org



Multiple vendors have been "working on it" for months.
Let's make it official.

Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250111024359.3678956-1-kuba@kernel.org


Signed-off-by: Jakub Kicinski <kuba@kernel.org>

The function graph tracer now calculates the calltime internally and for
each instance. If there are two instances that are running function graph
tracer and are tracing the same functions, the timings of the length of
those functions may be slightly different:

 # trace-cmd record -B foo -p function_graph -B bar -p function_graph sleep 5
 # trace-cmd report
[..]
bar:            sleep-981   [000] ...1.  1101.109027: funcgraph_entry:        0.764 us   |          mutex_unlock(); (ret=0xffff8abcc256c300)
foo:            sleep-981   [000] ...1.  1101.109028: funcgraph_entry:        0.748 us   |          mutex_unlock(); (ret=0xffff8abcc256c300)
bar:            sleep-981   [000] .....  1101.109029: funcgraph_exit:         2.456 us   |        } (ret=0xffff8abcc256c300)
foo:            sleep-981   [000] .....  1101.109029: funcgraph_exit:         2.403 us   |        } (ret=0xffff8abcc256c300)
bar:            sleep-981   [000] d..1.  1101.109031: funcgraph_entry:        0.844 us   |  fpregs_assert_state_consistent(); (ret=0x0)
foo:            sleep-981   [000] d..1.  1101.109032: funcgraph_entry:        0.803 us   |  fpregs_assert_state_consistent(); (ret=0x0)

Link: https://lore.kernel.org/all/20250114101806.b2778cb01f34f5be9d23ad98@kernel.org/



Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Suggested-by: Masami Hiramatsu <mhiramat@kernel.org>
Link: https://lore.kernel.org/20250114101202.02e7bc68@gandalf.local.home


Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>

Replace generic instructions for monitoring error counters with a
procedure using the unified PHY statistics interface (`--all-groups`).

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Introduce a new way to report PHY statistics in a structured and
standardized format using the netlink API. This new method does not
replace the old driver-specific stats, which can still be accessed with
`ethtool -S <eth name>`. The structured stats are available with
`ethtool -S <eth name> --all-groups`.

This new method makes it easier to diagnose problems by organizing stats
in a consistent and documented way.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Add HW Steering mode to mlx5 devlink param of steering mode options.

Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20250109160546.1733647-14-tariqt@nvidia.com


Signed-off-by: Jakub Kicinski <kuba@kernel.org>

After commit 38f83090 ("cpuidle: menu: Remove iowait influence") and
other previous changes, the description of the menu governor in the
documentation does not match the code any more, so update it as
appropriate.

Fixes: 38f83090 ("cpuidle: menu: Remove iowait influence")
Fixes: 5484e31b ("cpuidle: menu: Skip tick_nohz_get_sleep_length() call in some cases")
Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/12589281.O9o76ZdvQC@rjwysocki.net

Tags are really appreciated by maintainers in general, since it means
someone is willing to put their name on a commit, be it as a reviewer,
tester, etc.

However, signers (i.e. submitters carrying tags from previous versions
and maintainers applying patches) may need to take or drop tags, on a
case-by-case basis, for different reasons.

Yet this is not explicitly spelled out in the documentation, thus there
may be instances [1] where contributors may feel unwelcome.

Thus, to clarify, state this clearly.

Link: https://lore.kernel.org/rust-for-linux/CAEg-Je-h4NitWb2ErFGCOqt0KQfXuyKWLhpnNHCdRzZdxi018Q@mail.gmail.com/

 [1]
Suggested-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250112152946.761150-4-ojeda@kernel.org

Newcomers to the kernel need to learn the different tags that are
used in commit messages and when to apply them. Acked-by is sometimes
misunderstood, since the documentation did not really clarify (up to
the previous commit) when it should be used, especially compared to
Reviewed-by.

The previous commit already clarified who the usual providers of Acked-by
tags are, with examples. Thus provide a clarification paragraph for
the comparison with Reviewed-by, and give a couple examples reusing the
cases given above, in the previous commit.

Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250112152946.761150-3-ojeda@kernel.org

Acked-by is typically used by maintainers. However, sometimes it is
useful to be able to accept the tag from other stakeholders that may not
have done a deep technical review or may not be kernel developers. For
instance:

  - People with domain knowledge, such as the original author of the
    code being modified.

  - Userspace-side reviewers for a kernel uAPI patch, like in DRM --
    see Documentation/gpu/drm-uapi.rst:

    > The userspace-side reviewer should also provide an Acked-by on the
    > kernel uAPI patch indicating that they believe the proposed uAPI
    > is sound and sufficiently documented and validated for userspace's
    > consumption.

  - Key users of a feature, such as in [1].

Thus clarify that Acked-by may be used by other stakeholders (but most
commonly by maintainers).

Since, in these cases, it may be confusing why an Acked-by is/was
provided, allow and suggest to provide a "# Suffix" explaining it.

The "# Suffix" for Acked-by is already being used to clarify what part
of the patch a maintainer is acknowledging, thus also mention "# Suffix"
in the relevant paragraph.

Link: https://lore.kernel.org/rust-for-linux/CANiq72m4fea15Z0fFZauz8N2madkBJ0G7Dc094OwoajnXmROOA@mail.gmail.com/

 [1]
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250112152946.761150-2-ojeda@kernel.org

At the bottom of the bug-hunting.rst file there is a "signature" which
doesn't seem to make much sense.  It seems to predate git, and perhaps
was from an earlier bug report that got copied into the document, but
now makes no sense so remove it.

Cc: greg@wind.rmcc.com
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Alex Shi <alexs@kernel.org>
Cc: Yanteng Si <si.yanteng@linux.dev>
Cc: Hu Haowen <2023002089@link.tyut.edu.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/2025011005-resistant-uncork-9814@gregkh

Translate lwn/Documentation/security/sak.rst into Chinese

Update the translation through commit 4d3beaa0
("docs: security: move some books to it and update")

Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
Reviewed-by: Alex Shi <alexs@kernel.org>
Signed-off-by: zhangwei <zhangwei@cqsoftware.com.cn>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250110100405.2225-1-zhangwei@cqsoftware.com.cn

The arm64 'memory.rst' file tries to document the virtual memory map
and the translation procedure for a couple of kernel configurations.

Unfortunately, the virtual memory map changes relatively frequently and
we support considerably more configurations than we did when the docs
were introduced (e.g. we now have support for 16KiB pages and 52-bit
addressing). Furthermore, the Arm ARM is the definitive resource for the
translation procedure and so there's little point in duplicating part
of that information in the kernel documentation.

Rather than continue trying (and failing) to maintain these diagrams,
let's rip them out. The kernel page-table can be dumped using
CONFIG_PTDUMP_DEBUGFS if necesssary.

Link: https://lore.kernel.org/r/20250102065554.1533781-1-sangmoon.kim@samsung.com


Reported-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Signed-off-by: Will Deacon <will@kernel.org>

This is for the MPC831{4,5}{,E} SoCs.

Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250102-mpc83xx-v1-11-86f78ba2a7af@posteo.net


Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

From looking at the data sheets, it is not obvious that CS# and latch
clock can be treated at the same, but doing so works fine and saves the
hassle of (1) trying to specify a SPI device without CS, and (2) adding
another property to drive the latch clock[1].

[1]: https://lore.kernel.org/lkml/20241213-gpio74-v1-2-fa2c089caf41@posteo.net/



Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20241224-gpio74-v2-3-bbcf14183191@posteo.net


Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add a documentation file
(Documentation/nvme/nvme-pci-endpoint-target.rst) for the new NVMe PCI
endpoint target driver. This provides an overview of the driver
requirements, capabilities and limitations. A user guide describing how
to setup a NVMe PCI endpoint device using this driver is also provided.

This document is made accessible also from the PCI endpoint
documentation using a link. Furthermore, since the existing nvme
documentation was not accessible from the top documentation index, an
index file is added to Documentation/nvme and this index listed as
"NVMe Subsystem" in the "Storage interfaces" section of the subsystem
API index.

Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Keith Busch <kbusch@kernel.org>

The SRAM memory shared pointed to by the st,gcan property is unique, so
we don't need an array of phandles.

Fixes: e43250c0 ("dt-bindings: net: can: add STM32 bxcan DT bindings")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20241228150043.3926696-1-dario.binacchi@amarulasolutions.com


Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Move python code to a separate directory so it can be
packaged as a python module. Updates existing references
in selftests and docs.

Also rename ynl-gen-[c|rst] to ynl_gen_[c|rst], avoid
dashes as these prevent easy imports for entrypoints.

Signed-off-by: Jan Stancek <jstancek@redhat.com>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/a4151bad0e6984e7164d395125ce87fd2e048bf1.1736343575.git.jstancek@redhat.com


Signed-off-by: Jakub Kicinski <kuba@kernel.org>

All Qualcomm firmwares uploaded to linux-firmware are in MBN format,
instead of split MDT.  No functional changes, just correct the DTS
example so people will not rely on unaccepted files.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Alex Elder <elder@kernel.org>
Link: https://patch.msgid.link/20250108120242.156201-1-krzysztof.kozlowski@linaro.org


Signed-off-by: Jakub Kicinski <kuba@kernel.org>

The definition of EXPORT_SYMBOL et al depends on
DEFAULT_SYMBOL_NAMESPACE. So DEFAULT_SYMBOL_NAMESPACE must already be
available when <linux/export.h> is parsed.

Also when defined that early there is no need for an #undef, so drop
that from the usage example.

Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/linux-i2c/Z09bp9uMzwXRLXuF@smile.fi.intel.com/


Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/3dd7ff6fa0a636de86e091286016be8c90e03631.1733305665.git.ukleinek@kernel.org


Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20241230142357.3203913-6-u.kleine-koenig@baylibre.com

Since commit cdd30ebb ("module: Convert symbol namespace to string
literal") the namespace has to be a string. Fix accordingly.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/6fe15069c01b31aaa68c6224bec2df9f4a449858.1733305665.git.ukleinek@kernel.org


Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20241230142357.3203913-5-u.kleine-koenig@baylibre.com

A very minor oversight that dates all the way back to rst migration in
commit 9d85025b ("docs-rst: create an user's manual book").

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20241231190240.417446-1-lkundrak@v3.sk

Translate lwn/Documentation/security/landlock.rst into Chinese.

Update the translation through commit dad2f207
("landlock: Fix grammar issues in documentation")

Signed-off-by: Yuxian Mao <maoyuxian@cqsoftware.com.cn>
Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250102104406.17600-1-maoyuxian@cqsoftware.com.cn

It's noticed when I myself made the same spelling mistake while
searching for localmodconfig

Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Thorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250103004358.1310121-1-lizhijian@fujitsu.com

  - Correct "in a way the" to "in a way that",
  - Add a comma to improve readability.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/cf07f705d63f04ebf7ba4ecafdc9ab6f63960e3d.1736239148.git.geert+renesas@glider.be

Translate lwn/Documentation/security/siphash.rst into Chinese

Update the translation through commit 12fe4343
("Documentation: siphash: Fix typo in the name of offsetofend macro")

Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
Signed-off-by: zhangwei <zhangwei@cqsoftware.com.cn>
Reviewed-by: Yanteng Si <siyanteng@linux.dev>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/0af3d9b8be0e5166f74bd36fd6b040767f767fce.1736315479.git.zhangwei@cqsoftware.com.cn

Translate .../security/IMA-templates.rst into Chinese.

Update the translation through commit 398c42e2
("ima: support fs-verity file digest based version 3 signatures").

Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
Signed-off-by: Shuo Zhao <zhaoshuo@cqsoftware.com.cn>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250108075740.19342-1-zhaoshuo@cqsoftware.com.cn