* [PATCH RFC v2 07/11] ASoC: meson: gx: add AUDIN FIFO driver
From: Valerio Setti @ 2026-04-11 14:57 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Valerio Setti
Cc: linux-kernel, linux-sound, linux-arm-kernel, linux-amlogic,
devicetree
In-Reply-To: <20260411-audin-rfc-v2-0-4c8a6ec5fcab@baylibre.com>
Add support for the frontend DAI of the capture interface which is in
charge of receiving decoded data from "audin-decoder-i2s" and move them to
an internal FIFO before they are block-transferring to RAM.
This component could ideally handle multiple input sources (SPDIF, I2S,
PCM, HDMI), but for the time being only I2S is added and has been tested.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
---
sound/soc/meson/Kconfig | 9 +
sound/soc/meson/Makefile | 2 +
sound/soc/meson/audin-fifo.c | 432 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 443 insertions(+)
diff --git a/sound/soc/meson/Kconfig b/sound/soc/meson/Kconfig
index 0a1d166bed3477efdaffa8538150f7aca33a29e6..50307e54f96fda0f9c114c3bff6aae4094018934 100644
--- a/sound/soc/meson/Kconfig
+++ b/sound/soc/meson/Kconfig
@@ -19,6 +19,14 @@ config SND_MESON_GX_AUDIN_DECODER_I2S
Select Y or M to add support for the I2S audio input decoder found
in the Amlogic GX SoC family
+config SND_MESON_GX_AUDIN_FIFO
+ tristate "Amlogic GX AUDIN FIFO"
+ select REGMAP_MMIO
+ imply SND_MESON_AIU
+ help
+ Select Y or M to add support for the frontend capture interfaces
+ embedded in the Amlogic GX SoC family
+
config SND_MESON_AXG_FIFO
tristate
select REGMAP_MMIO
@@ -116,6 +124,7 @@ config SND_MESON_GX_SOUND_CARD
select SND_MESON_CARD_UTILS
imply SND_MESON_AIU
imply SND_MESON_GX_AUDIN_DECODER_I2S
+ imply SND_MESON_GX_AUDIN_FIFO
help
Select Y or M to add support for the GXBB/GXL SoC sound card
diff --git a/sound/soc/meson/Makefile b/sound/soc/meson/Makefile
index a5a8e5b5a3bb8ca8ca0f27e1a29865e0dab64b73..085ddcdc87639d5d79aa39152eafc030f2643e2e 100644
--- a/sound/soc/meson/Makefile
+++ b/sound/soc/meson/Makefile
@@ -11,6 +11,7 @@ snd-soc-meson-aiu-y += aiu-fifo.o
snd-soc-meson-aiu-y += aiu-fifo-i2s.o
snd-soc-meson-aiu-y += aiu-fifo-spdif.o
snd-soc-meson-gx-audin-decoder-i2s-y := audin-decoder-i2s.o
+snd-soc-meson-gx-audin-fifo-y := audin-fifo.o
snd-soc-meson-axg-fifo-y := axg-fifo.o
snd-soc-meson-axg-frddr-y := axg-frddr.o
snd-soc-meson-axg-toddr-y := axg-toddr.o
@@ -31,6 +32,7 @@ snd-soc-meson-t9015-y := t9015.o
obj-$(CONFIG_SND_MESON_AIU) += snd-soc-meson-aiu.o
obj-$(CONFIG_SND_MESON_GX_AUDIN_DECODER_I2S) += snd-soc-meson-gx-audin-decoder-i2s.o
+obj-$(CONFIG_SND_MESON_GX_AUDIN_FIFO) += snd-soc-meson-gx-audin-fifo.o
obj-$(CONFIG_SND_MESON_AXG_FIFO) += snd-soc-meson-axg-fifo.o
obj-$(CONFIG_SND_MESON_AXG_FRDDR) += snd-soc-meson-axg-frddr.o
obj-$(CONFIG_SND_MESON_AXG_TODDR) += snd-soc-meson-axg-toddr.o
diff --git a/sound/soc/meson/audin-fifo.c b/sound/soc/meson/audin-fifo.c
new file mode 100644
index 0000000000000000000000000000000000000000..62f0b03cdfc33056e3be7aaf7333ab71086a9c25
--- /dev/null
+++ b/sound/soc/meson/audin-fifo.c
@@ -0,0 +1,432 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2026 BayLibre, SAS.
+// Author: Valerio Setti <vsetti@baylibre.com>
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <sound/pcm_params.h>
+#include <linux/dma-mapping.h>
+#include <linux/hrtimer.h>
+#include <sound/soc.h>
+#include <sound/soc-dai.h>
+
+/* FIFO registers */
+#define AUDIN_FIFO_START 0x00
+#define AUDIN_FIFO_END 0x04
+#define AUDIN_FIFO_PTR 0x08
+
+/* FIFOx CTRL registers and bits */
+#define AUDIN_FIFO_CTRL 0x14
+#define AUDIN_FIFO_CTRL_EN BIT(0)
+#define AUDIN_FIFO_CTRL_RST BIT(1)
+#define AUDIN_FIFO_CTRL_LOAD BIT(2)
+#define AUDIN_FIFO_CTRL_DIN_SEL_OFF 3
+#define AUDIN_FIFO_CTRL_DIN_SEL_MASK GENMASK(5, 3)
+#define AUDIN_FIFO_CTRL_ENDIAN_MASK GENMASK(10, 8)
+#define AUDIN_FIFO_CTRL_CHAN_MASK GENMASK(14, 11)
+#define AUDIN_FIFO_CTRL_UG BIT(15)
+
+/* FIFOx_CTRL1 registers and bits */
+#define AUDIN_FIFO_CTRL1 0x18
+#define AUDIN_FIFO_CTRL1_DIN_POS_2 BIT(7)
+#define AUDIN_FIFO_CTRL1_DIN_BYTE_NUM_MASK GENMASK(3, 2)
+#define AUDIN_FIFO_CTRL1_DIN_POS_01_MASK GENMASK(1, 0)
+
+/* This is the size of the FIFO (i.e. 64*64 bytes). */
+#define AUDIN_FIFO_I2S_BLOCK 4096
+
+static const struct snd_pcm_hardware audin_fifo_pcm_hw = {
+ .info = (SNDRV_PCM_INFO_INTERLEAVED |
+ SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_PAUSE),
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .rate_min = 5512,
+ .rate_max = 192000,
+ .channels_min = 2,
+ .channels_max = 2,
+ .period_bytes_min = 2 * AUDIN_FIFO_I2S_BLOCK,
+ .period_bytes_max = AUDIN_FIFO_I2S_BLOCK * USHRT_MAX,
+ .periods_min = 2,
+ .periods_max = UINT_MAX,
+
+ /* No real justification for this */
+ .buffer_bytes_max = 1 * 1024 * 1024,
+};
+
+struct audin_fifo_drvdata {
+ struct clk *input_clk;
+};
+
+struct audin_fifo_dai_data {
+ /*
+ * The AUDIN peripheral has an IRQ to signal when data is received, but
+ * it cannot grant a periodic behavior. The reason is that the register
+ * which holds the address which triggers the IRQ must be updated
+ * continuously. This create a risk of overflow if for any reason the
+ * ISR execution is delayed. Using a periodic time is therefore simpler
+ * and more reliable.
+ */
+ struct hrtimer polling_timer;
+ ktime_t poll_time_ns;
+ struct snd_pcm_substream *substream;
+};
+
+static int audin_fifo_dai_trigger(struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_component *component = dai->component;
+ (void) dai;
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ snd_soc_component_update_bits(component, AUDIN_FIFO_CTRL,
+ AUDIN_FIFO_CTRL_EN,
+ AUDIN_FIFO_CTRL_EN);
+ break;
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ case SNDRV_PCM_TRIGGER_STOP:
+ snd_soc_component_update_bits(component, AUDIN_FIFO_CTRL,
+ AUDIN_FIFO_CTRL_EN, 0);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int audin_fifo_dai_prepare(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_component *component = dai->component;
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ dma_addr_t dma_end = runtime->dma_addr + runtime->dma_bytes - 8;
+ unsigned int val;
+
+ /* Setup memory boundaries */
+ snd_soc_component_write(component, AUDIN_FIFO_START, runtime->dma_addr);
+ snd_soc_component_write(component, AUDIN_FIFO_PTR, runtime->dma_addr);
+ snd_soc_component_write(component, AUDIN_FIFO_END, dma_end);
+
+ /* Load new addresses */
+ val = AUDIN_FIFO_CTRL_LOAD | AUDIN_FIFO_CTRL_UG;
+ snd_soc_component_update_bits(component, AUDIN_FIFO_CTRL, val, val);
+
+ /* Reset */
+ snd_soc_component_update_bits(dai->component, AUDIN_FIFO_CTRL,
+ AUDIN_FIFO_CTRL_RST,
+ AUDIN_FIFO_CTRL_RST);
+
+ return 0;
+}
+
+static int audin_fifo_dai_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_component *component = dai->component;
+ struct audin_fifo_dai_data *data = snd_soc_dai_dma_data_get_capture(dai);
+ unsigned int val;
+
+ if (params_width(params) != 16) {
+ dev_err(dai->dev, "Unsupported width %u\n",
+ params_physical_width(params));
+ return -EINVAL;
+ }
+
+ /*
+ * FIFO is filled line by line and each of them is 8 bytes. The
+ * problem is that each line is filled starting from the end,
+ * so we need to properly reorder them before moving to the
+ * RAM. This is the value required to properly re-order samples stored
+ * in 16 bit format.
+ */
+ val = FIELD_PREP(AUDIN_FIFO_CTRL_ENDIAN_MASK, 6);
+ snd_soc_component_update_bits(component, AUDIN_FIFO_CTRL,
+ AUDIN_FIFO_CTRL_ENDIAN_MASK, val);
+
+ /*
+ * The I2S input decoder passed 24 bits of left-justified data
+ * but for the time being we only 16 bit formatted samples which means
+ * that we drop the LSB.
+ */
+ val = FIELD_PREP(AUDIN_FIFO_CTRL1_DIN_POS_01_MASK, 1);
+ snd_soc_component_update_bits(component, AUDIN_FIFO_CTRL1,
+ AUDIN_FIFO_CTRL1_DIN_POS_01_MASK,
+ val);
+
+ /* Set sample size to 2 bytes (16 bit) */
+ val = FIELD_PREP(AUDIN_FIFO_CTRL1_DIN_BYTE_NUM_MASK, 1);
+ snd_soc_component_update_bits(component, AUDIN_FIFO_CTRL1,
+ AUDIN_FIFO_CTRL1_DIN_BYTE_NUM_MASK,
+ val);
+
+ /*
+ * This is a bit counterintuitive. Even though the platform has a single
+ * pin for I2S input which would mean that we can only support 2
+ * channels, doing so would cause samples to be stored in a weird way
+ * into the FIFO: all the samples from the 1st channel on the 1st half
+ * of the FIFO, then samples from the 2nd channel in the other half. Of
+ * course extra work would be required to properly interleave them
+ * before returning to the userspace.
+ * Setting a single channel mode instead solves the problem: samples
+ * from 1st and 2nd channel are stored interleaved and sequentially in
+ * the FIFO.
+ */
+ val = FIELD_PREP(AUDIN_FIFO_CTRL_CHAN_MASK, 1);
+ snd_soc_component_update_bits(component, AUDIN_FIFO_CTRL,
+ AUDIN_FIFO_CTRL_CHAN_MASK, val);
+
+ /* Setup the period for the polling timer and start it. */
+ data->poll_time_ns = NSEC_PER_SEC * params_period_size(params) /
+ params_rate(params);
+
+ hrtimer_start(&data->polling_timer, data->poll_time_ns,
+ HRTIMER_MODE_REL);
+
+ return 0;
+}
+
+static int audin_fifo_dai_hw_free(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct audin_fifo_dai_data *data = snd_soc_dai_dma_data_get_capture(dai);
+ (void) substream;
+
+ hrtimer_cancel(&data->polling_timer);
+
+ return 0;
+}
+
+static int audin_fifo_dai_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct audin_fifo_dai_data *data = snd_soc_dai_dma_data_get_capture(dai);
+ int ret;
+
+ snd_soc_set_runtime_hwparams(substream, &audin_fifo_pcm_hw);
+
+ ret = snd_pcm_hw_constraint_step(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_BUFFER_BYTES,
+ AUDIN_FIFO_I2S_BLOCK);
+ if (ret) {
+ dev_err(dai->dev, "Failed to set runtime constraint %d\n", ret);
+ return ret;
+ }
+
+ ret = snd_pcm_hw_constraint_step(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
+ AUDIN_FIFO_I2S_BLOCK);
+ if (ret) {
+ dev_err(dai->dev, "Failed to set runtime constraint %d\n", ret);
+ return ret;
+ }
+
+ data->substream = substream;
+
+ return ret;
+}
+
+static int audin_fifo_dai_pcm_new(struct snd_soc_pcm_runtime *rtd,
+ struct snd_soc_dai *dai)
+{
+ int ret;
+
+ ret = dma_coerce_mask_and_coherent(dai->dev, DMA_BIT_MASK(32));
+ if (ret) {
+ dev_err(dai->dev, "Failed to set DMA mask %d\n", ret);
+ return ret;
+ }
+
+ ret = snd_pcm_set_managed_buffer_all(rtd->pcm, SNDRV_DMA_TYPE_DEV,
+ dai->dev,
+ audin_fifo_pcm_hw.buffer_bytes_max,
+ audin_fifo_pcm_hw.buffer_bytes_max);
+ if (ret) {
+ dev_err(dai->dev, "Failed to set PCM managed buffer %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static enum hrtimer_restart dai_timer_cb(struct hrtimer *timer)
+{
+ struct audin_fifo_dai_data *data =
+ container_of(timer, struct audin_fifo_dai_data, polling_timer);
+ snd_pcm_period_elapsed(data->substream);
+ hrtimer_forward_now(timer, data->poll_time_ns);
+ return HRTIMER_RESTART;
+}
+
+static int audin_fifo_dai_probe(struct snd_soc_dai *dai)
+{
+ struct audin_fifo_dai_data *data;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ hrtimer_setup(&data->polling_timer, dai_timer_cb, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL);
+
+ snd_soc_dai_dma_data_set_capture(dai, data);
+
+ return 0;
+}
+
+static int audin_fifo_dai_remove(struct snd_soc_dai *dai)
+{
+ kfree(snd_soc_dai_dma_data_get_capture(dai));
+
+ return 0;
+}
+
+const struct snd_soc_dai_ops audin_fifo_dai_ops = {
+ .trigger = audin_fifo_dai_trigger,
+ .prepare = audin_fifo_dai_prepare,
+ .hw_params = audin_fifo_dai_hw_params,
+ .hw_free = audin_fifo_dai_hw_free,
+ .startup = audin_fifo_dai_startup,
+ .pcm_new = audin_fifo_dai_pcm_new,
+ .probe = audin_fifo_dai_probe,
+ .remove = audin_fifo_dai_remove,
+};
+
+static struct snd_soc_dai_driver audin_fifo_dai_drv[] = {
+ {
+ .name = "FIFO",
+ .capture = {
+ .stream_name = "Capture",
+ .channels_min = 2,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_CONTINUOUS,
+ .rate_min = 5512,
+ .rate_max = 192000,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ },
+ .ops = &audin_fifo_dai_ops,
+ },
+};
+
+static snd_pcm_uframes_t
+audin_fifo_component_pointer(struct snd_soc_component *component,
+ struct snd_pcm_substream *substream)
+{
+ unsigned int start, ptr;
+
+ start = snd_soc_component_read(component, AUDIN_FIFO_START);
+ ptr = snd_soc_component_read(component, AUDIN_FIFO_PTR);
+
+ return bytes_to_frames(substream->runtime, ptr - start);
+}
+
+static const char * const audin_fifo_fifo_input_sel_texts[] = {
+ "SPDIF", "I2S", "PCM", "HDMI", "Demodulator"
+};
+
+static SOC_ENUM_SINGLE_DECL(audin_fifo_input_sel_enum, AUDIN_FIFO_CTRL,
+ AUDIN_FIFO_CTRL_DIN_SEL_OFF,
+ audin_fifo_fifo_input_sel_texts);
+
+static const struct snd_kcontrol_new audin_fifo_input_sel_mux =
+ SOC_DAPM_ENUM("SRC SEL", audin_fifo_input_sel_enum);
+
+static const struct snd_soc_dapm_widget audin_fifo_dapm_widgets[] = {
+ SND_SOC_DAPM_AIF_IN("I2S IN", NULL, 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_MUX("SRC SEL", SND_SOC_NOPM, 0, 0,
+ &audin_fifo_input_sel_mux),
+};
+
+static const struct snd_soc_dapm_route audin_fifo_dapm_routes[] = {
+ { "SRC SEL", "I2S", "I2S IN" },
+ { "Capture", NULL, "SRC SEL" },
+};
+
+static const struct snd_soc_component_driver audin_fifo_component = {
+ .dapm_widgets = audin_fifo_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(audin_fifo_dapm_widgets),
+ .dapm_routes = audin_fifo_dapm_routes,
+ .num_dapm_routes = ARRAY_SIZE(audin_fifo_dapm_routes),
+ .pointer = audin_fifo_component_pointer,
+};
+
+static const struct regmap_config audin_fifo_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x1b,
+};
+
+static int audin_fifo_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ void __iomem *regs;
+ struct regmap *map;
+ struct audin_fifo_drvdata *data;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (data == NULL)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, data);
+
+ regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
+ map = devm_regmap_init_mmio(dev, regs, &audin_fifo_regmap_cfg);
+ if (IS_ERR(map)) {
+ dev_err(dev, "Failed to init regmap: %ld\n", PTR_ERR(map));
+ return PTR_ERR(map);
+ }
+
+ data->input_clk = devm_clk_get_enabled(dev, "i2s_input_clk");
+ if (IS_ERR(data->input_clk)) {
+ dev_err(dev, "can't get the i2s input clock\n");
+ return PTR_ERR(data->input_clk);
+ }
+
+ ret = snd_soc_register_component(dev, &audin_fifo_component,
+ audin_fifo_dai_drv,
+ ARRAY_SIZE(audin_fifo_dai_drv));
+ if (ret) {
+ dev_err(dev, "failed to register component\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void audin_fifo_remove(struct platform_device *pdev)
+{
+ struct audin_fifo_drvdata *data = platform_get_drvdata(pdev);
+
+ clk_disable_unprepare(data->input_clk);
+ snd_soc_unregister_component(&pdev->dev);
+}
+
+static const struct of_device_id audin_fifo_of_match[] = {
+ { .compatible = "amlogic,meson-gxbb-audin-fifo", .data = NULL },
+ {}
+};
+MODULE_DEVICE_TABLE(of, audin_fifo_of_match);
+
+static struct platform_driver audin_fifo_pdrv = {
+ .probe = audin_fifo_probe,
+ .remove = audin_fifo_remove,
+ .driver = {
+ .name = "meson-gx-audin-fifo",
+ .of_match_table = audin_fifo_of_match,
+ },
+};
+module_platform_driver(audin_fifo_pdrv);
+
+MODULE_DESCRIPTION("Meson AUDIN FIFO Driver");
+MODULE_AUTHOR("Valerio Setti <vsetti@baylibre.com>");
+MODULE_LICENSE("GPL");
--
2.39.5
^ permalink raw reply related
* Re: [PATCH bpf-next v13 2/5] bpf: Pass bpf_verifier_env to JIT
From: Alexei Starovoitov @ 2026-04-11 17:11 UTC (permalink / raw)
To: bot+bpf-ci
Cc: Xu Kuohai, bpf, LKML, linux-arm-kernel, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Eduard,
Kumar Kartikeya Dwivedi, Yonghong Song, Puranjay Mohan,
Anton Protopopov, Alexis Lothoré (eBPF Foundation),
Shahab Vahedi, Russell King, Tiezhu Yang, Hengqi Chen,
Johan Almbladh, Paul Burton, Hari Bathini, Christophe Leroy,
Naveen N. Rao, Luke Nelson, Xi Wang, Björn Töpel,
Pu Lehui, Ilya Leoshkevich, Heiko Carstens, Vasily Gorbik,
David S. Miller, Wang YanQing, Martin KaFai Lau, Chris Mason,
Ihor Solodrai
In-Reply-To: <e7535d00be73466e4a09621be0cc898e0ab76422427a17996e4d34712d16fbe3@mail.kernel.org>
On Sat, Apr 11, 2026 at 7:43 AM <bot+bpf-ci@kernel.org> wrote:
>
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index 3fa3c74869d0..bd96b3a01b99 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
>
> [ ... ]
>
> > @@ -2553,46 +2530,53 @@ static bool bpf_prog_select_interpreter(struct bpf_prog *fp)
> > return select_interpreter;
> > }
> >
> > -static struct bpf_prog *bpf_prog_jit_compile(struct bpf_prog *prog)
> > +static struct bpf_prog *bpf_prog_jit_compile(struct bpf_verifier_env *env, struct bpf_prog *prog)
> > {
> > #ifdef CONFIG_BPF_JIT
> > struct bpf_prog *orig_prog;
> > + struct bpf_insn_aux_data *orig_insn_aux;
> >
> > if (!bpf_prog_need_blind(prog))
> > - return bpf_int_jit_compile(prog);
> > + return bpf_int_jit_compile(env, prog);
> > +
> > + if (env) {
> > + /* If env is not NULL, we are called from the end of bpf_check(), at this
> > + * point, only insn_aux_data is used after failure, so it should be restored
> > + * on failure.
> > + */
>
> This isn't a bug, but this multi-line comment has text on the
> opening /* line. The BPF subsystem preferred style places /* on
> its own line:
>
> /*
> * If env is not NULL, we are called from ...
> */
AI is correct.
pw-bot: cr
^ permalink raw reply
* Re: [GIT PULL] firmware: arm_ffa: Fix for v7.1
From: Sudeep Holla @ 2026-04-11 17:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: ARM SoC Team, SoC Team, Sudeep Holla, ALKML, Arnd Bergmann
In-Reply-To: <20260411-tireless-agama-of-advance-5bdabf@quoll>
On Sat, Apr 11, 2026 at 10:49:50AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Apr 07, 2026 at 11:08:39AM +0100, Sudeep Holla wrote:
> > Hi ARM SoC Team,
> >
> > Please pull ! This is the only fix/update I have at the moment for v7.1
> > So, I am sending it early as fix but late as an update for v7.1.
> >
> > Regards,
> > Sudeep
> >
> > -->8
> >
> > The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
> >
> > Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/ffa-fix-7.1
> >
> > for you to fetch changes up to 83210251fd70d5f96bcdc8911e15f7411a6b2463:
> >
> > firmware: arm_ffa: Use the correct buffer size during RXTX_MAP (2026-04-07 10:47:42 +0100)
> >
> > ----------------------------------------------------------------
> > Arm FF-A fix for v7.1
> >
> > Use the page aligned backing allocation size when computing the RXTX_MAP
> > page count. This fixes FF-A RX/TX buffer registration on kernels built
> > with 16K/64K PAGE_SIZE, where alloc_pages_exact() backs the buffer with a
> > larger aligned span than the discovered minimum buffer size.
>
> Can we avoid per-driver trees or pulls? You do maintain also ARM SCMI
> firmware driver, so this could be sent together? I think you also use
> the same Git tree, right?
>
Sure, I can put all of the firmware drivers I maintain together. I had
for some reason assumed individual PR is preferred.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] mailbox: prefix new constants with MBOX_
From: Sudeep Holla @ 2026-04-11 17:41 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Jassi Brar, Peter Chen, Fugang Duan,
CIX Linux Kernel Upstream Group, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Matthias Brugger,
AngeloGioacchino Del Regno, Thierry Reding, Jonathan Hunter,
linux-arm-kernel, imx, linux-mediatek, linux-tegra
In-Reply-To: <20260410125105.39340-2-wsa+renesas@sang-engineering.com>
On Fri, Apr 10, 2026 at 02:49:12PM +0200, Wolfram Sang wrote:
> Commit 89e5d7d61600 ("mailbox: remove superfluous internal header")
> moved some constants to a public header but forgot to add a mailbox
> specific prefix. Add this now to prevent future collisions on a too
> generic naming.
>
> Link: https://sashiko.dev/#/patchset/20260327151112.5202-2-wsa%2Brenesas%40sang-engineering.com
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> This patch improves the above mentioned commit which already sits in
> -next. It is not really a fix but it probably is still a good idea to
> apply it before rc1 to avoid confusion.
>
Agreed and makes sense to have the mailbox namespace for these macro.
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Alexey Charkov @ 2026-04-11 18:00 UTC (permalink / raw)
To: dennis
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Peter Robinson, Michael Riesch, Mykola Kvach, Jimmy Hon,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-4-dennis@ausil.us>
On Sat, Apr 11, 2026 at 6:47 AM <dennis@ausil.us> wrote:
>
> From: Dennis Gilmore <dennis@ausil.us>
>
> Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
>
> - eMMC module, you can optionally solder a SPI NOR in place and turn
> off the eMMC
> - PCIe-attached NIC (pcie2x1l1)
> - PCIe NVMe slot (pcie2x1l2)
> - AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
> - BCM4345C5 Bluetooth
> - es8388 audio
> - USB 2.0 and USB 3.0
> - Two HDMI ports, the second is connected to the SoC's DP controller
> driven by a transparent LT8711UXD bridge that has firmware onboard and
> needs no node defined.
>
> Vendors description and links to schematics available:
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html
Hi Dennis,
The most useful of these is the schematic, so it's best to include a
direct link to that in a dedicated Link: tag
Link: https://drive.google.com/file/d/1qs1DratHuh7C6J6MEtQIwUsiSrg8qgTi/view
[schematic]
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
> .../display/rockchip/rockchip,dw-dp.yaml | 7 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../dts/rockchip/rk3588s-orangepi-5-pro.dts | 352 ++++++++++++++++++
> drivers/gpu/drm/bridge/synopsys/dw-dp.c | 12 +
These should be three separate patches, never lumped together. First
the binding change, next the driver change. They go together via the
subsystem tree (likely DRM in this case). Then the DTS addition (or
change) separately (it goes via the SoC tree).
> 4 files changed, 372 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> index 6345f0132d43..079a912d97f1 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> @@ -57,6 +57,13 @@ properties:
> - const: i2s
> - const: spdif
>
> + hpd-gpios:
> + maxItems: 1
> + description:
> + GPIO used for hot plug detection when the controller's native HPD
> + input is not connected. If not specified, the controller uses its
> + internal HPD detection mechanism.
Do you actually need this change? According to the schematic, the
DP_HPDIN line from the DP-HDMI bridge is routed to the native
DP0_HPDIN_M0 pin of the DP controller, so it shouldn't require this
GPIO trick if the pinctrl is configured properly.
> phys:
> maxItems: 1
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 4d384f153c13..c99dca2ae9e7 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> new file mode 100644
> index 000000000000..84c83aa69f63
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> @@ -0,0 +1,352 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3588s-orangepi-5.dtsi"
> +
> +/ {
> + model = "Xunlong Orange Pi 5 Pro";
> + compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
> +
> + aliases {
> + mmc0 = &sdhci;
> + mmc1 = &sdmmc;
> + mmc2 = &sdio;
> + };
> +
> + dp-con {
> + compatible = "dp-connector";
You don't have a physical DP connector on the board, so this node
doesn't describe actual hardware, and is thus a no-go. What you have
instead is an HDMI type A connector routed via an onboard DP to HDMI
bridge, so you should describe exactly that in the device tree (a node
for the HDMI connector, a node for the bridge, a node for the DP
controller, and endpoints connected from the controller to the bridge,
from the bridge to the connector). Please refer to the device tree for
Radxa Rock 5 ITX, which has a similar setup (but a different bridge
IC).
I don't think your LT8711UXD has existing binding or driver entry, so
a one-line patch will likely be needed to
Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml,
and a separate one to drivers/gpu/drm/bridge/simple-bridge.c. Separate
ones :)
> + port {
> + dp_con_in: endpoint {
> + remote-endpoint = <&dp0_out_con>;
> + };
> + };
> + };
> +
> + analog-sound {
> + compatible = "simple-audio-card";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hp_detect>;
> + simple-audio-card,bitclock-master = <&masterdai>;
> + simple-audio-card,format = "i2s";
> + simple-audio-card,frame-master = <&masterdai>;
> + simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> + simple-audio-card,mclk-fs = <256>;
> + simple-audio-card,name = "rockchip,es8388";
> + simple-audio-card,routing =
> + "Headphones", "LOUT1",
> + "Headphones", "ROUT1",
> + "LINPUT1", "Microphone Jack",
> + "RINPUT1", "Microphone Jack",
> + "LINPUT2", "Onboard Microphone",
> + "RINPUT2", "Onboard Microphone";
> + simple-audio-card,widgets =
> + "Microphone", "Microphone Jack",
> + "Microphone", "Onboard Microphone",
> + "Headphone", "Headphones";
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s2_2ch>;
> + };
> +
> + masterdai: simple-audio-card,codec {
> + sound-dai = <&es8388>;
> + system-clock-frequency = <12288000>;
> + };
> + };
> +
> + pwm-leds {
> + compatible = "pwm-leds";
> +
> + led-0 {
> + color = <LED_COLOR_ID_BLUE>;
> + function = LED_FUNCTION_STATUS;
> + linux,default-trigger = "heartbeat";
> + max-brightness = <255>;
> + pwms = <&pwm15 0 1000000 0>;
> + };
> +
> + led-1 {
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_ACTIVITY;
> + linux,default-trigger = "heartbeat";
> + max-brightness = <255>;
> + pwms = <&pwm3 0 1000000 0>;
> + };
> + };
> +
> + fan: pwm-fan {
> + compatible = "pwm-fan";
> + #cooling-cells = <2>;
> + cooling-levels = <0 50 100 150 200 255>;
> + fan-supply = <&vcc5v0_sys>;
> + pwms = <&pwm2 0 20000000 0>;
> + };
> +
> + vcc3v3_dp: regulator-vcc3v3-dp {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
Please don't forget to add explicit pinctrl nodes for each GPIO pin
you use (here and in other places like this). These GPIOs happen to
work on Linux without configuring their pin control first, but that is
pure luck and coincidence due to how the respective Linux subsystems
are wired together, and if you ever need to use this device tree in
e.g. U-boot (which also derives its DTS from the Linux kernel tree) it
will break there.
> + regulator-always-on;
> + regulator-boot-on;
Does it have to be always-on, boot-on? This looks like a hack to work
around the fact that you didn't define the bridge node, which uses
this as its supply. Please model the dependencies explicitly - most
likely that will let you drop these attributes.
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
It's two separate regulators on your schematic, one DCDC at 1.25V and
the other a load switch at 3.3V, driving six separate voltage inputs
of the DP bridge. They are both controlled by the same GPIO pin
though, so _maybe_ it's okay to have just one "virtual" node like this
to model them together. Would be great for the DT maintainers to weigh
in on this.
> + regulator-name = "vcc3v3_dp";
> + vin-supply = <&vcc_3v3_s3>;
> + };
> +
> + vcc3v3_phy1: regulator-vcc3v3-phy1 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
> + regulator-boot-on;
See above
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
> + regulator-name = "vcc3v3_phy1";
> + startup-delay-us = <50000>;
> + vin-supply = <&vcc_3v3_s3>;
> + };
> +
> + vcc5v0_otg: regulator-vcc5v0-otg {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc5v0_otg_en>;
> + regulator-max-microvolt = <5000000>;
> + regulator-min-microvolt = <5000000>;
> + regulator-name = "vcc5v0_otg";
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&hym8563>;
> + clock-names = "ext_clock";
> + post-power-on-delay-ms = <200>;
> + reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
This GPIO also needs a pinctrl
> + };
> +
> + typea_con: usb-a-connector {
> + compatible = "usb-a-connector";
> + data-role = "host";
> + label = "USB3 Type-A";
> + power-role = "source";
> + vbus-supply = <&vcc5v0_otg>;
> + };
> +};
> +
> +&dp0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&dp0m0_pins>;
This switches your HPD pin to the native DP controller handling
(DP0_HPDIN_M0), so the GPIO bits you've patched into the controller
driver aren't even used, and it doesn't look like you tested that code
path.
> + status = "okay";
> +};
> +
> +&dp0_in {
> + dp0_in_vp1: endpoint {
> + remote-endpoint = <&vp1_out_dp0>;
> + };
> +};
> +
> +&dp0_out {
> + dp0_out_con: endpoint {
> + remote-endpoint = <&dp_con_in>;
This will need to be rewritten once you add the proper bridge chain
leading up to the HDMI type A connector.
> + };
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1m4_xfer>;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c3m0_xfer>;
> + status = "okay";
> +
> + es8388: audio-codec@11 {
> + compatible = "everest,es8388", "everest,es8328";
> + reg = <0x11>;
> + #sound-dai-cells = <0>;
> + AVDD-supply = <&vcc_3v3_s0>;
Are you sure? Schematic says VCCA_3V3_S0, which is a different
regulator (PLDO4 output of the PMIC)
> + DVDD-supply = <&vcc_1v8_s0>;
Schematic says VCCA_1V8_S0, which is a different regulator (PLDO1
output of the PMIC)
> + HPVDD-supply = <&vcc_3v3_s0>;
Schematic says VCCA_3V3_S0
> + PVDD-supply = <&vcc_3v3_s0>;
Schematic says VCCA_1V8_S0
> + assigned-clock-rates = <12288000>;
> + assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
> + clocks = <&cru I2S2_2CH_MCLKOUT>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2s2m1_mclk>;
> + };
> +};
> +
> +&i2c4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c4m3_xfer>;
> + status = "okay";
> +};
> +
> +&i2s2_2ch {
> + pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
> + &i2s2m1_sdi &i2s2m1_sdo>;
> + status = "okay";
> +};
> +
> +&package_thermal {
> + polling-delay = <1000>;
> +
> + cooling-maps {
> + map0 {
> + trip = <&package_fan0>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map1 {
> + trip = <&package_fan1>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +
> + trips {
> + package_fan0: package-fan0 {
> + hysteresis = <2000>;
> + temperature = <55000>;
> + type = "active";
> + };
> +
> + package_fan1: package-fan1 {
> + hysteresis = <2000>;
> + temperature = <65000>;
> + type = "active";
> + };
> + };
> +};
> +
> +/* NVMe */
> +&pcie2x1l1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie30x1m1_1_clkreqn &pcie30x1m1_1_waken>;
> + reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
The GPIO also needs a pinctrl
> + supports-clkreq;
> + vpcie3v3-supply = <&vcc_3v3_s3>;
> + status = "okay";
> +};
> +
> +/* NIC */
> +&pcie2x1l2 {
> + reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
The GPIO also needs a pinctrl
> + vpcie3v3-supply = <&vcc3v3_phy1>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + bluetooth {
> + bt_wake_gpio: bt-wake-pin {
> + rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + bt_wake_host_irq: bt-wake-host-irq {
> + rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +
> + usb {
> + vcc5v0_otg_en: vcc5v0-otg-en {
> + rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + wlan {
> + wifi_host_wake_irq: wifi-host-wake-irq {
> + rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +};
> +
> +&pwm15 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm15m2_pins>;
> + status = "okay";
> +};
> +
> +&pwm2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm2m1_pins>;
> + status = "okay";
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm3m2_pins>;
> + status = "okay";
> +};
> +
> +&sdhci {
> + status = "okay";
> +};
> +
> +&sdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + bus-width = <4>;
> + cap-sd-highspeed;
> + cap-sdio-irq;
> + keep-power-in-suspend;
> + max-frequency = <150000000>;
> + mmc-pwrseq = <&sdio_pwrseq>;
> + no-mmc;
> + no-sd;
> + non-removable;
> + sd-uhs-sdr104;
> + status = "okay";
> +
> + ap6256: wifi@1 {
> + compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
> + reg = <1>;
> + interrupt-names = "host-wake";
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_host_wake_irq>;
> + };
> +};
> +
> +&uart9 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn &uart9m2_rtsn>;
> + uart-has-rtscts;
> + status = "okay";
> +
> + bluetooth {
> + compatible = "brcm,bcm4345c5";
> + clocks = <&hym8563>;
> + clock-names = "lpo";
> + device-wakeup-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
> + interrupt-names = "host-wakeup";
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PC5 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1500000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&bt_wake_host_irq &bt_wake_gpio>;
> + shutdown-gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
> + vbat-supply = <&vcc_3v3_s3>;
> + vddio-supply = <&vcc_1v8_s3>;
> + };
> +};
> +
> +&usb_host0_xhci {
> + dr_mode = "host";
> +};
> +
> +&usbdp_phy0 {
> + rockchip,dp-lane-mux = <0 1>;
I'm wondering if the DP controller's "out" endpoint should go to the
PHY instead of directly to the connector/bridge. That would describe
the hardware better.
> +};
> +
> +&vp1 {
> + vp1_out_dp0: endpoint@a {
> + reg = <ROCKCHIP_VOP2_EP_DP0>;
> + remote-endpoint = <&dp0_in_vp1>;
> + };
> +};
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> index fd23ca2834b0..b58f57b69b22 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> @@ -8,6 +8,7 @@
> */
> #include <linux/bitfield.h>
> #include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/iopoll.h>
> #include <linux/irq.h>
> #include <linux/media-bus-format.h>
> @@ -330,6 +331,8 @@ struct dw_dp {
> u8 pixel_mode;
>
> DECLARE_BITMAP(sdp_reg_bank, SDP_REG_BANK_SIZE);
> +
> + struct gpio_desc *hpd_gpiod;
> };
>
> enum {
> @@ -481,6 +484,9 @@ static bool dw_dp_hpd_detect(struct dw_dp *dp)
> {
> u32 value;
>
> + if (dp->hpd_gpiod)
> + return gpiod_get_value_cansleep(dp->hpd_gpiod);
> +
> regmap_read(dp->regmap, DW_DP_HPD_STATUS, &value);
>
> return FIELD_GET(HPD_STATE, value) == DW_DP_HPD_STATE_PLUG;
> @@ -2002,6 +2008,12 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
> return ERR_CAST(dp->regmap);
> }
>
> + dp->hpd_gpiod = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
Not tested, not needed, why bother?..
Best regards,
Alexey
^ permalink raw reply
* [PATCH v2] dt-bindings: ARM: arm,vexpress-scc: convert to DT schema
From: Khushal Chitturi @ 2026-04-11 18:33 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, liviu.dudau, sudeep.holla, lpieralisi
Cc: pawel.moll, devicetree, linux-arm-kernel, linux-kernel,
Khushal Chitturi
Convert the ARM Versatile Express Serial Configuration Controller
bindings to DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v1 -> v2:
- Modified compatible string to use an enum instead of a generic pattern.
- Updated maintainers list.
.../bindings/arm/arm,vexpress-scc.yaml | 53 +++++++++++++++++++
.../devicetree/bindings/arm/vexpress-scc.txt | 33 ------------
2 files changed, 53 insertions(+), 33 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml
delete mode 100644 Documentation/devicetree/bindings/arm/vexpress-scc.txt
diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml
new file mode 100644
index 000000000000..9b8f7e0c4ea0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,vexpress-scc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Versatile Express Serial Configuration Controller
+
+maintainers:
+ - Liviu Dudau <liviu.dudau@arm.com>
+ - Sudeep Holla <sudeep.holla@arm.com>
+
+description: |
+ Test chips for ARM Versatile Express platform implement SCC (Serial
+ Configuration Controller) interface, used to set initial conditions
+ for the test chip.
+
+ In some cases its registers are also mapped in normal address space
+ and can be used to obtain runtime information about the chip internals
+ (like silicon temperature sensors) and as interface to other subsystems
+ like platform configuration control and power management.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - arm,vexpress-scc,v2p-ca15_a7
+ - const: arm,vexpress-scc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ scc@7fff0000 {
+ compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
+ reg = <0 0x7fff0000 0 0x1000>;
+ interrupts = <0 95 4>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/arm/vexpress-scc.txt b/Documentation/devicetree/bindings/arm/vexpress-scc.txt
deleted file mode 100644
index ae5043e42e5d..000000000000
--- a/Documentation/devicetree/bindings/arm/vexpress-scc.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-ARM Versatile Express Serial Configuration Controller
------------------------------------------------------
-
-Test chips for ARM Versatile Express platform implement SCC (Serial
-Configuration Controller) interface, used to set initial conditions
-for the test chip.
-
-In some cases its registers are also mapped in normal address space
-and can be used to obtain runtime information about the chip internals
-(like silicon temperature sensors) and as interface to other subsystems
-like platform configuration control and power management.
-
-Required properties:
-
-- compatible value: "arm,vexpress-scc,<model>", "arm,vexpress-scc";
- where <model> is the full tile model name (as used
- in the tile's Technical Reference Manual),
- eg. for Coretile Express A15x2 A7x3 (V2P-CA15_A7):
- compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
-
-Optional properties:
-
-- reg: when the SCC is memory mapped, physical address and size of the
- registers window
-- interrupts: when the SCC can generate a system-level interrupt
-
-Example:
-
- scc@7fff0000 {
- compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
- reg = <0 0x7fff0000 0 0x1000>;
- interrupts = <0 95 4>;
- };
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] thermal/drivers/imx: two fixes
From: Felix Gu @ 2026-04-11 19:03 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Felix Gu
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
Felix Gu (2):
thermal/drivers/imx: Fix thermal zone leak on probe error path
thermal/drivers/imxl:Fix runtime PM handling on early returns
drivers/thermal/imx_thermal.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260411-imx-b022791ea1b9
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply
* [PATCH 1/2] thermal/drivers/imx: Fix thermal zone leak on probe error path
From: Felix Gu @ 2026-04-11 19:03 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Felix Gu
In-Reply-To: <20260412-imx-v1-0-cc3b45d63811@gmail.com>
If pm_runtime_resume_and_get() fails after the thermal zone has been
registered, the probe error path cleans up runtime PM but skips
thermal_zone_device_unregister(), leaking the thermal zone device.
Move thermal_zone_device_unregister() into disable_runtime_pm so all
failures after thermal zone registration unwind the probe path
correctly.
Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/thermal/imx_thermal.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 38c993d1bcb3..68f9ce41a670 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -727,25 +727,24 @@ static int imx_thermal_probe(struct platform_device *pdev)
data->irq_enabled = true;
ret = thermal_zone_device_enable(data->tz);
if (ret)
- goto thermal_zone_unregister;
+ goto disable_runtime_pm;
ret = devm_request_threaded_irq(dev, data->irq,
imx_thermal_alarm_irq, imx_thermal_alarm_irq_thread,
0, "imx_thermal", data);
if (ret < 0) {
dev_err(dev, "failed to request alarm irq: %d\n", ret);
- goto thermal_zone_unregister;
+ goto disable_runtime_pm;
}
pm_runtime_put(data->dev);
return 0;
-thermal_zone_unregister:
- thermal_zone_device_unregister(data->tz);
disable_runtime_pm:
pm_runtime_put_noidle(data->dev);
pm_runtime_disable(data->dev);
+ thermal_zone_device_unregister(data->tz);
clk_disable:
clk_disable_unprepare(data->thermal_clk);
legacy_cleanup:
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] thermal/drivers/imxl:Fix runtime PM handling on early returns
From: Felix Gu @ 2026-04-11 19:03 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Felix Gu
In-Reply-To: <20260412-imx-v1-0-cc3b45d63811@gmail.com>
Use PM_RUNTIME_ACQUIRE() in imx_get_temp() and imx_set_trip_temp() so
runtime PM references are released correctly even when the functions
return early on errors.
Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/thermal/imx_thermal.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 68f9ce41a670..9d9ae7871068 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -260,8 +260,9 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
u32 val;
int ret;
- ret = pm_runtime_resume_and_get(data->dev);
- if (ret < 0)
+ PM_RUNTIME_ACQUIRE(data->dev, pm);
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
return ret;
regmap_read(map, soc_data->temp_data, &val);
@@ -302,8 +303,6 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
enable_irq(data->irq);
}
- pm_runtime_put(data->dev);
-
return 0;
}
@@ -337,8 +336,9 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
struct imx_thermal_data *data = thermal_zone_device_priv(tz);
int ret;
- ret = pm_runtime_resume_and_get(data->dev);
- if (ret < 0)
+ PM_RUNTIME_ACQUIRE(data->dev, pm);
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
return ret;
/* do not allow passive to be set higher than critical */
@@ -348,8 +348,6 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
imx_set_alarm_temp(data, temp);
trips[IMX_TRIP_PASSIVE].temperature = temp;
- pm_runtime_put(data->dev);
-
return 0;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 2/7] arm64/runtime-const: Use aarch64_insn_patch_text_nosync() for patching
From: K Prateek Nayak @ 2026-04-11 19:54 UTC (permalink / raw)
To: Catalin Marinas
Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Will Deacon, David Laight, Darren Hart,
Davidlohr Bueso, André Almeida, linux-arch, linux-kernel,
linux-s390, linux-riscv, linux-arm-kernel, Jisheng Zhang
In-Reply-To: <adjE6WzFM7NogzlU@arm.com>
Hello Catalin,
Thank you for taking a look at the series and pointing to the Shashiko
review.
On 4/10/2026 3:07 PM, Catalin Marinas wrote:
>> -static inline void __runtime_fixup_caches(void *where, unsigned int insns)
>> -{
>> - unsigned long va = (unsigned long)where;
>> - caches_clean_inval_pou(va, va + 4*insns);
>> + aarch64_insn_patch_text_nosync(p, insn);
>> }
>
> Sashiko has some good points here:
Ack! I did check the Sashiko review a few days after posting. I think
I'll probably start replying to Shahsiko's inline review on future
threads on LKML to keep the record like some folks are doing.
>
> https://sashiko.dev/#/patchset/20260402112250.2138-1-kprateek.nayak@amd.com
>
> In short, aarch64_insn_patch_text_nosync() does not expect a linear map
> address but rather a kernel text one (or vmalloc/modules). The other
> valid point is on aliasing I-caches.
>
> I think dropping the lm_alias() and just use 'where' directly would do
> but I haven't tried.
Ack! I completely missed that subtlety of passing "where" to
caches_clean_inval_pou(). I'm still surprised that it didn't
blow up in my testing.
Anyhow, following diff, on top of the full series builds and
tests fine and has been blessed by review-prompts:
diff --git a/arch/arm64/include/asm/runtime-const.h b/arch/arm64/include/asm/runtime-const.h
index 21f817eb5951..d3f0dfa7ced0 100644
--- a/arch/arm64/include/asm/runtime-const.h
+++ b/arch/arm64/include/asm/runtime-const.h
@@ -57,21 +57,21 @@
} while (0)
/* 16-bit immediate for wide move (movz and movk) in bits 5..20 */
-static inline void __runtime_fixup_16(__le32 *p, unsigned int val)
+static inline void __runtime_fixup_16(void *where, unsigned int val)
{
+ __le32 *p = lm_alias(where);
u32 insn = le32_to_cpu(*p);
insn &= 0xffe0001f;
insn |= (val & 0xffff) << 5;
- aarch64_insn_patch_text_nosync(p, insn);
+ aarch64_insn_patch_text_nosync(where, insn);
}
static inline void __runtime_fixup_ptr(void *where, unsigned long val)
{
- __le32 *p = lm_alias(where);
- __runtime_fixup_16(p, val);
- __runtime_fixup_16(p+1, val >> 16);
- __runtime_fixup_16(p+2, val >> 32);
- __runtime_fixup_16(p+3, val >> 48);
+ __runtime_fixup_16(where, val);
+ __runtime_fixup_16(where + 4, val >> 16);
+ __runtime_fixup_16(where + 8, val >> 32);
+ __runtime_fixup_16(where + 12, val >> 48);
}
/* Immediate value is 6 bits starting at bit #16 */
@@ -81,15 +81,14 @@ static inline void __runtime_fixup_shift(void *where, unsigned long val)
u32 insn = le32_to_cpu(*p);
insn &= 0xffc0ffff;
insn |= (val & 63) << 16;
- aarch64_insn_patch_text_nosync(p, insn);
+ aarch64_insn_patch_text_nosync(where, insn);
}
/* Immediate value is 6 bits starting at bit #16 */
static inline void __runtime_fixup_mask(void *where, unsigned long val)
{
- __le32 *p = lm_alias(where);
- __runtime_fixup_16(p, val);
- __runtime_fixup_16(p+1, val >> 16);
+ __runtime_fixup_16(where, val);
+ __runtime_fixup_16(where + 4, val >> 16);
}
static inline void runtime_const_fixup(void (*fn)(void *, unsigned long),
---
I'll do some more sanity checks and address the rest of the comments
before posting out v4 soon after the merge window. Thank you again
for your feedback. Much appreciated.
--
Thanks and Regards,
Prateek
^ permalink raw reply related
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Sam Edwards @ 2026-04-11 20:40 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Maxime Chevallier,
Ovidiu Panait, Vladimir Oltean, Baruch Siach, Serge Semin,
Giuseppe Cavallaro, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <adjrtRSepmac2hpN@shell.armlinux.org.uk>
On Fri, Apr 10, 2026 at 5:23 AM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Thu, Apr 02, 2026 at 10:39:32AM -0700, Sam Edwards wrote:
> > On Thu, Apr 2, 2026 at 10:16 AM Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > > I've tested this on my Jetson Xavier platform. One of the issues I've
> > > had is that running iperf3 results in the receive side stalling because
> > > it runs out of descriptors. However, despite the receive ring
> > > eventually being re-filled and the hardware appropriately prodded, it
> > > steadfastly refuses to restart, despite the descriptors having been
> > > updated.
> >
> > Hi Russell,
> >
> > Just to make sure I understand correctly: before my patches, you've
> > been observing this problem on Xavier for a while (no interrupts, ring
> > goes dry); with my patches, the ring is refilled, but the dwmac5
> > doesn't resume DMA. (Ah, just saw your follow-up email.)
> >
> > > Any ideas?
> >
> > Off the top of my head, my hypothesis is that dwmac5 has an additional
> > tripwire when the receive DMA is exhausted, and the
> > stmmac_set_rx_tail_ptr()/stmmac_enable_dma_reception() at the end of
> > stmmac_rx_refill() aren't sufficient to wake it back up.
> >
> > I think this is new to dwmac5, because my RK3588 (dwmac4.20 iirc)
> > happily resumes after the same condition.
> >
> > You gave a lot of info; thanks! I'll try to scrape up some
> > documentation on dwmac5 to see if there's something more
> > stmmac_rx_refill() ought to be doing. I think I have a Xavier NX
> > around here somewhere, I'll see if I can repro the problem.
>
> I've added dma_rmb() into dwmac4_wrback_get_tx_status() and
> dwmac4_wrback_get_rx_status(), and with that I've had an iperf3
> instance finally complete... but only once:
Hi Russell,
To me it feels relevant that the T194 doesn't use first-party
ARM/Cortex cores but rather Nvidia's in-house "Carmel" architecture.
Do you suppose the cache there is quirky in such a way that either:
1) We're seeing poor cache hygiene in stmmac where other caches are
more forgiving (more likely)
2) Carmel's cache has a subtle hardware bug triggered by stmmac's
specific access pattern (less likely)?
I'm still trying to get my Xavier NX to boot on net-next. It's running
into eMMC corruption/stalls very early in the boot process (at
slightly different times; feels like a problem in autocalibration)
that I'm not seeing on older kernels. Once I'm done bisecting that
regression I'll take a deeper look at this stmmac mystery. :)
Cheers,
Sam
>
> root@tegra-ubuntu:~# iperf3 -c 192.168.248.1 -R
> Connecting to host 192.168.248.1, port 5201
> Reverse mode, remote host 192.168.248.1 is sending
> [ 5] local 192.168.248.174 port 42232 connected to 192.168.248.1 port 5201
> [ ID] Interval Transfer Bitrate
> [ 5] 0.00-1.00 sec 50.8 MBytes 426 Mbits/sec
> [ 5] 1.00-2.00 sec 54.9 MBytes 460 Mbits/sec
> [ 5] 2.00-3.00 sec 54.0 MBytes 453 Mbits/sec
> [ 5] 3.00-4.00 sec 53.8 MBytes 452 Mbits/sec
> [ 5] 4.00-5.00 sec 52.4 MBytes 438 Mbits/sec
> [ 5] 5.00-6.00 sec 54.3 MBytes 455 Mbits/sec
> [ 5] 6.00-7.00 sec 53.7 MBytes 452 Mbits/sec
> [ 5] 7.00-8.00 sec 52.8 MBytes 443 Mbits/sec
> [ 5] 8.00-9.00 sec 53.7 MBytes 451 Mbits/sec
> [ 5] 9.00-10.00 sec 54.3 MBytes 455 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.01 sec 537 MBytes 450 Mbits/sec 13 sender
> [ 5] 0.00-10.00 sec 535 MBytes 448 Mbits/sec receiver
>
> iperf Done.
>
> So, it seems better, but not completely solved.
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> index 2994df41ec2c..119f31c94b61 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> @@ -17,10 +17,12 @@ static int dwmac4_wrback_get_tx_status(struct stmmac_extra_stats *x,
> struct dma_desc *p,
> void __iomem *ioaddr)
> {
> - u32 tdes3 = le32_to_cpu(p->des3);
> + u32 tdes3;
> int ret = tx_done;
>
> /* Get tx owner first */
> + dma_rmb();
> + tdes3 = le32_to_cpu(p->des3);
> if (unlikely(tdes3 & TDES3_OWN))
> return tx_dma_own;
>
> @@ -70,12 +72,12 @@ static int dwmac4_wrback_get_tx_status(struct stmmac_extra_stats *x,
> static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
> struct dma_desc *p)
> {
> - u32 rdes1 = le32_to_cpu(p->des1);
> - u32 rdes2 = le32_to_cpu(p->des2);
> - u32 rdes3 = le32_to_cpu(p->des3);
> + u32 rdes1, rdes2, rdes3;
> int message_type;
> int ret = good_frame;
>
> + dma_rmb();
> + rdes3 = le32_to_cpu(p->des3);
> if (unlikely(rdes3 & RDES3_OWN))
> return dma_own;
>
> @@ -107,6 +109,7 @@ static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
>
> message_type = FIELD_GET(RDES1_PTP_MSG_TYPE_MASK, rdes1);
>
> + rdes1 = le32_to_cpu(p->des1);
> if (rdes1 & RDES1_IP_HDR_ERROR) {
> x->ip_hdr_err++;
> ret |= csum_none;
> @@ -152,6 +155,7 @@ static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
> if (rdes1 & RDES1_TIMESTAMP_DROPPED)
> x->timestamp_dropped++;
>
> + rdes2 = le32_to_cpu(p->des2);
> if (unlikely(rdes2 & RDES2_SA_FILTER_FAIL)) {
> x->sa_rx_filter_fail++;
> ret = discard_frame;
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [GIT PULL] Qualcomm clock fix for v7.0
From: Stephen Boyd @ 2026-04-11 23:22 UTC (permalink / raw)
To: Bjorn Andersson, linux-clk
Cc: linux-arm-msm, linux-arm-kernel, Dmitry Baryshkov
In-Reply-To: <20260326134515.67326-1-andersson@kernel.org>
Quoting Bjorn Andersson (2026-03-26 06:45:15)
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-clk-fixes-for-7.0
>
> for you to fetch changes up to 141af1be817c42c7f1e1605348d4b1983d319bea:
>
> clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source (2026-02-23 10:45:35 -0600)
>
> ----------------------------------------------------------------
Thanks. Pulled into clk-next
^ permalink raw reply
* Re: [GIT PULL] Allwinner Clock Changes for 7.1
From: Stephen Boyd @ 2026-04-11 23:24 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, linux-sunxi,
linux-arm-kernel, linux-clk
In-Reply-To: <adJu-NeYb70E-1yS@home.wens.tw>
Quoting Chen-Yu Tsai (2026-04-05 07:17:28)
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-7.1
>
> for you to fetch changes up to fb20ccf70cf695f178d7c32e2d33b376560df0ff:
>
> clk: sunxi-ng: sun55i-a523-r: Add missing r-spi module clock (2026-02-25 00:26:12 +0800)
>
> ----------------------------------------------------------------
Thanks. Pulled into clk-next
^ permalink raw reply
* Re: [GIT PULL] clk: samsung: drivers for v7.1
From: Stephen Boyd @ 2026-04-11 23:27 UTC (permalink / raw)
To: Krzysztof Kozlowski, Michael Turquette
Cc: Krzysztof Kozlowski, Chanwoo Choi, linux-clk, Sylwester Nawrocki,
Alim Akhtar, Peter Griffin, linux-arm-kernel, linux-samsung-soc,
linux-kernel
In-Reply-To: <20260409122504.71017-2-krzk@kernel.org>
Quoting Krzysztof Kozlowski (2026-04-09 05:25:03)
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-clk-7.1
>
> for you to fetch changes up to e57c36bc1a3e459239ead492ebce731a88a264b1:
>
> clk: samsung: exynos850: Add APM-to-AP mailbox clock (2026-03-24 13:43:19 +0100)
>
> ----------------------------------------------------------------
Thanks. Pulled into clk-next
^ permalink raw reply
* Re: [GIT PULL] Qualcomm clock updates for v7.1
From: Stephen Boyd @ 2026-04-11 23:35 UTC (permalink / raw)
To: Bjorn Andersson, linux-clk
Cc: linux-arm-msm, linux-arm-kernel, Taniya Das, Val Packett,
Krzysztof Kozlowski, Konrad Dybcio, John Crispin, Abel Vesa,
Kathiravan Thirumoorthy, Pengyu Luo, Dmitry Baryshkov,
Jagadeesh Kona, Prasanna Tolety, Vladimir Zapolskiy, White Lewis
In-Reply-To: <20260410223840.3976134-1-andersson@kernel.org>
Quoting Bjorn Andersson (2026-04-10 15:38:40)
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-clk-for-7.1
>
> for you to fetch changes up to a4f780cd5c7aa8c0d2d044ffd153f7a3a13ca81e:
>
> clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC (2026-04-08 21:00:09 -0500)
>
> ----------------------------------------------------------------
Thanks. Pulled into clk-next
^ permalink raw reply
* Re: [PATCH v5 0/5] Add support for AAEON SRG-IMX8P MCU
From: Guenter Roeck @ 2026-04-12 0:12 UTC (permalink / raw)
To: Thomas Perrot (Schneider Electric), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski
In-Reply-To: <20260408-dev-b4-aaeon-mcu-driver-v5-0-ad98bd481668@bootlin.com>
On 4/8/26 10:21, Thomas Perrot (Schneider Electric) wrote:
> This patch series introduces support for the AAEON SRG-IMX8P embedded
> controller (MCU). The MCU is connected via I2C and provides GPIO and
> watchdog functionality for the SRG-IMX8P board.
>
> The series includes:
> - Device tree binding for the MFD driver
> - MFD driver that serves as the core driver for the MCU
> - GPIO driver implementing the GPIO functionality
> - Watchdog driver for system monitoring
> - MAINTAINERS entry for the new drivers
>
> The drivers follow the standard Linux kernel subsystem patterns, with
> the MFD driver registering the sub-devices (GPIO and watchdog) which
> are then handled by their respective subsystem drivers.
>
> Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
Sashiko has some interesting feedback that might be worth looking into.
https://sashiko.dev/#/patchset/20260408-dev-b4-aaeon-mcu-driver-v5-0-ad98bd481668%40bootlin.com
Guenter
^ permalink raw reply
* [GIT PULL] CRC updates for 7.1
From: Eric Biggers @ 2026-04-12 0:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-crypto, linux-arm-kernel, linux-kernel, Ard Biesheuvel,
Demian Shulhan
The following changes since commit 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681:
Linux 7.0-rc3 (2026-03-08 16:56:54 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git tags/crc-for-linus
for you to fetch changes up to 8fdef85d601db670e9c178314eedffe7bbb07e52:
lib/crc: arm64: Simplify intrinsics implementation (2026-04-02 16:14:53 -0700)
----------------------------------------------------------------
- Several improvements related to crc_kunit, to align with the
standard KUnit conventions and make it easier for developers and CI
systems to run this test suite
- Add an arm64-optimized implementation of CRC64-NVME
- Remove unused code for big endian arm64
----------------------------------------------------------------
Ard Biesheuvel (3):
lib/crc: arm64: Drop unnecessary chunking logic from crc64
lib/crc: arm64: Use existing macros for kernel-mode FPU cflags
lib/crc: arm64: Simplify intrinsics implementation
Demian Shulhan (1):
lib/crc: arm64: add NEON accelerated CRC64-NVMe implementation
Eric Biggers (8):
lib/crc: tests: Make crc_kunit test only the enabled CRC variants
lib/crc: tests: Add CRC_ENABLE_ALL_FOR_KUNIT
lib/crc: tests: Add a .kunitconfig file
kunit: configs: Enable all CRC tests in all_tests.config
crypto: crc32c - Remove more outdated usage information
crypto: crc32c - Remove another outdated comment
lib/crc: arm64: Drop check for CONFIG_KERNEL_MODE_NEON
lib/crc: arm64: Assume a little-endian kernel
crypto/crc32c.c | 19 +-------
lib/crc/.kunitconfig | 3 ++
lib/crc/Kconfig | 20 ++++++---
lib/crc/Makefile | 7 ++-
lib/crc/arm64/crc-t10dif-core.S | 56 ++++++++++++------------
lib/crc/arm64/crc32-core.S | 9 +---
lib/crc/arm64/crc64-neon-inner.c | 65 ++++++++++++++++++++++++++++
lib/crc/arm64/crc64.h | 28 ++++++++++++
lib/crc/tests/crc_kunit.c | 28 +++++++++---
tools/testing/kunit/configs/all_tests.config | 2 +
10 files changed, 172 insertions(+), 65 deletions(-)
create mode 100644 lib/crc/.kunitconfig
create mode 100644 lib/crc/arm64/crc64-neon-inner.c
create mode 100644 lib/crc/arm64/crc64.h
^ permalink raw reply
* [GIT PULL] Crypto library updates for 7.1
From: Eric Biggers @ 2026-04-12 0:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-crypto, linux-arm-kernel, linux-kernel, Ard Biesheuvel,
Jason A. Donenfeld, Herbert Xu, AlanSong-oc, Arnd Bergmann,
Dan Williams, David Howells, Johannes Berg, Randy Dunlap
The following changes since commit 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681:
Linux 7.0-rc3 (2026-03-08 16:56:54 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git tags/libcrypto-for-linus
for you to fetch changes up to 12b11e47f126d097839fd2f077636e2139b0151b:
lib/crypto: arm64: Assume a little-endian kernel (2026-04-01 13:02:15 -0700)
----------------------------------------------------------------
- Migrate more hash algorithms from the traditional crypto subsystem
to lib/crypto/.
Like the algorithms migrated earlier (e.g. SHA-*), this simplifies
the implementations, improves performance, enables further
simplifications in calling code, and solves various other issues:
- AES CBC-based MACs (AES-CMAC, AES-XCBC-MAC, and AES-CBC-MAC)
- Support these algorithms in lib/crypto/ using the AES
library and the existing arm64 assembly code
- Reimplement the traditional crypto API's "cmac(aes)",
"xcbc(aes)", and "cbcmac(aes)" on top of the library
- Convert mac80211 to use the AES-CMAC library. Note: several
other subsystems can use it too and will be converted later
- Drop the broken, nonstandard, and likely unused support for
"xcbc(aes)" with key lengths other than 128 bits
- Enable optimizations by default
- GHASH
- Migrate the standalone GHASH code into lib/crypto/
- Integrate the GHASH code more closely with the very similar
POLYVAL code, and improve the generic GHASH implementation
to resist cache-timing attacks and use much less memory
- Reimplement the AES-GCM library and the "gcm" crypto_aead
template on top of the GHASH library. Remove "ghash" from
the crypto_shash API, as it's no longer needed
- Enable optimizations by default
- SM3
- Migrate the kernel's existing SM3 code into lib/crypto/, and
reimplement the traditional crypto API's "sm3" on top of it
- I don't recommend using SM3, but this cleanup is worthwhile
to organize the code the same way as other algorithms
- Testing improvements
- Add a KUnit test suite for each of the new library APIs
- Migrate the existing ChaCha20Poly1305 test to KUnit
- Make the KUnit all_tests.config enable all crypto library tests
- Move the test kconfig options to the Runtime Testing menu
- Other updates to arch-optimized crypto code
- Optimize SHA-256 for Zhaoxin CPUs using the Padlock Hash Engine
- Remove some MD5 implementations that are no longer worth keeping
- Drop big endian and voluntary preemption support from the arm64
code, as those configurations are no longer supported on arm64
- Make jitterentropy and samples/tsm-mr use the crypto library APIs
Note: the overall diffstat is neutral, but when the test code is
excluded it is significantly negative:
Tests: 13 files changed, 1982 insertions(+), 888 deletions(-)
Non-test: 141 files changed, 2897 insertions(+), 3987 deletions(-)
All: 154 files changed, 4879 insertions(+), 4875 deletions(-)
----------------------------------------------------------------
AlanSong-oc (1):
lib/crypto: x86/sha256: PHE Extensions optimized SHA256 transform function
David Howells (1):
crypto: jitterentropy - Use SHA-3 library
Eric Biggers (64):
lib/crypto: aes: Add support for CBC-based MACs
crypto: aes - Add cmac, xcbc, and cbcmac algorithms using library
crypto: arm64/aes - Fix 32-bit aes_mac_update() arg treated as 64-bit
lib/crypto: arm64/aes: Move assembly code for AES modes into libaes
lib/crypto: arm64/aes: Migrate optimized CBC-based MACs into library
lib/crypto: tests: Add KUnit tests for CBC-based MACs
lib/crypto: aes: Add FIPS self-test for CMAC
wifi: mac80211: Use AES-CMAC library in ieee80211_aes_cmac()
wifi: mac80211: Use AES-CMAC library in aes_s2v()
lib/crypto: tests: Introduce CRYPTO_LIB_ENABLE_ALL_FOR_KUNIT
kunit: configs: Enable all crypto library tests in all_tests.config
lib/crypto: tests: Drop the default to CRYPTO_SELFTESTS
lib/crypto: Remove unused file blockhash.h
lib/crypto: arm64: Drop checks for CONFIG_KERNEL_MODE_NEON
sample/tsm-mr: Use SHA-2 library APIs
coco/guest: Remove unneeded selection of CRYPTO
lib/crypto: gf128hash: Rename polyval module to gf128hash
lib/crypto: gf128hash: Support GF128HASH_ARCH without all POLYVAL functions
lib/crypto: gf128hash: Add GHASH support
lib/crypto: tests: Add KUnit tests for GHASH
crypto: arm/ghash - Make the "ghash" crypto_shash NEON-only
crypto: arm/ghash - Move NEON GHASH assembly into its own file
lib/crypto: arm/ghash: Migrate optimized code into library
crypto: arm64/ghash - Move NEON GHASH assembly into its own file
lib/crypto: arm64/ghash: Migrate optimized code into library
crypto: arm64/aes-gcm - Rename struct ghash_key and make fixed-sized
lib/crypto: powerpc/ghash: Migrate optimized code into library
lib/crypto: riscv/ghash: Migrate optimized code into library
lib/crypto: s390/ghash: Migrate optimized code into library
lib/crypto: x86/ghash: Migrate optimized code into library
crypto: gcm - Use GHASH library instead of crypto_ahash
crypto: ghash - Remove ghash from crypto_shash API
lib/crypto: gf128mul: Remove unused 4k_lle functions
lib/crypto: gf128hash: Remove unused content from ghash.h
lib/crypto: aesgcm: Use GHASH library API
crypto: sm3 - Fold sm3_init() into its caller
crypto: sm3 - Remove sm3_zero_message_hash and SM3_T[1-2]
crypto: sm3 - Rename CRYPTO_SM3_GENERIC to CRYPTO_SM3
lib/crypto: sm3: Add SM3 library API
lib/crypto: tests: Add KUnit tests for SM3
crypto: sm3 - Replace with wrapper around library
lib/crypto: arm64/sm3: Migrate optimized code into library
lib/crypto: riscv/sm3: Migrate optimized code into library
lib/crypto: x86/sm3: Migrate optimized code into library
crypto: sm3 - Remove sm3_base.h
crypto: sm3 - Remove the original "sm3_block_generic()"
crypto: sm3 - Remove 'struct sm3_state'
lib: Move crypto library tests to Runtime Testing menu
lib/crypto: mips: Drop optimized MD5 code
lib/crypto: sparc: Drop optimized MD5 code
lib/crypto: tests: Migrate ChaCha20Poly1305 self-test to KUnit
lib/crypto: aescfb: Don't disable IRQs during AES block encryption
lib/crypto: aesgcm: Don't disable IRQs during AES block encryption
lib/crypto: Include <crypto/utils.h> instead of <crypto/algapi.h>
lib/crypto: arm64/aes: Remove obsolete chunking logic
lib/crypto: arm64/chacha: Remove obsolete chunking logic
lib/crypto: arm64/gf128hash: Remove obsolete chunking logic
lib/crypto: arm64/poly1305: Remove obsolete chunking logic
lib/crypto: arm64/sha1: Remove obsolete chunking logic
lib/crypto: arm64/sha256: Remove obsolete chunking logic
lib/crypto: arm64/sha512: Remove obsolete chunking logic
lib/crypto: arm64/sha3: Remove obsolete chunking logic
arm64: fpsimd: Remove obsolete cond_yield macro
lib/crypto: arm64: Assume a little-endian kernel
MAINTAINERS | 4 +-
arch/arm/crypto/Kconfig | 13 +-
arch/arm/crypto/ghash-ce-core.S | 171 +--
arch/arm/crypto/ghash-ce-glue.c | 166 +--
arch/arm64/configs/defconfig | 2 +-
arch/arm64/crypto/Kconfig | 29 +-
arch/arm64/crypto/Makefile | 10 +-
arch/arm64/crypto/aes-ce-ccm-glue.c | 17 +-
arch/arm64/crypto/aes-glue.c | 261 +---
arch/arm64/crypto/aes-neonbs-glue.c | 15 +-
arch/arm64/crypto/ghash-ce-core.S | 221 +--
arch/arm64/crypto/ghash-ce-glue.c | 168 +--
arch/arm64/crypto/sm3-ce-glue.c | 70 -
arch/arm64/crypto/sm3-neon-glue.c | 67 -
arch/arm64/include/asm/assembler.h | 22 -
arch/loongarch/configs/loongson32_defconfig | 2 +-
arch/loongarch/configs/loongson64_defconfig | 2 +-
arch/m68k/configs/amiga_defconfig | 2 +-
arch/m68k/configs/apollo_defconfig | 2 +-
arch/m68k/configs/atari_defconfig | 2 +-
arch/m68k/configs/bvme6000_defconfig | 2 +-
arch/m68k/configs/hp300_defconfig | 2 +-
arch/m68k/configs/mac_defconfig | 2 +-
arch/m68k/configs/multi_defconfig | 2 +-
arch/m68k/configs/mvme147_defconfig | 2 +-
arch/m68k/configs/mvme16x_defconfig | 2 +-
arch/m68k/configs/q40_defconfig | 2 +-
arch/m68k/configs/sun3_defconfig | 2 +-
arch/m68k/configs/sun3x_defconfig | 2 +-
arch/powerpc/crypto/Kconfig | 5 +-
arch/powerpc/crypto/Makefile | 8 +-
arch/powerpc/crypto/aesp8-ppc.h | 1 -
arch/powerpc/crypto/ghash.c | 160 ---
arch/powerpc/crypto/vmx.c | 10 +-
arch/riscv/crypto/Kconfig | 24 -
arch/riscv/crypto/Makefile | 6 -
arch/riscv/crypto/ghash-riscv64-glue.c | 146 --
arch/riscv/crypto/sm3-riscv64-glue.c | 97 --
arch/s390/configs/debug_defconfig | 3 +-
arch/s390/configs/defconfig | 3 +-
arch/s390/crypto/Kconfig | 10 -
arch/s390/crypto/Makefile | 1 -
arch/s390/crypto/ghash_s390.c | 144 --
arch/x86/crypto/Kconfig | 23 -
arch/x86/crypto/Makefile | 6 -
arch/x86/crypto/aesni-intel_glue.c | 1 +
arch/x86/crypto/ghash-clmulni-intel_glue.c | 163 ---
arch/x86/crypto/sm3_avx_glue.c | 100 --
crypto/Kconfig | 17 +-
crypto/Makefile | 3 +-
crypto/aes.c | 183 ++-
crypto/gcm.c | 413 +-----
crypto/ghash-generic.c | 162 ---
crypto/hctr2.c | 2 +-
crypto/jitterentropy-kcapi.c | 114 +-
crypto/jitterentropy.c | 25 +-
crypto/jitterentropy.h | 19 +-
crypto/sm3.c | 89 ++
crypto/sm3_generic.c | 72 -
crypto/tcrypt.c | 9 -
crypto/testmgr.c | 28 +-
crypto/testmgr.h | 109 --
drivers/crypto/Kconfig | 2 +-
drivers/crypto/starfive/Kconfig | 2 +-
drivers/crypto/starfive/jh7110-aes.c | 4 +-
drivers/crypto/starfive/jh7110-hash.c | 8 +-
drivers/virt/coco/guest/Kconfig | 1 -
include/crypto/aes-cbc-macs.h | 154 ++
include/crypto/aes.h | 66 +
include/crypto/chacha20poly1305.h | 2 -
include/crypto/gcm.h | 4 +-
include/crypto/{polyval.h => gf128hash.h} | 126 +-
include/crypto/gf128mul.h | 17 +-
include/crypto/ghash.h | 12 -
include/crypto/internal/blockhash.h | 52 -
include/crypto/sm3.h | 85 +-
include/crypto/sm3_base.h | 82 --
lib/Kconfig.debug | 2 +
lib/crypto/.kunitconfig | 24 +-
lib/crypto/Kconfig | 68 +-
lib/crypto/Makefile | 79 +-
lib/crypto/aes.c | 231 ++-
lib/crypto/aescfb.c | 27 +-
lib/crypto/aesgcm.c | 76 +-
lib/crypto/arm/gf128hash.h | 43 +
lib/crypto/arm/ghash-neon-core.S | 209 +++
{arch/arm64/crypto => lib/crypto/arm64}/aes-ce.S | 3 +-
lib/crypto/arm64/aes-cipher-core.S | 10 -
.../arm64/crypto => lib/crypto/arm64}/aes-modes.S | 25 +-
{arch/arm64/crypto => lib/crypto/arm64}/aes-neon.S | 2 +-
lib/crypto/arm64/aes.h | 75 +-
lib/crypto/arm64/chacha-neon-core.S | 16 -
lib/crypto/arm64/chacha.h | 16 +-
lib/crypto/arm64/gf128hash.h | 121 ++
lib/crypto/arm64/ghash-neon-core.S | 220 +++
lib/crypto/arm64/poly1305.h | 14 +-
lib/crypto/arm64/polyval.h | 80 --
lib/crypto/arm64/sha1-ce-core.S | 22 +-
lib/crypto/arm64/sha1.h | 15 +-
lib/crypto/arm64/sha256-ce.S | 55 +-
lib/crypto/arm64/sha256.h | 37 +-
lib/crypto/arm64/sha3-ce-core.S | 8 +-
lib/crypto/arm64/sha3.h | 15 +-
lib/crypto/arm64/sha512-ce-core.S | 28 +-
lib/crypto/arm64/sha512.h | 20 +-
.../crypto => lib/crypto/arm64}/sm3-ce-core.S | 19 +-
.../crypto => lib/crypto/arm64}/sm3-neon-core.S | 9 +-
lib/crypto/arm64/sm3.h | 41 +
lib/crypto/chacha.c | 2 +-
lib/crypto/chacha20poly1305.c | 14 -
lib/crypto/fips.h | 5 +
lib/crypto/{polyval.c => gf128hash.c} | 183 ++-
lib/crypto/gf128mul.c | 73 +-
lib/crypto/memneq.c | 4 +-
lib/crypto/mips/md5.h | 65 -
lib/crypto/powerpc/.gitignore | 1 +
lib/crypto/powerpc/gf128hash.h | 109 ++
.../crypto => lib/crypto/powerpc}/ghashp8-ppc.pl | 1 +
lib/crypto/riscv/gf128hash.h | 57 +
.../crypto/riscv}/ghash-riscv64-zvkg.S | 13 +-
.../crypto/riscv}/sm3-riscv64-zvksh-zvkb.S | 3 +-
lib/crypto/riscv/sm3.h | 39 +
lib/crypto/s390/gf128hash.h | 54 +
lib/crypto/sm3.c | 148 +-
lib/crypto/sparc/md5.h | 48 -
lib/crypto/sparc/md5_asm.S | 70 -
lib/crypto/tests/Kconfig | 86 +-
lib/crypto/tests/Makefile | 4 +
lib/crypto/tests/aes-cmac-testvecs.h | 181 +++
lib/crypto/tests/aes_cbc_macs_kunit.c | 228 +++
.../chacha20poly1305_kunit.c} | 1493 ++++++++++----------
lib/crypto/tests/ghash-testvecs.h | 186 +++
lib/crypto/tests/ghash_kunit.c | 194 +++
lib/crypto/tests/polyval_kunit.c | 2 +-
lib/crypto/tests/sm3-testvecs.h | 231 +++
lib/crypto/tests/sm3_kunit.c | 31 +
lib/crypto/x86/{polyval.h => gf128hash.h} | 72 +-
.../crypto/x86/ghash-pclmul.S | 98 +-
lib/crypto/x86/sha256.h | 25 +
.../x86/crypto => lib/crypto/x86}/sm3-avx-asm_64.S | 13 +-
lib/crypto/x86/sm3.h | 39 +
net/mac80211/Kconfig | 2 +-
net/mac80211/aes_cmac.c | 65 +-
net/mac80211/aes_cmac.h | 12 +-
net/mac80211/fils_aead.c | 48 +-
net/mac80211/key.c | 11 +-
net/mac80211/key.h | 3 +-
net/mac80211/wpa.c | 13 +-
samples/Kconfig | 2 +
samples/tsm-mr/tsm_mr_sample.c | 68 +-
scripts/crypto/gen-fips-testvecs.py | 10 +
scripts/crypto/gen-hash-testvecs.py | 97 +-
security/integrity/ima/Kconfig | 2 +-
tools/testing/kunit/configs/all_tests.config | 2 +
154 files changed, 4879 insertions(+), 4875 deletions(-)
delete mode 100644 arch/arm64/crypto/sm3-ce-glue.c
delete mode 100644 arch/arm64/crypto/sm3-neon-glue.c
delete mode 100644 arch/powerpc/crypto/ghash.c
delete mode 100644 arch/riscv/crypto/ghash-riscv64-glue.c
delete mode 100644 arch/riscv/crypto/sm3-riscv64-glue.c
delete mode 100644 arch/s390/crypto/ghash_s390.c
delete mode 100644 arch/x86/crypto/ghash-clmulni-intel_glue.c
delete mode 100644 arch/x86/crypto/sm3_avx_glue.c
delete mode 100644 crypto/ghash-generic.c
create mode 100644 crypto/sm3.c
delete mode 100644 crypto/sm3_generic.c
create mode 100644 include/crypto/aes-cbc-macs.h
rename include/crypto/{polyval.h => gf128hash.h} (60%)
delete mode 100644 include/crypto/internal/blockhash.h
delete mode 100644 include/crypto/sm3_base.h
create mode 100644 lib/crypto/arm/gf128hash.h
create mode 100644 lib/crypto/arm/ghash-neon-core.S
rename {arch/arm64/crypto => lib/crypto/arm64}/aes-ce.S (96%)
rename {arch/arm64/crypto => lib/crypto/arm64}/aes-modes.S (98%)
rename {arch/arm64/crypto => lib/crypto/arm64}/aes-neon.S (99%)
create mode 100644 lib/crypto/arm64/gf128hash.h
create mode 100644 lib/crypto/arm64/ghash-neon-core.S
delete mode 100644 lib/crypto/arm64/polyval.h
rename {arch/arm64/crypto => lib/crypto/arm64}/sm3-ce-core.S (89%)
rename {arch/arm64/crypto => lib/crypto/arm64}/sm3-neon-core.S (98%)
create mode 100644 lib/crypto/arm64/sm3.h
rename lib/crypto/{polyval.c => gf128hash.c} (61%)
delete mode 100644 lib/crypto/mips/md5.h
create mode 100644 lib/crypto/powerpc/gf128hash.h
rename {arch/powerpc/crypto => lib/crypto/powerpc}/ghashp8-ppc.pl (98%)
create mode 100644 lib/crypto/riscv/gf128hash.h
rename {arch/riscv/crypto => lib/crypto/riscv}/ghash-riscv64-zvkg.S (91%)
rename {arch/riscv/crypto => lib/crypto/riscv}/sm3-riscv64-zvksh-zvkb.S (97%)
create mode 100644 lib/crypto/riscv/sm3.h
create mode 100644 lib/crypto/s390/gf128hash.h
delete mode 100644 lib/crypto/sparc/md5.h
delete mode 100644 lib/crypto/sparc/md5_asm.S
create mode 100644 lib/crypto/tests/aes-cmac-testvecs.h
create mode 100644 lib/crypto/tests/aes_cbc_macs_kunit.c
rename lib/crypto/{chacha20poly1305-selftest.c => tests/chacha20poly1305_kunit.c} (91%)
create mode 100644 lib/crypto/tests/ghash-testvecs.h
create mode 100644 lib/crypto/tests/ghash_kunit.c
create mode 100644 lib/crypto/tests/sm3-testvecs.h
create mode 100644 lib/crypto/tests/sm3_kunit.c
rename lib/crypto/x86/{polyval.h => gf128hash.h} (51%)
rename arch/x86/crypto/ghash-clmulni-intel_asm.S => lib/crypto/x86/ghash-pclmul.S (54%)
rename {arch/x86/crypto => lib/crypto/x86}/sm3-avx-asm_64.S (98%)
create mode 100644 lib/crypto/x86/sm3.h
^ permalink raw reply
* Re: [PATCH] clk: visconti: pll: initialize clk_init_data to zero
From: Stephen Boyd @ 2026-04-12 0:55 UTC (permalink / raw)
To: Brian Masney, Michael Turquette, Nobuhiro Iwamatsu, Rosen Penev
Cc: linux-clk, linux-arm-kernel, linux-kernel, Brian Masney
In-Reply-To: <20260330-clk-visconti-init-v1-1-ac3e825e54b5@redhat.com>
Quoting Brian Masney (2026-03-30 07:32:37)
> Sashiko reported the following:
>
> > The struct clk_init_data init is declared on the stack without being
> > fully zero-initialized. While fields like name, flags, parent_names,
> > num_parents, and ops are explicitly assigned, the parent_data and
> > parent_hws fields are left containing stack garbage.
>
> clk_core_populate_parent_map() currently prefers the parent names over
> the parent data and hws, so this isn't a problem at the moment. If that
> ordering ever changed in the future, then this could lead to some
> unexpected crashes. Let's just go ahead and make sure that the struct
> clk_init_data is initialized to zero as a good practice.
>
> Fixes: b4cbe606dc367 ("clk: visconti: Add support common clock driver and reset driver")
> Link: https://sashiko.dev/#/patchset/20260326042317.122536-1-rosenp%40gmail.com
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH 1/2] thermal/drivers/imx: Fix thermal zone leak on probe error path
From: Frank Li @ 2026-04-12 0:58 UTC (permalink / raw)
To: Felix Gu
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel, linux-pm, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260412-imx-v1-1-cc3b45d63811@gmail.com>
On Sun, Apr 12, 2026 at 03:03:03AM +0800, Felix Gu wrote:
> If pm_runtime_resume_and_get() fails after the thermal zone has been
> registered, the probe error path cleans up runtime PM but skips
> thermal_zone_device_unregister(), leaking the thermal zone device.
>
> Move thermal_zone_device_unregister() into disable_runtime_pm so all
Use devm_thermal_of_zone_register() to fix this problem
Frank
^ permalink raw reply
* Re: [PATCH 2/2] thermal/drivers/imxl:Fix runtime PM handling on early returns
From: Frank Li @ 2026-04-12 1:00 UTC (permalink / raw)
To: Felix Gu
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel, linux-pm, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260412-imx-v1-2-cc3b45d63811@gmail.com>
On Sun, Apr 12, 2026 at 03:03:04AM +0800, Felix Gu wrote:
> Use PM_RUNTIME_ACQUIRE() in imx_get_temp() and imx_set_trip_temp() so
> runtime PM references are released correctly even when the functions
> return early on errors.
>
> Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/thermal/imx_thermal.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> index 68f9ce41a670..9d9ae7871068 100644
> --- a/drivers/thermal/imx_thermal.c
> +++ b/drivers/thermal/imx_thermal.c
> @@ -260,8 +260,9 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
> u32 val;
> int ret;
>
> - ret = pm_runtime_resume_and_get(data->dev);
> - if (ret < 0)
> + PM_RUNTIME_ACQUIRE(data->dev, pm);
> + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> + if (ret)
> return ret;
>
> regmap_read(map, soc_data->temp_data, &val);
> @@ -302,8 +303,6 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
> enable_irq(data->irq);
> }
>
> - pm_runtime_put(data->dev);
> -
> return 0;
> }
>
> @@ -337,8 +336,9 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
> struct imx_thermal_data *data = thermal_zone_device_priv(tz);
> int ret;
>
> - ret = pm_runtime_resume_and_get(data->dev);
> - if (ret < 0)
> + PM_RUNTIME_ACQUIRE(data->dev, pm);
> + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> + if (ret)
> return ret;
>
> /* do not allow passive to be set higher than critical */
> @@ -348,8 +348,6 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
> imx_set_alarm_temp(data, temp);
> trips[IMX_TRIP_PASSIVE].temperature = temp;
>
> - pm_runtime_put(data->dev);
> -
> return 0;
> }
>
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] pmdomain: imx: Make IMX8M/IMX9 BLK_CTRL tristate
From: Frank Li @ 2026-04-12 1:07 UTC (permalink / raw)
To: Zhipeng Wang
Cc: ulfh, s.hauer, kernel, festevam, linux-pm, imx, linux-arm-kernel,
linux-kernel, xuegang.liu, jindong.yue
In-Reply-To: <20260410092735.1065294-1-zhipeng.wang_1@nxp.com>
On Fri, Apr 10, 2026 at 06:27:35PM +0900, Zhipeng Wang wrote:
> Convert IMX8M_BLK_CTRL and IMX9_BLK_CTRL from bool to tristate
> to allow building as loadable modules.
>
> Add prompt strings to make these options visible and configurable
> in menuconfig, keeping them enabled by default on appropriate platforms.
>
> Also remove the IMX_GPCV2_PM_DOMAINS dependency from IMX9_BLK_CTRL
> since i.MX93 doesn't use GPCv2 power domains.
Does it cause build failure at GPCv2 platform? Or previous dependency
actually wrong.
Frank
>
> Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>
> ---
> drivers/pmdomain/imx/Kconfig | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pmdomain/imx/Kconfig b/drivers/pmdomain/imx/Kconfig
> index 00203615c65e..9168d183b0c5 100644
> --- a/drivers/pmdomain/imx/Kconfig
> +++ b/drivers/pmdomain/imx/Kconfig
> @@ -10,15 +10,18 @@ config IMX_GPCV2_PM_DOMAINS
> default y if SOC_IMX7D
>
> config IMX8M_BLK_CTRL
> - bool
> - default SOC_IMX8M && IMX_GPCV2_PM_DOMAINS
> + tristate "i.MX8M BLK CTRL driver"
> + depends on SOC_IMX8M
> + depends on IMX_GPCV2_PM_DOMAINS
> depends on PM_GENERIC_DOMAINS
> depends on COMMON_CLK
> + default y
>
> config IMX9_BLK_CTRL
> - bool
> - default SOC_IMX9 && IMX_GPCV2_PM_DOMAINS
> + tristate "i.MX93 BLK CTRL driver"
> + depends on SOC_IMX9
> depends on PM_GENERIC_DOMAINS
> + default y
>
> config IMX_SCU_PD
> bool "IMX SCU Power Domain driver"
> --
> 2.34.1
>
^ permalink raw reply
* Questions On Request/Partnership
From: John Lucas @ 2026-04-12 3:03 UTC (permalink / raw)
To: linux-arm-kernel
Greetings linux-arm-kernel,
I hope this message finds you well. Kindly confirm if you have
received the loan offer letter.
The company has a large portfolio in Eastern part
of Europe, Middle East and Asia which he earmarked for
investment.
If this is of interest to you, get back to me and I will give you
further details and my personal information
I will give you good news immediately as soon as I hear from
you. I await your response
Warm regards,
John Lucas
Financial Consultant
^ permalink raw reply
* [soc:arm/fixes] BUILD SUCCESS 3e2444044d160e33ec2b139d1e4f9691bb9d9bac
From: kernel test robot @ 2026-04-12 5:25 UTC (permalink / raw)
To: Krzysztof Kozlowski; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: 3e2444044d160e33ec2b139d1e4f9691bb9d9bac Merge tag 'mvebu-fixes-7.0-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes
elapsed time: 725m
configs tested: 207
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260412 gcc-11.5.0
arc randconfig-002-20260412 gcc-11.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm aspeed_g5_defconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm randconfig-001-20260412 gcc-11.5.0
arm randconfig-002-20260412 gcc-11.5.0
arm randconfig-003-20260412 gcc-11.5.0
arm randconfig-004-20260412 gcc-11.5.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260412 clang-19
arm64 randconfig-002-20260412 clang-19
arm64 randconfig-003-20260412 clang-19
arm64 randconfig-004-20260412 clang-19
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260412 clang-19
csky randconfig-002-20260412 clang-19
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260412 clang-23
hexagon randconfig-002-20260412 clang-23
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260412 gcc-14
i386 buildonly-randconfig-002-20260412 gcc-14
i386 buildonly-randconfig-003-20260412 gcc-14
i386 buildonly-randconfig-004-20260412 gcc-14
i386 buildonly-randconfig-005-20260412 gcc-14
i386 buildonly-randconfig-006-20260412 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260412 clang-20
i386 randconfig-002-20260412 clang-20
i386 randconfig-003-20260412 clang-20
i386 randconfig-004-20260412 clang-20
i386 randconfig-005-20260412 clang-20
i386 randconfig-006-20260412 clang-20
i386 randconfig-007-20260412 clang-20
i386 randconfig-011-20260412 gcc-14
i386 randconfig-012-20260412 gcc-14
i386 randconfig-013-20260412 gcc-14
i386 randconfig-014-20260412 gcc-14
i386 randconfig-015-20260412 gcc-14
i386 randconfig-016-20260412 gcc-14
i386 randconfig-017-20260412 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260412 clang-23
loongarch randconfig-002-20260412 clang-23
loongarch randconfig-002-20260412 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips db1xxx_defconfig clang-23
mips loongson3_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260412 clang-23
nios2 randconfig-001-20260412 gcc-11.5.0
nios2 randconfig-002-20260412 clang-23
nios2 randconfig-002-20260412 gcc-8.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260412 gcc-15.2.0
parisc randconfig-002-20260412 gcc-15.2.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260412 gcc-15.2.0
powerpc randconfig-002-20260412 gcc-15.2.0
powerpc64 randconfig-001-20260412 gcc-15.2.0
powerpc64 randconfig-002-20260412 gcc-15.2.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260412 clang-23
riscv randconfig-001-20260412 gcc-15.2.0
riscv randconfig-002-20260412 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260412 clang-23
s390 randconfig-001-20260412 gcc-15.2.0
s390 randconfig-002-20260412 clang-23
s390 randconfig-002-20260412 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh kfr2r09-romimage_defconfig gcc-15.2.0
sh randconfig-001-20260412 clang-23
sh randconfig-001-20260412 gcc-15.2.0
sh randconfig-002-20260412 clang-23
sh randconfig-002-20260412 gcc-15.2.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260412 clang-23
sparc randconfig-002-20260412 clang-23
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260412 clang-23
sparc64 randconfig-002-20260412 clang-23
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260412 clang-23
um randconfig-002-20260412 clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260412 clang-20
x86_64 buildonly-randconfig-002-20260412 clang-20
x86_64 buildonly-randconfig-003-20260412 clang-20
x86_64 buildonly-randconfig-004-20260412 clang-20
x86_64 buildonly-randconfig-005-20260412 clang-20
x86_64 buildonly-randconfig-006-20260412 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260412 clang-20
x86_64 randconfig-002-20260412 clang-20
x86_64 randconfig-003-20260412 clang-20
x86_64 randconfig-004-20260412 clang-20
x86_64 randconfig-005-20260412 clang-20
x86_64 randconfig-006-20260412 clang-20
x86_64 randconfig-011-20260412 gcc-14
x86_64 randconfig-012-20260412 gcc-14
x86_64 randconfig-013-20260412 gcc-14
x86_64 randconfig-014-20260412 gcc-14
x86_64 randconfig-015-20260412 gcc-14
x86_64 randconfig-016-20260412 gcc-14
x86_64 randconfig-071-20260412 clang-20
x86_64 randconfig-072-20260412 clang-20
x86_64 randconfig-073-20260412 clang-20
x86_64 randconfig-074-20260412 clang-20
x86_64 randconfig-074-20260412 gcc-14
x86_64 randconfig-075-20260412 clang-20
x86_64 randconfig-076-20260412 clang-20
x86_64 randconfig-076-20260412 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260412 clang-23
xtensa randconfig-002-20260412 clang-23
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [soc:soc/drivers] BUILD SUCCESS 33a20cdaf41d08a66581cc01a60c1a3d596ba9cd
From: kernel test robot @ 2026-04-12 5:25 UTC (permalink / raw)
To: Krzysztof Kozlowski; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/drivers
branch HEAD: 33a20cdaf41d08a66581cc01a60c1a3d596ba9cd Merge tag 'ffa-fix-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
elapsed time: 723m
configs tested: 255
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260412 gcc-11.5.0
arc randconfig-002-20260412 gcc-10.5.0
arc randconfig-002-20260412 gcc-11.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm aspeed_g5_defconfig gcc-15.2.0
arm defconfig clang-23
arm defconfig gcc-15.2.0
arm pxa168_defconfig clang-19
arm randconfig-001-20260412 clang-23
arm randconfig-001-20260412 gcc-11.5.0
arm randconfig-002-20260412 gcc-11.5.0
arm randconfig-002-20260412 gcc-14.3.0
arm randconfig-003-20260412 gcc-10.5.0
arm randconfig-003-20260412 gcc-11.5.0
arm randconfig-004-20260412 gcc-11.5.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260412 clang-19
arm64 randconfig-002-20260412 clang-19
arm64 randconfig-002-20260412 gcc-8.5.0
arm64 randconfig-003-20260412 clang-18
arm64 randconfig-003-20260412 clang-19
arm64 randconfig-004-20260412 clang-19
arm64 randconfig-004-20260412 gcc-8.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260412 clang-19
csky randconfig-001-20260412 gcc-15.2.0
csky randconfig-002-20260412 clang-19
csky randconfig-002-20260412 gcc-14.3.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig clang-23
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260412 clang-23
hexagon randconfig-002-20260412 clang-23
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260412 gcc-14
i386 buildonly-randconfig-002-20260412 clang-20
i386 buildonly-randconfig-002-20260412 gcc-14
i386 buildonly-randconfig-003-20260412 gcc-14
i386 buildonly-randconfig-004-20260412 gcc-14
i386 buildonly-randconfig-005-20260412 gcc-14
i386 buildonly-randconfig-006-20260412 gcc-14
i386 defconfig clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260412 clang-20
i386 randconfig-002-20260412 clang-20
i386 randconfig-003-20260412 clang-20
i386 randconfig-004-20260412 clang-20
i386 randconfig-005-20260412 clang-20
i386 randconfig-005-20260412 gcc-14
i386 randconfig-006-20260412 clang-20
i386 randconfig-007-20260412 clang-20
i386 randconfig-011-20260412 gcc-14
i386 randconfig-012-20260412 clang-20
i386 randconfig-012-20260412 gcc-14
i386 randconfig-013-20260412 clang-20
i386 randconfig-013-20260412 gcc-14
i386 randconfig-014-20260412 clang-20
i386 randconfig-014-20260412 gcc-14
i386 randconfig-015-20260412 clang-20
i386 randconfig-015-20260412 gcc-14
i386 randconfig-016-20260412 clang-20
i386 randconfig-016-20260412 gcc-14
i386 randconfig-017-20260412 clang-20
i386 randconfig-017-20260412 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260412 clang-23
loongarch randconfig-002-20260412 clang-23
loongarch randconfig-002-20260412 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips db1xxx_defconfig clang-23
mips loongson3_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260412 clang-23
nios2 randconfig-001-20260412 gcc-11.5.0
nios2 randconfig-002-20260412 clang-23
nios2 randconfig-002-20260412 gcc-8.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260412 gcc-15.2.0
parisc randconfig-002-20260412 gcc-15.2.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260412 gcc-15.2.0
powerpc randconfig-002-20260412 gcc-15.2.0
powerpc64 randconfig-001-20260412 gcc-15.2.0
powerpc64 randconfig-002-20260412 gcc-15.2.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig clang-23
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260412 clang-23
riscv randconfig-001-20260412 gcc-13.4.0
riscv randconfig-001-20260412 gcc-15.2.0
riscv randconfig-002-20260412 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig clang-23
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260412 clang-23
s390 randconfig-001-20260412 gcc-15.2.0
s390 randconfig-002-20260412 clang-23
s390 randconfig-002-20260412 gcc-15.2.0
s390 randconfig-002-20260412 gcc-8.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh defconfig gcc-15.2.0
sh randconfig-001-20260412 clang-23
sh randconfig-001-20260412 gcc-12.5.0
sh randconfig-001-20260412 gcc-15.2.0
sh randconfig-002-20260412 clang-23
sh randconfig-002-20260412 gcc-13.4.0
sh randconfig-002-20260412 gcc-15.2.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260412 clang-23
sparc randconfig-001-20260412 gcc-8.5.0
sparc randconfig-002-20260412 clang-23
sparc randconfig-002-20260412 gcc-11.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260412 clang-23
sparc64 randconfig-001-20260412 gcc-15.2.0
sparc64 randconfig-002-20260412 clang-23
sparc64 randconfig-002-20260412 gcc-12.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig clang-23
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260412 clang-23
um randconfig-001-20260412 gcc-14
um randconfig-002-20260412 clang-23
um x86_64_defconfig clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260412 clang-20
x86_64 buildonly-randconfig-001-20260412 gcc-12
x86_64 buildonly-randconfig-002-20260412 clang-20
x86_64 buildonly-randconfig-002-20260412 gcc-14
x86_64 buildonly-randconfig-003-20260412 clang-20
x86_64 buildonly-randconfig-003-20260412 gcc-12
x86_64 buildonly-randconfig-004-20260412 clang-20
x86_64 buildonly-randconfig-004-20260412 gcc-14
x86_64 buildonly-randconfig-005-20260412 clang-20
x86_64 buildonly-randconfig-005-20260412 gcc-14
x86_64 buildonly-randconfig-006-20260412 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260412 clang-20
x86_64 randconfig-001-20260412 gcc-14
x86_64 randconfig-002-20260412 clang-20
x86_64 randconfig-003-20260412 clang-20
x86_64 randconfig-004-20260412 clang-20
x86_64 randconfig-005-20260412 clang-20
x86_64 randconfig-005-20260412 gcc-14
x86_64 randconfig-006-20260412 clang-20
x86_64 randconfig-011-20260412 gcc-14
x86_64 randconfig-012-20260412 clang-20
x86_64 randconfig-012-20260412 gcc-14
x86_64 randconfig-013-20260412 clang-20
x86_64 randconfig-013-20260412 gcc-14
x86_64 randconfig-014-20260412 gcc-14
x86_64 randconfig-015-20260412 gcc-14
x86_64 randconfig-016-20260412 gcc-14
x86_64 randconfig-071-20260412 clang-20
x86_64 randconfig-072-20260412 clang-20
x86_64 randconfig-073-20260412 clang-20
x86_64 randconfig-074-20260412 clang-20
x86_64 randconfig-074-20260412 gcc-14
x86_64 randconfig-075-20260412 clang-20
x86_64 randconfig-076-20260412 clang-20
x86_64 randconfig-076-20260412 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260412 clang-23
xtensa randconfig-001-20260412 gcc-12.5.0
xtensa randconfig-002-20260412 clang-23
xtensa randconfig-002-20260412 gcc-13.4.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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