* [PATCH v2 2/2] i2c: imx-lpi2c: use dmaengine_prep_submit() to simple code
From: Frank.Li @ 2026-05-22 20:13 UTC (permalink / raw)
To: Vinod Koul, Dong Aisheng, Andi Shyti, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dmaengine, linux-kernel, linux-i2c, imx, linux-arm-kernel,
carlos.song, Frank Li
In-Reply-To: <20260522-dma_prep_submit-v2-0-7a87a5a29525@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use dmaengine_prep_submit() to simple code. No functional change.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 21 +++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 2a0962a0b4417..c90f72eec8498 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -720,7 +720,6 @@ static void lpi2c_dma_callback(void *data)
static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
{
- struct dma_async_tx_descriptor *rx_cmd_desc;
struct lpi2c_imx_dma *dma = lpi2c_imx->dma;
struct dma_chan *txchan = dma->chan_tx;
dma_cookie_t cookie;
@@ -733,15 +732,11 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return -EINVAL;
}
- rx_cmd_desc = dmaengine_prep_slave_single(txchan, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_MEM_TO_DEV,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (!rx_cmd_desc) {
- dev_err(&lpi2c_imx->adapter.dev, "DMA prep slave sg failed, use pio\n");
- goto desc_prepare_err_exit;
- }
-
- cookie = dmaengine_submit(rx_cmd_desc);
+ cookie = dmaengine_prep_submit_slave_single(txchan, NULL, NULL,
+ dma->dma_tx_addr,
+ dma->rx_cmd_buf_len,
+ DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (dma_submit_error(cookie)) {
dev_err(&lpi2c_imx->adapter.dev, "submitting DMA failed, use pio\n");
goto submit_err_exit;
@@ -751,15 +746,9 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return 0;
-desc_prepare_err_exit:
- dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- return -EINVAL;
-
submit_err_exit:
dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- dmaengine_desc_free(rx_cmd_desc);
return -EINVAL;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] dmaengine: add helper macro dmaengine_prep_submit()
From: Frank.Li @ 2026-05-22 20:13 UTC (permalink / raw)
To: Vinod Koul, Dong Aisheng, Andi Shyti, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dmaengine, linux-kernel, linux-i2c, imx, linux-arm-kernel,
carlos.song, Frank Li
Add helper macro dmaengine_prep_submit() to combine prep and submit to
one call.
Pervious try to use cleanup
https://lore.kernel.org/dmaengine/20251002-dma_chan_free-v1-0-4dbf116c2b19@nxp.com/
It is not simple enough and easy missing retain_and_null_ptr() at success
path.
struct dma_async_tx_descriptor *rx_cmd_desc __free(dma_async_tx_descriptor) = NULL;
...
cookie = dmaengine_submit(rx_cmd_desc);
if (dma_submit_error(cookie))
return dma_submit_error(cookie);
...
retain_and_null_ptr(rx_cmd_desc);
}
So create help macro to combine prep and submit by one call.
patch 2.
static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
{
- struct dma_async_tx_descriptor *rx_cmd_desc;
struct lpi2c_imx_dma *dma = lpi2c_imx->dma;
struct dma_chan *txchan = dma->chan_tx;
dma_cookie_t cookie;
@@ -761,15 +760,10 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return -EINVAL;
}
- rx_cmd_desc = dmaengine_prep_slave_single(txchan, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_MEM_TO_DEV,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (!rx_cmd_desc) {
- dev_err(&lpi2c_imx->adapter.dev, "DMA prep slave sg failed, use pio\n");
- goto desc_prepare_err_exit;
- }
-
- cookie = dmaengine_submit(rx_cmd_desc);
+ cookie = dmaengine_prep_submit(txchan, NULL, NULL, slave_single,
+ dma->dma_tx_addr,
+ dma->rx_cmd_buf_len, DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (dma_submit_error(cookie)) {
dev_err(&lpi2c_imx->adapter.dev, "submitting DMA failed, use pio\n");
goto submit_err_exit;
@@ -779,15 +773,9 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return 0;
-desc_prepare_err_exit:
- dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- return -EINVAL;
-
submit_err_exit:
dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- dmaengine_desc_free(rx_cmd_desc);
return -EINVAL;
}
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v2:
- use API dmaengine_prep_submit_slave_single()
- Link to v1: https://lore.kernel.org/r/20260130-dma_prep_submit-v1-0-2198f9e848fa@nxp.com
---
Frank Li (2):
dmaengine: Add helper dmaengine_prep_submit_slave_single()
i2c: imx-lpi2c: use dmaengine_prep_submit() to simple code
drivers/dma/dmaengine.c | 28 ++++++++++++++++++++++++++++
drivers/i2c/busses/i2c-imx-lpi2c.c | 21 +++++----------------
include/linux/dmaengine.h | 17 +++++++++++++++++
3 files changed, 50 insertions(+), 16 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20260130-dma_prep_submit-cbeac742de48
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Stefan Dösinger @ 2026-05-22 19:31 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap
Cc: Linus Walleij, Krzysztof Kozlowski, linux-arm-kernel,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <503916c8-da3b-42dd-812e-356f519be47f@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
Hi Randy,
Am Freitag, 22. Mai 2026, 20:44:24 Ostafrikanische Zeit schrieben Sie:
> Does this mean that you will be merging this patch since you merged the
> original patch?
I am new to the kernel development process, so I don't know what's the
preferred way. I guess for me it is easier if your patch gets merged as-is.
I can certainly submit a pull request myself though since I made myself the
maintainer for this thing. Does that go to linux-doc@vger.kernel.org or the
soc list?
Cheers,
Stefan
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v8 01/10] dt-bindings: net: airoha: Add GDM port ethernet child node
From: Lorenzo Bianconi @ 2026-05-22 19:27 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260519-airoha-eth-multi-serdes-v8-1-6bd70e329df6@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]
> EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
> or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner.
> As a result multiple net_devices can connect to the same GDM{3,4} port
> and there is a theoretical "1:n" relation between GDM ports and
> net_devices.
> Introduce the ethernet node child of a specific GDM port in order to model
> a given net_device that is connected via the external arbiter to the
> GDM{3,4} port. This new ethernet node is defined by the "airoha,eth-port"
> compatible string. Please note GDM1 and GDM2 does not support the
> connection with the external arbiter and they are represented by an
> ethernet node defined by the "airoha,eth-mac" compatible string.
Hi Rob, Krzysztof and Conor,
do you have any comment about this patch? Thanks in advance.
Regards,
Lorenzo
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../devicetree/bindings/net/airoha,en7581-eth.yaml | 56 +++++++++++++++++++++-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> index fbe2ddcdd909..17fe2edf4886 100644
> --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> @@ -130,6 +130,42 @@ patternProperties:
> maximum: 4
> description: GMAC port identifier
>
> + allOf:
> + - if:
> + properties:
> + reg:
> + contains:
> + items:
> + - enum:
> + - 3
> + - 4
> + then:
> + properties:
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^ethernet@[0-5]$":
> + type: object
> + unevaluatedProperties: false
> + $ref: ethernet-controller.yaml#
> + description: External ethernet port ID available on the GDM port
> +
> + properties:
> + compatible:
> + const: airoha,eth-port
> +
> + reg:
> + maximum: 5
> + description: External ethernet port identifier
> +
> + required:
> + - reg
> + - compatible
> +
> required:
> - reg
> - compatible
> @@ -191,9 +227,27 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> - mac: ethernet@1 {
> + ethernet@1 {
> compatible = "airoha,eth-mac";
> reg = <1>;
> };
> +
> + ethernet@4 {
> + compatible = "airoha,eth-mac";
> + reg = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet@0 {
> + compatible = "airoha,eth-port";
> + reg = <0>;
> + };
> +
> + ethernet@1 {
> + compatible = "airoha,eth-port";
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: clocksource/drivers/owl: fix refcount leak
From: Markus Elfring @ 2026-05-22 19:25 UTC (permalink / raw)
To: Alexander A. Klimov, linux-actions, linux-arm-kernel,
Andreas Färber, Daniel Lezcano, Manivannan Sadhasivam,
Thomas Gleixner
Cc: LKML, kernel-janitors
In-Reply-To: <fe494c36-04e9-4714-ab49-5f05bed66c9e@al2klimov.de>
>> How will chances evolve to adjust variable scopes accordingly?
>
> Is this even a thing in Linux?
> I mean specifying C variables anywhere ex. at function begin.
Development views are evolving also together with the application of scope-based
resource management, aren't they?
https://elixir.bootlin.com/linux/v7.1-rc4/source/include/linux/cleanup.h#L136-L153
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 3/3] ASoC: sunxi: sun4i-spdif: Reorder clock enable sequence
From: Chen-Yu Tsai @ 2026-05-22 19:20 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai
In-Reply-To: <20260522095401.72915-4-phucduc.bui@gmail.com>
On Fri, May 22, 2026 at 12:54 PM <phucduc.bui@gmail.com> wrote:
>
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Enable the APB bus clock before the SPDIF module clock
> during runtime resume, as register accesses depend on the
> bus clock being enabled first.
That does not even matter here. Access will only happen once the runtime
PM callbacks return.
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> sound/soc/sunxi/sun4i-spdif.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> index f54eb14c9ed8..102db1a2afbb 100644
> --- a/sound/soc/sunxi/sun4i-spdif.c
> +++ b/sound/soc/sunxi/sun4i-spdif.c
> @@ -643,15 +643,15 @@ static int sun4i_spdif_runtime_suspend(struct device *dev)
>
> static int sun4i_spdif_runtime_resume(struct device *dev)
> {
> - struct sun4i_spdif_dev *host = dev_get_drvdata(dev);
> + struct sun4i_spdif_dev *host = dev_get_drvdata(dev);
> int ret;
>
> - ret = clk_prepare_enable(host->spdif_clk);
> + ret = clk_prepare_enable(host->apb_clk);
> if (ret)
> return ret;
> - ret = clk_prepare_enable(host->apb_clk);
> + ret = clk_prepare_enable(host->spdif_clk);
> if (ret)
> - clk_disable_unprepare(host->spdif_clk);
> + clk_disable_unprepare(host->apb_clk);
>
> return ret;
> }
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v5 0/2] mm: improve large folio readahead for exec memory
From: Andrew Morton @ 2026-05-22 19:20 UTC (permalink / raw)
To: Usama Arif
Cc: david, willy, ryan.roberts, linux-mm, r, jack, Andrew Donnellan,
apopple, baohua, baolin.wang, brauner, catalin.marinas, dev.jain,
kees, kevin.brodsky, lance.yang, Liam R.Howlett, linux-arm-kernel,
linux-fsdevel, linux-kernel, ljs, mhocko, npache, pasha.tatashin,
rmclure, rppt, surenb, vbabka, Al Viro, wilts.infradead.org,
"linux-fsdevel, ziy, hannes, kas, shakeel.butt, kernel-team
In-Reply-To: <20260522162422.3856502-1-usama.arif@linux.dev>
On Fri, 22 May 2026 09:23:46 -0700 Usama Arif <usama.arif@linux.dev> wrote:
> Two checks in do_sync_mmap_readahead() limit large-folio readahead:
>
> 1. The mmap_miss heuristic is meant to throttle wasteful speculative
> readahead. It is currently also applied to the VM_EXEC readahead
> path, which is targeted rather than speculative. Once mmap_miss exceeds
> MMAP_LOTSAMISS, exec readahead - including the large-folio
> order requested by exec_folio_order() - is disabled. On
> configurations where the mmap_miss decrement paths are not
> active (see patch 1) the counter only grows, so exec readahead
> is permanently disabled after the first 100 faults.
>
> 2. The force_thp_readahead path is gated only on
> HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER and always drives the
> readahead at HPAGE_PMD_ORDER. Configurations where
> HPAGE_PMD_ORDER exceeds MAX_PAGECACHE_ORDER never reach this
> path, even when the mapping itself supports usefully large
> folios well below the cap.
>
> Both issues are most visible on arm64 with a 64K base page size,
> where HPAGE_PMD_ORDER is 13 (512MB) -- above MAX_PAGECACHE_ORDER
> (11) -- and where fault_around_pages collapses to 1 disabling
> should_fault_around() (one of the two mmap_miss decrement sites).
> However the fixes are architecture-agnostic: patch 1 reflects the
> nature of VM_EXEC readahead regardless of base page size, and
> patch 2 generalises the gate so any mapping advertising a usefully
> large maximum folio order can benefit.
>
> I created a benchmark that mmaps a large executable file and calls
> RET-stub functions at PAGE_SIZE offsets across it. "Cold" measures
> fault + readahead cost. "Random" first faults in all pages with a
> sequential sweep (not measured), then measures time for calling random
> offsets, isolating iTLB miss cost for scattered execution.
>
> The benchmark results on Neoverse V2 (Grace), arm64 with 64K base pages,
> 512MB executable file on ext4, averaged over 3 runs:
>
> Phase | Baseline | Patched | Improvement
> -----------|--------------|--------------|------------------
> Cold fault | 83.4 ms | 41.3 ms | 50% faster
> Random | 76.0 ms | 58.3 ms | 23% faster
Well that's nice.
AI review might have found a few things:
https://sashiko.dev/#/patchset/20260522162422.3856502-1-usama.arif@linux.dev
^ permalink raw reply
* Re: [PATCH v2 2/3] ASoC: sunxi: sun4i-spdif: Resume device before kcontrol register access
From: Chen-Yu Tsai @ 2026-05-22 19:19 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai
In-Reply-To: <20260522095401.72915-3-phucduc.bui@gmail.com>
On Fri, May 22, 2026 at 12:54 PM <phucduc.bui@gmail.com> wrote:
>
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Accessing registers while the device is runtime-suspended
> may lead to invalid hardware accesses on systems where the
> APB bus clock is gated during runtime suspend.
Did you actually reproduce the issue, or did you add the patch simply
because Sashiko mentioned it?
On sunxi, either it will hang the system because the bus transaction
got ignored, or it won't as something else enabled the clock.
And when you do add patches due to Sashiko raising an issue, please
do mention it in the commit message.
> Ensure the device is resumed before accessing registers.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> sound/soc/sunxi/sun4i-spdif.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> index 89eccc83a130..f54eb14c9ed8 100644
> --- a/sound/soc/sunxi/sun4i-spdif.c
> +++ b/sound/soc/sunxi/sun4i-spdif.c
> @@ -428,6 +428,11 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
> struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
> u8 *status = ucontrol->value.iec958.status;
> unsigned int reg;
> + int ret;
> +
> + ret = pm_runtime_resume_and_get(cpu_dai->dev);
> + if (ret)
> + return ret;
>
> scoped_guard(spinlock_irqsave, &host->lock) {
> regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA0, ®);
> @@ -443,6 +448,8 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
> status[5] = (reg >> 8) & 0x3;
> }
>
> + pm_runtime_put(cpu_dai->dev);
> +
> return 0;
> }
>
> @@ -453,8 +460,13 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
> struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
> u8 *status = ucontrol->value.iec958.status;
> unsigned int reg;
> + int ret;
> bool chg0, chg1;
>
> + ret = pm_runtime_resume_and_get(cpu_dai->dev);
> + if (ret)
> + return ret;
> +
> scoped_guard(spinlock_irqsave, &host->lock) {
> reg = (u32)status[3] << 24;
> reg |= (u32)status[2] << 16;
> @@ -479,6 +491,8 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
> SUN4I_SPDIF_TXCFG_NONAUDIO, reg);
> }
>
> + pm_runtime_put(cpu_dai->dev);
> +
> return chg0 || chg1;
> }
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v15 12/28] drm/i915/dp: Add YCBCR444 handling for sink formats
From: Ville Syrjälä @ 2026-05-22 19:19 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone, kernel, amd-gfx,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
intel-gfx, intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260522-color-format-v15-12-21fb136c9df2@collabora.com>
On Fri, May 22, 2026 at 02:32:03PM +0200, Nicolas Frattaroli wrote:
> In anticipation of userspace being able to explicitly select supported
> sink formats, add handling of the YCBCR444 sink format. The AUTO path
> does not choose this format, but with explicit format selection added to
> the driver, it becomes a possibility.
>
> Check for both source and sink support of YCBCR444 in
> intel_dp_sink_format_valid.
>
> Acked-by: Daniel Stone <daniel@fooishbar.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1920d2f02666..143ed85224be 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1344,6 +1344,20 @@ intel_dp_mode_valid_downstream(struct intel_connector *connector,
> 8, sink_format, true);
> }
>
> +static bool
> +intel_dp_can_ycbcr444(struct intel_dp *intel_dp)
> +{
> + if (source_can_output(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR444) &&
> + !drm_dp_is_branch(intel_dp->dpcd))
> + return true;
> +
> + if (source_can_output(intel_dp, INTEL_OUTPUT_FORMAT_RGB) &&
> + dfp_can_convert_from_rgb(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR444))
IIRC my previous conclusion was that we don't want the dfp convert
stuff here, at least initially. So this should just are about
source_can_output().
> + return true;
> +
> + return false;
> +}
> +
> static enum drm_mode_status
> intel_dp_sink_format_valid(struct intel_connector *connector,
> const struct drm_display_mode *mode,
> @@ -1364,6 +1378,13 @@ intel_dp_sink_format_valid(struct intel_connector *connector,
>
> return MODE_OK;
Again, would prefer a cleanr 420->444->rgb order.
> case INTEL_OUTPUT_FORMAT_RGB:
> + return MODE_OK;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
> + return MODE_BAD;
> + if (!intel_dp_can_ycbcr444(intel_dp))
> + return MODE_BAD;
These two ifs are swapped when compared to the HDMI version for no
good reason that I can see.
And missing the has_hdmi_sink check here as well.
> +
> return MODE_OK;
> default:
> MISSING_CASE(sink_format);
>
> --
> 2.54.0
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH v15 11/28] drm/i915/hdmi: Add YCBCR444 handling for sink formats
From: Ville Syrjälä @ 2026-05-22 19:12 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone, kernel, amd-gfx,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
intel-gfx, intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260522-color-format-v15-11-21fb136c9df2@collabora.com>
On Fri, May 22, 2026 at 02:32:02PM +0200, Nicolas Frattaroli wrote:
> In anticipation of userspace being able to explicitly select supported
> sink formats, add handling of the YCBCR444 sink format. The AUTO path
> does not choose this format, but with explicit format selection added to
> the driver, it becomes a possibility.
>
> Check for YCBCR444 support on the sink in sink_bpc_possible, and on the
> source and sink in sink_format_valid.
>
> Acked-by: Daniel Stone <daniel@fooishbar.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 32 +++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 9076c2b176ec..97cb321e6568 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1966,6 +1966,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
>
> if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36;
> + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_36;
> else
> return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_36;
> case 10:
> @@ -1974,6 +1976,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
>
> if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_30;
> + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_30;
> else
> return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_30;
> case 8:
> @@ -2021,6 +2025,27 @@ intel_hdmi_mode_clock_valid(struct drm_connector *_connector, int clock,
> return status;
> }
>
> +/**
> + * intel_hdmi_can_ycbcr444 - Check whether connector can output YCbCr444
> + * @connector: pointer to &struct intel_connector to check
> + *
> + * Checks whether the hardware that backs @connector is capable of outputting
> + * YCbCr444 video over HDMI. Does not check whether currently connected sink is
> + * capable of receiving it.
> + *
> + * Returns: %true if source supports outputting YCbCr444, %false otherwise.
> + */
We don't need kernel docs for internal stuff.
> +static bool
> +intel_hdmi_can_ycbcr444(struct intel_connector *connector)
> +{
> + const struct intel_display *display = to_intel_display(connector);
> +
> + if (HAS_GMCH(display))
> + return true;
Exactly the wrong way around.
> +
> + return false;
> +}
> +
> static enum drm_mode_status
> intel_hdmi_sink_format_valid(struct intel_connector *connector,
> const struct drm_display_mode *mode,
> @@ -2038,6 +2063,13 @@ intel_hdmi_sink_format_valid(struct intel_connector *connector,
>
> return MODE_OK;
I would put the 444 stuff here between 420 and RGB. Then we logically go
from YCbCr420 -> YCbCr444 -> RGB when reading the code.
> case INTEL_OUTPUT_FORMAT_RGB:
> + return MODE_OK;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + if (!intel_hdmi_can_ycbcr444(connector))
> + return MODE_BAD;
We're missing the has_hdmi_sink check as well.
> + if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
> + return MODE_BAD;
> +
> return MODE_OK;
> default:
> MISSING_CASE(sink_format);
>
> --
> 2.54.0
--
Ville Syrjälä
Intel
^ permalink raw reply
* [PATCH v2] pwm: imx27: Fix variable truncation in .apply()
From: Ronaldo Nunez @ 2026-05-22 19:13 UTC (permalink / raw)
To: linux-pwm
Cc: Uwe Kleine-König, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, imx, linux-arm-kernel,
linux-kernel, Ronaldo Nunez
Fix a variable truncation when calculating period in microseconds as
part of the solution for the ERR051198 in .apply() callback.
Example scenario:
- Period of 3us (PWMPR = 196 and prescaler = 1)
- Expected value in tmp: 198000000000 (NSEC_PER_SEC * (196 + 2) * 1)
- Actual value is 431504384 (truncation to u32)
Signed-off-by: Ronaldo Nunez <rnunez@baylibre.com>
---
Changes in v2:
- Added example with actual PWMPR/prescaler values per Frank Li's feedback
- Dropped testing section
---
drivers/pwm/pwm-imx27.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 3d34cdc4a3a5..c8b801fcb525 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -200,7 +200,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)
{
- unsigned long period_cycles, duty_cycles, prescale, period_us, tmp;
+ unsigned long period_cycles, duty_cycles, prescale, period_us;
struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
unsigned long long c;
unsigned long long clkrate;
@@ -208,6 +208,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
int val;
int ret;
u32 cr;
+ u64 tmp;
clkrate = clk_get_rate(imx->clks[PWM_IMX27_PER].clk);
c = clkrate * state->period;
@@ -249,6 +250,11 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
val = readl(imx->mmio_base + MX3_PWMPR);
val = val >= MX3_PWMPR_MAX ? MX3_PWMPR_MAX : val;
cr = readl(imx->mmio_base + MX3_PWMCR);
+
+ /*
+ * tmp stores period in nanoseconds. Result fits in u64 since
+ * val <= 0xfffe and prescaler in [1, 0x1000].
+ */
tmp = NSEC_PER_SEC * (u64)(val + 2) * MX3_PWMCR_PRESCALER_GET(cr);
tmp = DIV_ROUND_UP_ULL(tmp, clkrate);
period_us = DIV_ROUND_UP_ULL(tmp, 1000);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 1/2] gpio: mxc: fix irq_high handling
From: Frank Li @ 2026-05-22 18:21 UTC (permalink / raw)
To: Alexander Stein
Cc: Linus Walleij, Bartosz Golaszewski, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-gpio, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522070118.800671-1-alexander.stein@ew.tq-group.com>
On Fri, May 22, 2026 at 09:01:15AM +0200, Alexander Stein wrote:
> If port->irq_high is -1 (fsl,imx21-gpio compatible) and gpio_idx is >= 16
> enable_irq_wake() is called with -1 which is wrong.
>
> Fixes: 5f6d1998adeb ("gpio: mxc: release the parent IRQ in runtime suspend")
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> I don't have hardware to test. I just noticed this by code review.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> drivers/gpio/gpio-mxc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> index 647b6f4861b74..12f11a6c96653 100644
> --- a/drivers/gpio/gpio-mxc.c
> +++ b/drivers/gpio/gpio-mxc.c
> @@ -469,7 +469,7 @@ static int mxc_gpio_probe(struct platform_device *pdev)
> * the handler is needed only once, but doing it for every port
> * is more robust and easier.
> */
> - port->irq_high = -1;
> + port->irq_high = 0;
> port->mx_irq_handler = mx2_gpio_irq_handler;
> } else
> port->mx_irq_handler = mx3_gpio_irq_handler;
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH] mmc: dw_mmc-rockchip: Add missing private data for very old controllers
From: Heiko Stuebner @ 2026-05-22 18:43 UTC (permalink / raw)
To: ulfh, shawn.lin, jh80.chung
Cc: heiko, linux-mmc, linux-arm-kernel, linux-rockchip, linux-kernel,
stable
The really old controllers (rk2928, rk3066, rk3188) do not support UHS
speeds at all, and thus never handled phase data.
For that reason it never had a parse_dt callback and no driver private
data at all.
Commit ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating
support") makes the private data sort of mandatory, because the init
function checks whether phases are configured internally or through the
clock controller.
This results in the old SoCs then experiencing NULL-pointer dereferences
when they try to access that private-data struct.
While we could have if (priv) conditionals in all places, it's way less
cluttery to just give the old types their private-data struct.
Fixes: ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support")
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/mmc/host/dw_mmc-rockchip.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index c6eece4ec3fd..75c82ff20f17 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -441,6 +441,22 @@ static int dw_mci_common_parse_dt(struct dw_mci *host)
return 0;
}
+static int dw_mci_rk2928_parse_dt(struct dw_mci *host)
+{
+ struct dw_mci_rockchip_priv_data *priv;
+ int err;
+
+ err = dw_mci_common_parse_dt(host);
+ if (err)
+ return err;
+
+ priv = host->priv;
+
+ priv->internal_phase = false;
+
+ return 0;
+}
+
static int dw_mci_rk3288_parse_dt(struct dw_mci *host)
{
struct dw_mci_rockchip_priv_data *priv;
@@ -514,6 +530,7 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
static const struct dw_mci_drv_data rk2928_drv_data = {
.init = dw_mci_rockchip_init,
+ .parse_dt = dw_mci_rk2928_parse_dt,
};
static const struct dw_mci_drv_data rk3288_drv_data = {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v1 3/4] arm64/vdso: Enable SFrame generation in vDSO
From: Dylan Hatch @ 2026-05-22 18:24 UTC (permalink / raw)
To: Jens Remus
Cc: Catalin Marinas, Will Deacon, Steven Rostedt, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Weinan Liu, linux-arm-kernel,
linux-kernel, Heiko Carstens, Ilya Leoshkevich
In-Reply-To: <48871045-9ec8-4e62-a2c5-809e3070d671@linux.ibm.com>
On Fri, May 22, 2026 at 1:51 AM Jens Remus <jremus@linux.ibm.com> wrote:
>
> Hello Dylan,
>
> thank you for the feedback!
>
> On 5/22/2026 3:31 AM, Dylan Hatch wrote:
> > On Fri, Apr 17, 2026 at 8:08 AM Jens Remus <jremus@linux.ibm.com> wrote:
> >>
> >> This replicates Josh's x86 patch "x86/vdso: Enable sframe generation
> >> in VDSO" [1] for arm64.
> >>
> >> Enable .sframe generation in the vDSO library so kernel and user space
> >> can unwind through it. Keep all function symbols in the vDSO .symtab
> >> for stack trace purposes. This enables perf to lookup these function
> >> symbols in addition to those already exported in vDSO .dynsym.
> >>
> >> Starting with binutils 2.46 both GNU assembler and GNU linker
> >> exclusively support generating and merging .sframe in SFrame V3 format.
> >> For vDSO, only if supported by the assembler, generate .sframe, collect
> >> it, mark it as KEEP, and generate a GNU_SFRAME program table entry.
> >> Otherwise explicitly discard any .sframe.
> >>
> >> [1]: x86/vdso: Enable sframe generation in VDSO,
> >> https://lore.kernel.org/all/20260211141357.271402-7-jremus@linux.ibm.com/
> >>
> >> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> >> ---
> >>
> >> Notes (jremus):
> >> @Dylan: Adding -Wa,--gsframe-3 to the VDSO CC_FLAGS_ADD_VDSO (and
> >> AS_FLAGS_ADD_VDSO) may clash with your patch [1] that adds likewise
> >> to the CC_FLAGS_REMOVE_VDSO. Any idea how to resolve?
> >>
> >> [1]: [PATCH v3 2/8] arm64, unwind: build kernel with sframe V3 info,
> >> https://lore.kernel.org/all/20260406185000.1378082-3-dylanbhatch@google.com/
> >
> > In a kernel tree with both your patch and my [1] patch merged, I
> > believe we'd want to hold two invariants true:
> >
> > 1. If HAVE_UNWIND_KERNEL_SFRAME=n, we must not build the kernel with .sframe.
> > 2. If AS_SFRAME3=y, we must build vDSO with .sframe.
> >
> > Since HAVE_UNWIND_KERNEL_SFRAME=y implies AS_SFRAME3=y, I wonder if we
> > should be able to drop CC_FLAGS_SFRAME from CC_FLAGS_REMOVE_VDSO and
> > move some definitions:
> >
> > diff --git a/Makefile b/Makefile
> > index 227fda16deb1..ef059bccb8c1 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1147,12 +1147,15 @@ endif
> > # Ensure compilers do not transform certain loops into calls to wcslen()
> > KBUILD_CFLAGS += -fno-builtin-wcslen
> >
> > +ifeq ($(CONFIG_AS_SFRAME3),y)
> > +CC_FLAGS_SFRAME := -Wa,--gsframe-3
> > +export CC_FLAGS_SFRAME
> > +endif
> > +
> > # build with sframe table
> > ifdef CONFIG_HAVE_UNWIND_KERNEL_SFRAME
> > -CC_FLAGS_SFRAME := -Wa,--gsframe-3
> > KBUILD_CFLAGS += $(CC_FLAGS_SFRAME)
> > KBUILD_AFLAGS += $(CC_FLAGS_SFRAME)
> > -export CC_FLAGS_SFRAME
> > endif
> >
> > # change __FILE__ to the relative path to the source directory
> > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > index e90427a8d0f6..f03cac27857c 100644
> > --- a/arch/arm64/kernel/vdso/Makefile
> > +++ b/arch/arm64/kernel/vdso/Makefile
> > @@ -15,10 +15,6 @@ obj-vdso := vgettimeofday.o note.o sigreturn.o
> > vgetrandom.o vgetrandom-chacha.o
> > targets := $(obj-vdso) vdso.so vdso.so.dbg
> > obj-vdso := $(addprefix $(obj)/, $(obj-vdso))
> >
> > -ifeq ($(CONFIG_AS_SFRAME3),y)
> > - SFRAME_CFLAGS := -Wa,--gsframe-3
> > -endif
> > -
> > btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti
> >
> > # -Bsymbolic has been added for consistency with arm, the compat vDSO and
> > @@ -42,12 +38,12 @@ ccflags-y += -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
> > CC_FLAGS_REMOVE_VDSO := $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) \
> > $(RANDSTRUCT_CFLAGS) $(KSTACK_ERASE_CFLAGS) \
> > $(GCC_PLUGINS_CFLAGS) \
> > - $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) $(CC_FLAGS_SFRAME) \
> > + $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) \
> > -Wmissing-prototypes -Wmissing-declarations
> >
> > -CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> > $(SFRAME_CFLAGS)
> > +CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> > $(CC_FLAGS_SFRAME)
> >
> > -AS_FLAGS_ADD_VDSO := $(SFRAME_CFLAGS)
> > +AS_FLAGS_ADD_VDSO := $(CC_FLAGS_SFRAME)
> >
> > CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_REMOVE_VDSO)
> > CFLAGS_REMOVE_vgetrandom.o = $(CC_FLAGS_REMOVE_VDSO)
> >
> >
> > If done this way I think we will add the -Wa,--gsframe-3 twice when
> > HAVE_UNWIND_KERNEL_SFRAME=y, but maybe that's not a problem? This
> > could probably be folded into either this patch or mine [1], depending
> > which is applied first. I'm happy to rebase my unwind-for-kernel
> > patches onto this series, or we can do the other way around if that
> > works better.
> >
> > What do you think?
>
> I like that approach. Go ahead.
Do you have an updated version you can send? I noticed some of these
patches don't apply cleanly on Steven's current sframe branch. If you
can't get to it before you leave then no worries, have a good vacation
:)
^ permalink raw reply
* Re: [PATCH] clocksource/drivers/owl: fix refcount leak
From: Alexander A. Klimov @ 2026-05-22 18:20 UTC (permalink / raw)
To: Markus Elfring, linux-actions, linux-arm-kernel,
Andreas Färber, Daniel Lezcano, Manivannan Sadhasivam,
Thomas Gleixner
Cc: LKML
In-Reply-To: <c1aba09f-0a74-485c-b787-59b215a3bd88@web.de>
On 5/21/26 14:10, Markus Elfring wrote:
>> Every value returned from of_clk_get() is supposed to be cleaned up
>> via clk_put() once not needed anymore.
>
> How do you think about to add a wording like “Thus add a missing function call.”?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.1-rc4#n94
>
> Would the application of another guard become helpful?
TIL (from you) there's DEFINE_FREE.
This seems pretty cool on its own.
I think I can apply it here, but I'd have to recompile.
This takes long.
Or we just fix this leak with the oneliner
I already compiled, booted and submitted.
I'll wait what maintainers decide...
>
> How will chances evolve to adjust variable scopes accordingly?
Is this even a thing in Linux?
I mean specifying C variables anywhere ex. at function begin.
^ permalink raw reply
* Re: [PATCH 2/2] gpio: mxc: use BIT() macro
From: Frank Li @ 2026-05-22 18:09 UTC (permalink / raw)
To: Alexander Stein
Cc: Linus Walleij, Bartosz Golaszewski, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-gpio, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522070118.800671-2-alexander.stein@ew.tq-group.com>
On Fri, May 22, 2026 at 09:01:16AM +0200, Alexander Stein wrote:
> Do not open-code the BIT() macro.
Nit: Replace the open-code with the BIT() macro.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> drivers/gpio/gpio-mxc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> index 12f11a6c96653..7e2690d92df6f 100644
> --- a/drivers/gpio/gpio-mxc.c
> +++ b/drivers/gpio/gpio-mxc.c
> @@ -330,13 +330,13 @@ static int gpio_set_wake_irq(struct irq_data *d, u32 enable)
> ret = enable_irq_wake(port->irq_high);
> else
> ret = enable_irq_wake(port->irq);
> - port->wakeup_pads |= (1 << gpio_idx);
> + port->wakeup_pads |= BIT(gpio_idx);
> } else {
> if (port->irq_high && (gpio_idx >= 16))
> ret = disable_irq_wake(port->irq_high);
> else
> ret = disable_irq_wake(port->irq);
> - port->wakeup_pads &= ~(1 << gpio_idx);
> + port->wakeup_pads &= ~BIT(gpio_idx);
> }
>
> return ret;
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v3 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Andrew Morton @ 2026-05-22 18:07 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6
In-Reply-To: <20260522053146.83209-1-jiangwenxiaomi@gmail.com>
On Fri, 22 May 2026 13:31:40 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
> This patchset accelerates ioremap, vmalloc, and vmap when the memory
> is physically fully or partially contiguous.
Thanks. AI review asked a few things and might have found an existing
32-bit bug in vmap():
https://sashiko.dev/#/patchset/20260522053146.83209-1-jiangwenxiaomi@gmail.com
^ permalink raw reply
* [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
From: Mark Brown @ 2026-05-22 18:00 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Catalin Marinas, Will Deacon
Cc: Mark Rutland, linux-arm-kernel, kvmarm, linux-kernel, Mark Brown
Since b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps") when guests
write to ZCR_EL2 we have clamped the value of ZCR_EL2.LEN to be at most
that configuring the maximum guest VL. This is not the behaviour the
architecture documents for ZCR_EL2.LEN, the expectation is that all bits
will be read as written. Further, writing values larger than the largest
available vector length is part of the documented procedure for enumerating
the supported vector lengths so we expect to see this happen in practice.
The reasoning for the current behaviour is not specifically articulated, my
best guess is that it is intended to ensure that the guest can not see an
effective VL greater than the maximum that has been configured. This can
instead be achieved by configuring ZCR_EL2 when loading guest state:
- When running at EL0 or EL1 configure ZCR_EL2.LEN to the minimum of the
guest ZCR_EL2.LEN and vcpu_sve_max_vq(vcpu)-1.
- When running at EL2 configure the maximum VL for the guest in
ZCR_EL2.LEN like we do for non-nested guests and load the guest
ZCR_EL2 into ZCR_EL1.
This will ensure that the guest sees both the ZCR_EL2.LEN value which it
wrote and the effective VL that resulting from the values it has configured
in ZCR_ELx.LEN.
Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
written are sanitised based on this.
Fixes: b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps")
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/kvm/hyp/include/hyp/switch.h | 8 ++++----
arch/arm64/kvm/sys_regs.c | 6 +-----
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index bf0eb5e43427..fd277cb70967 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -501,11 +501,11 @@ static inline void fpsimd_lazy_switch_to_guest(struct kvm_vcpu *vcpu)
return;
if (vcpu_has_sve(vcpu)) {
+ zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
+
/* A guest hypervisor may restrict the effective max VL. */
- if (is_nested_ctxt(vcpu))
- zcr_el2 = __vcpu_sys_reg(vcpu, ZCR_EL2);
- else
- zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
+ if (is_nested_ctxt(vcpu) && !is_hyp_ctxt(vcpu))
+ zcr_el2 = min(zcr_el2, __vcpu_sys_reg(vcpu, ZCR_EL2));
write_sysreg_el2(zcr_el2, SYS_ZCR);
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 148fc3400ea8..c4d3bbae2d14 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2862,8 +2862,6 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
- unsigned int vq;
-
if (guest_hyp_sve_traps_enabled(vcpu)) {
kvm_inject_nested_sve_trap(vcpu);
return false;
@@ -2874,9 +2872,7 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
return true;
}
- vq = SYS_FIELD_GET(ZCR_ELx, LEN, p->regval) + 1;
- vq = min(vq, vcpu_sve_max_vq(vcpu));
- __vcpu_assign_sys_reg(vcpu, ZCR_EL2, vq - 1);
+ __vcpu_assign_sys_reg(vcpu, ZCR_EL2, p->regval & ZCR_ELx_LEN);
return true;
}
---
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
change-id: 20260519-kvm-arm64-fix-zcr-len-nv-9e9e7bae012a
Best regards,
--
Mark Brown <broonie@kernel.org>
^ permalink raw reply related
* Re: [PATCH 1/5] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Frank Li @ 2026-05-22 18:00 UTC (permalink / raw)
To: Laurentiu Mihalcea
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Pengutronix Kernel Team, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-2-laurentiumihalcea111@gmail.com>
On Fri, May 22, 2026 at 04:18:45AM -0700, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>
> Document the optional "memory-region-names" property.
Need add reason why need memory-region-names.
Try to fix previous use undocument ABI method, which depend memory node
name. But now prefer use morden memory-region-names to fetch related
resource.
you can rephrase it.
Frank
>
> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> ---
> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index c18f71b64889..6679b10f9da5 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> @@ -62,6 +62,14 @@ properties:
> minItems: 1
> maxItems: 32
>
> + memory-region-names:
> + minItems: 1
> + maxItems: 32
> + items:
> + oneOf:
> + - const: rsc-table
> + - pattern: '^vdev[0-9](buffer|vring[0-9])$'
> +
> power-domains:
> minItems: 2
> maxItems: 8
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH 3/3] arm64: Sort registers in cpu-feature-registers.rst
From: Mark Brown @ 2026-05-22 17:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Shuah Khan
Cc: Peter Maydell, Joey Gouly, linux-arm-kernel, linux-doc,
linux-kernel, Mark Brown
In-Reply-To: <20260522-arm64-cpu-ftr-regs-v1-0-19775b40faf0@kernel.org>
In order to make it a bit easier to work with sort the list of registers in
cpu-feature-registers.rst lexically. There should be no content changes
resulting from this patch.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/arch/arm64/cpu-feature-registers.rst | 223 +++++++++++----------
1 file changed, 112 insertions(+), 111 deletions(-)
diff --git a/Documentation/arch/arm64/cpu-feature-registers.rst b/Documentation/arch/arm64/cpu-feature-registers.rst
index 02815db0c780..0ea294c56984 100644
--- a/Documentation/arch/arm64/cpu-feature-registers.rst
+++ b/Documentation/arch/arm64/cpu-feature-registers.rst
@@ -170,137 +170,161 @@ infrastructure:
+------------------------------+---------+---------+
- ID_AA64PFR0_EL1 - Processor Feature Register 0
+ ID_AA64ISAR1_EL1 - Instruction set attribute register 1
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | DIT | [51-48] | y |
+ | LS64 | [63-60] | y |
+------------------------------+---------+---------+
- | MPAM | [43-40] | n |
+ | I8MM | [55-52] | y |
+------------------------------+---------+---------+
- | SVE | [35-32] | y |
+ | DGH | [51-48] | y |
+------------------------------+---------+---------+
- | GIC | [27-24] | n |
+ | BF16 | [47-44] | y |
+------------------------------+---------+---------+
- | AdvSIMD | [23-20] | y |
+ | SB | [39-36] | y |
+------------------------------+---------+---------+
- | FP | [19-16] | y |
+ | FRINTTS | [35-32] | y |
+------------------------------+---------+---------+
- | EL3 | [15-12] | n |
+ | GPI | [31-28] | y |
+------------------------------+---------+---------+
- | EL2 | [11-8] | n |
+ | GPA | [27-24] | y |
+------------------------------+---------+---------+
- | EL1 | [7-4] | n |
+ | LRCPC | [23-20] | y |
+------------------------------+---------+---------+
- | EL0 | [3-0] | n |
+ | FCMA | [19-16] | y |
+ +------------------------------+---------+---------+
+ | JSCVT | [15-12] | y |
+ +------------------------------+---------+---------+
+ | API | [11-8] | y |
+ +------------------------------+---------+---------+
+ | APA | [7-4] | y |
+ +------------------------------+---------+---------+
+ | DPB | [3-0] | y |
+------------------------------+---------+---------+
-
- ID_AA64PFR1_EL1 - Processor Feature Register 1
+ ID_AA64ISAR2_EL1 - Instruction set attribute register 2
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | GCS | [47-44] | y |
+ | LUT | [59-56] | y |
+------------------------------+---------+---------+
- | SME | [27-24] | y |
+ | CSSC | [55-52] | y |
+------------------------------+---------+---------+
- | MTE | [11-8] | y |
+ | RPRFM | [51-48] | y |
+------------------------------+---------+---------+
- | SSBS | [7-4] | y |
+ | BC | [23-20] | y |
+------------------------------+---------+---------+
- | BT | [3-0] | y |
+ | MOPS | [19-16] | y |
+ +------------------------------+---------+---------+
+ | APA3 | [15-12] | y |
+ +------------------------------+---------+---------+
+ | GPA3 | [11-8] | y |
+ +------------------------------+---------+---------+
+ | RPRES | [7-4] | y |
+ +------------------------------+---------+---------+
+ | WFXT | [3-0] | y |
+------------------------------+---------+---------+
- ID_AA64PFR2_EL1 - Processor Feature Register 2
+ ID_AA64ISAR3_EL1 - Instruction set attribute register 3
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | FPMR | [35-32] | y |
+ | FPRCVT | [31-28] | y |
+------------------------------+---------+---------+
- | MTEFAR | [11-8] | y |
+ | LSFE | [19-16] | y |
+------------------------------+---------+---------+
- | MTESTOREONLY | [7-4] | y |
+ | FAMINMAX | [7-4] | y |
+------------------------------+---------+---------+
- MIDR_EL1 - Main ID Register
+ ID_AA64MMFR0_EL1 - Memory model feature register 0
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | Implementer | [31-24] | y |
- +------------------------------+---------+---------+
- | Variant | [23-20] | y |
+ | ECV | [63-60] | y |
+------------------------------+---------+---------+
- | Architecture | [19-16] | y |
+
+ ID_AA64MMFR1_EL1 - Memory model feature register 1
+
+------------------------------+---------+---------+
- | PartNum | [15-4] | y |
+ | Name | bits | visible |
+------------------------------+---------+---------+
- | Revision | [3-0] | y |
+ | AFP | [47-44] | y |
+------------------------------+---------+---------+
- NOTE: The 'visible' fields of MIDR_EL1 will contain the value
- as available on the CPU where it is fetched and is not a system
- wide safe value.
-
- ID_AA64ISAR1_EL1 - Instruction set attribute register 1
+ ID_AA64MMFR2_EL1 - Memory model feature register 2
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | LS64 | [63-60] | y |
+ | AT | [35-32] | y |
+------------------------------+---------+---------+
- | I8MM | [55-52] | y |
+
+ ID_AA64MMFR3_EL1 - Memory model feature register 3
+
+------------------------------+---------+---------+
- | DGH | [51-48] | y |
+ | Name | bits | visible |
+------------------------------+---------+---------+
- | BF16 | [47-44] | y |
+ | S1POE | [19-16] | y |
+------------------------------+---------+---------+
- | SB | [39-36] | y |
+
+ ID_AA64PFR0_EL1 - Processor Feature Register 0
+
+------------------------------+---------+---------+
- | FRINTTS | [35-32] | y |
+ | Name | bits | visible |
+------------------------------+---------+---------+
- | GPI | [31-28] | y |
+ | DIT | [51-48] | y |
+------------------------------+---------+---------+
- | GPA | [27-24] | y |
+ | MPAM | [43-40] | n |
+------------------------------+---------+---------+
- | LRCPC | [23-20] | y |
+ | SVE | [35-32] | y |
+------------------------------+---------+---------+
- | FCMA | [19-16] | y |
+ | GIC | [27-24] | n |
+------------------------------+---------+---------+
- | JSCVT | [15-12] | y |
+ | AdvSIMD | [23-20] | y |
+------------------------------+---------+---------+
- | API | [11-8] | y |
+ | FP | [19-16] | y |
+------------------------------+---------+---------+
- | APA | [7-4] | y |
+ | EL3 | [15-12] | n |
+------------------------------+---------+---------+
- | DPB | [3-0] | y |
+ | EL2 | [11-8] | n |
+ +------------------------------+---------+---------+
+ | EL1 | [7-4] | n |
+ +------------------------------+---------+---------+
+ | EL0 | [3-0] | n |
+------------------------------+---------+---------+
- ID_AA64MMFR0_EL1 - Memory model feature register 0
+
+ ID_AA64PFR1_EL1 - Processor Feature Register 1
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | ECV | [63-60] | y |
+ | GCS | [47-44] | y |
+------------------------------+---------+---------+
-
- ID_AA64MMFR2_EL1 - Memory model feature register 2
-
+ | SME | [27-24] | y |
+------------------------------+---------+---------+
- | Name | bits | visible |
+ | MTE | [11-8] | y |
+------------------------------+---------+---------+
- | AT | [35-32] | y |
+ | SSBS | [7-4] | y |
+ +------------------------------+---------+---------+
+ | BT | [3-0] | y |
+------------------------------+---------+---------+
- ID_AA64MMFR3_EL1 - Memory model feature register 3
+ ID_AA64PFR2_EL1 - Processor Feature Register 2
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | S1POE | [19-16] | y |
+ | FPMR | [35-32] | y |
+ +------------------------------+---------+---------+
+ | MTEFAR | [11-8] | y |
+ +------------------------------+---------+---------+
+ | MTESTOREONLY | [7-4] | y |
+------------------------------+---------+---------+
ID_AA6SMFR0_EL1 - SME feature ID register 0
@@ -387,50 +411,64 @@ infrastructure:
| SVEVer | [3-0] | y |
+------------------------------+---------+---------+
- ID_AA64MMFR1_EL1 - Memory model feature register 1
+ ID_ISAR5_EL1 - AArch32 Instruction Set Attribute Register 5
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | AFP | [47-44] | y |
+ | CRC32 | [19-16] | y |
+ +------------------------------+---------+---------+
+ | SHA2 | [15-12] | y |
+ +------------------------------+---------+---------+
+ | SHA1 | [11-8] | y |
+ +------------------------------+---------+---------+
+ | AES | [7-4] | y |
+------------------------------+---------+---------+
- ID_AA64ISAR2_EL1 - Instruction set attribute register 2
+ ID_ISAR6_EL1 - AArch32 Instruction Set Attribute Register 6
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | LUT | [59-56] | y |
- +------------------------------+---------+---------+
- | CSSC | [55-52] | y |
+ | I8MM | [27-24] | y |
+------------------------------+---------+---------+
- | RPRFM | [51-48] | y |
+ | BF16 | [23-20] | y |
+------------------------------+---------+---------+
- | BC | [23-20] | y |
+ | SB | [15-12] | y |
+------------------------------+---------+---------+
- | MOPS | [19-16] | y |
+ | FHM | [11-8] | y |
+------------------------------+---------+---------+
- | APA3 | [15-12] | y |
+ | DP | [7-4] | y |
+------------------------------+---------+---------+
- | GPA3 | [11-8] | y |
+
+ ID_PFR2_EL1 - AArch32 Processor Feature Register 2
+
+------------------------------+---------+---------+
- | RPRES | [7-4] | y |
+ | Name | bits | visible |
+------------------------------+---------+---------+
- | WFXT | [3-0] | y |
+ | SSBS | [7-4] | y |
+------------------------------+---------+---------+
- ID_AA64ISAR3_EL1 - Instruction set attribute register 3
+ MIDR_EL1 - Main ID Register
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
- | FPRCVT | [31-28] | y |
+ | Implementer | [31-24] | y |
+------------------------------+---------+---------+
- | LSFE | [19-16] | y |
+ | Variant | [23-20] | y |
+------------------------------+---------+---------+
- | FAMINMAX | [7-4] | y |
+ | Architecture | [19-16] | y |
+ +------------------------------+---------+---------+
+ | PartNum | [15-4] | y |
+ +------------------------------+---------+---------+
+ | Revision | [3-0] | y |
+------------------------------+---------+---------+
+ NOTE: The 'visible' fields of MIDR_EL1 will contain the value
+ as available on the CPU where it is fetched and is not a system
+ wide safe value.
+
MVFR0_EL1 - AArch32 Media and VFP Feature Register 0
+------------------------------+---------+---------+
@@ -457,43 +495,6 @@ infrastructure:
| SIMDLS | [11-8] | y |
+------------------------------+---------+---------+
- ID_ISAR5_EL1 - AArch32 Instruction Set Attribute Register 5
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | CRC32 | [19-16] | y |
- +------------------------------+---------+---------+
- | SHA2 | [15-12] | y |
- +------------------------------+---------+---------+
- | SHA1 | [11-8] | y |
- +------------------------------+---------+---------+
- | AES | [7-4] | y |
- +------------------------------+---------+---------+
-
- ID_ISAR6_EL1 - AArch32 Instruction Set Attribute Register 6
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | I8MM | [27-24] | y |
- +------------------------------+---------+---------+
- | BF16 | [23-20] | y |
- +------------------------------+---------+---------+
- | SB | [15-12] | y |
- +------------------------------+---------+---------+
- | FHM | [11-8] | y |
- +------------------------------+---------+---------+
- | DP | [7-4] | y |
- +------------------------------+---------+---------+
-
- ID_PFR2_EL1 - AArch32 Processor Feature Register 2
-
- +------------------------------+---------+---------+
- | Name | bits | visible |
- +------------------------------+---------+---------+
- | SSBS | [7-4] | y |
- +------------------------------+---------+---------+
Appendix I: Example
-------------------
--
2.47.3
^ permalink raw reply related
* [PATCH 2/3] arm64: Document missing bitfields in cpu-feature-registers.rst
From: Mark Brown @ 2026-05-22 17:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Shuah Khan
Cc: Peter Maydell, Joey Gouly, linux-arm-kernel, linux-doc,
linux-kernel, Mark Brown
In-Reply-To: <20260522-arm64-cpu-ftr-regs-v1-0-19775b40faf0@kernel.org>
We have been rather lax in updating the list of visible bitfields in the
ID registers in cpu-feature-registers.rst, it is currently missing several
of the registers and quite a few bitfields in existing registers. Bring it
into sync with current -next.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/arch/arm64/cpu-feature-registers.rst | 146 +++++++++++++++++++++
1 file changed, 146 insertions(+)
diff --git a/Documentation/arch/arm64/cpu-feature-registers.rst b/Documentation/arch/arm64/cpu-feature-registers.rst
index c6e5bc053c09..02815db0c780 100644
--- a/Documentation/arch/arm64/cpu-feature-registers.rst
+++ b/Documentation/arch/arm64/cpu-feature-registers.rst
@@ -113,6 +113,30 @@ infrastructure:
4. List of registers with visible features
-------------------------------------------
+ ID_AA6FPFR0_EL1 - Floating Point feature ID register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | F8CVT | [31] | y |
+ +------------------------------+---------+---------+
+ | F8FMA | [30] | y |
+ +------------------------------+---------+---------+
+ | F8DP4 | [29] | y |
+ +------------------------------+---------+---------+
+ | F8DP2 | [28] | y |
+ +------------------------------+---------+---------+
+ | F8MM8 | [27] | y |
+ +------------------------------+---------+---------+
+ | F8MM4 | [26] | y |
+ +------------------------------+---------+---------+
+ | F16MM2 | [15] | y |
+ +------------------------------+---------+---------+
+ | F8E4M3 | [1] | y |
+ +------------------------------+---------+---------+
+ | F8E5M2 | [0] | y |
+ +------------------------------+---------+---------+
+
ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0
+------------------------------+---------+---------+
@@ -178,6 +202,8 @@ infrastructure:
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
+ | GCS | [47-44] | y |
+ +------------------------------+---------+---------+
| SME | [27-24] | y |
+------------------------------+---------+---------+
| MTE | [11-8] | y |
@@ -187,6 +213,17 @@ infrastructure:
| BT | [3-0] | y |
+------------------------------+---------+---------+
+ ID_AA64PFR2_EL1 - Processor Feature Register 2
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | FPMR | [35-32] | y |
+ +------------------------------+---------+---------+
+ | MTEFAR | [11-8] | y |
+ +------------------------------+---------+---------+
+ | MTESTOREONLY | [7-4] | y |
+ +------------------------------+---------+---------+
MIDR_EL1 - Main ID Register
@@ -213,6 +250,8 @@ infrastructure:
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
+ | LS64 | [63-60] | y |
+ +------------------------------+---------+---------+
| I8MM | [55-52] | y |
+------------------------------+---------+---------+
| DGH | [51-48] | y |
@@ -256,6 +295,68 @@ infrastructure:
| AT | [35-32] | y |
+------------------------------+---------+---------+
+ ID_AA64MMFR3_EL1 - Memory model feature register 3
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | S1POE | [19-16] | y |
+ +------------------------------+---------+---------+
+
+ ID_AA6SMFR0_EL1 - SME feature ID register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | FA64 | [63] | y |
+ +------------------------------+---------+---------+
+ | LUT6 | [61] | y |
+ +------------------------------+---------+---------+
+ | LUTv2 | [60] | y |
+ +------------------------------+---------+---------+
+ | SMEver | [59-56] | y |
+ +------------------------------+---------+---------+
+ | I16I64 | [55-52] | y |
+ +------------------------------+---------+---------+
+ | F64F64 | [48] | y |
+ +------------------------------+---------+---------+
+ | I16I32 | [47-44] | y |
+ +------------------------------+---------+---------+
+ | B16B16 | [43] | y |
+ +------------------------------+---------+---------+
+ | F16F16 | [42] | y |
+ +------------------------------+---------+---------+
+ | F8F16 | [41] | y |
+ +------------------------------+---------+---------+
+ | F8F32 | [40] | y |
+ +------------------------------+---------+---------+
+ | I8I32 | [39-36] | y |
+ +------------------------------+---------+---------+
+ | F16F32 | [35] | y |
+ +------------------------------+---------+---------+
+ | B16F32 | [34] | y |
+ +------------------------------+---------+---------+
+ | BI32I32 | [33] | y |
+ +------------------------------+---------+---------+
+ | F32F32 | [32] | y |
+ +------------------------------+---------+---------+
+ | SF8FMA | [30] | y |
+ +------------------------------+---------+---------+
+ | SF8DP4 | [29] | y |
+ +------------------------------+---------+---------+
+ | SF8DP2 | [28] | y |
+ +------------------------------+---------+---------+
+ | SBitPerm | [25] | y |
+ +------------------------------+---------+---------+
+ | AES | [24] | y |
+ +------------------------------+---------+---------+
+ | SFEXPA | [23] | y |
+ +------------------------------+---------+---------+
+ | STMOP | [16] | y |
+ +------------------------------+---------+---------+
+ | SMOP4 | [0] | y |
+ +------------------------------+---------+---------+
+
ID_AA64ZFR0_EL1 - SVE feature ID register 0
+------------------------------+---------+---------+
@@ -265,6 +366,8 @@ infrastructure:
+------------------------------+---------+---------+
| F32MM | [55-52] | y |
+------------------------------+---------+---------+
+ | F16MM | [51-48] | y |
+ +------------------------------+---------+---------+
| I8MM | [47-44] | y |
+------------------------------+---------+---------+
| SM4 | [43-40] | y |
@@ -277,6 +380,8 @@ infrastructure:
+------------------------------+---------+---------+
| BitPerm | [19-16] | y |
+------------------------------+---------+---------+
+ | EltPerm | [15-12] | y |
+ +------------------------------+---------+---------+
| AES | [7-4] | y |
+------------------------------+---------+---------+
| SVEVer | [3-0] | y |
@@ -295,6 +400,8 @@ infrastructure:
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
+ | LUT | [59-56] | y |
+ +------------------------------+---------+---------+
| CSSC | [55-52] | y |
+------------------------------+---------+---------+
| RPRFM | [51-48] | y |
@@ -312,6 +419,18 @@ infrastructure:
| WFXT | [3-0] | y |
+------------------------------+---------+---------+
+ ID_AA64ISAR3_EL1 - Instruction set attribute register 3
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | FPRCVT | [31-28] | y |
+ +------------------------------+---------+---------+
+ | LSFE | [19-16] | y |
+ +------------------------------+---------+---------+
+ | FAMINMAX | [7-4] | y |
+ +------------------------------+---------+---------+
+
MVFR0_EL1 - AArch32 Media and VFP Feature Register 0
+------------------------------+---------+---------+
@@ -327,6 +446,10 @@ infrastructure:
+------------------------------+---------+---------+
| SIMDFMAC | [31-28] | y |
+------------------------------+---------+---------+
+ | FPHP | [27-24] | y |
+ +------------------------------+---------+---------+
+ | SIMDHP | [23-20] | y |
+ +------------------------------+---------+---------+
| SIMDSP | [19-16] | y |
+------------------------------+---------+---------+
| SIMDInt | [15-12] | y |
@@ -348,6 +471,29 @@ infrastructure:
| AES | [7-4] | y |
+------------------------------+---------+---------+
+ ID_ISAR6_EL1 - AArch32 Instruction Set Attribute Register 6
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | I8MM | [27-24] | y |
+ +------------------------------+---------+---------+
+ | BF16 | [23-20] | y |
+ +------------------------------+---------+---------+
+ | SB | [15-12] | y |
+ +------------------------------+---------+---------+
+ | FHM | [11-8] | y |
+ +------------------------------+---------+---------+
+ | DP | [7-4] | y |
+ +------------------------------+---------+---------+
+
+ ID_PFR2_EL1 - AArch32 Processor Feature Register 2
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | SSBS | [7-4] | y |
+ +------------------------------+---------+---------+
Appendix I: Example
-------------------
--
2.47.3
^ permalink raw reply related
* [PATCH 1/3] arm64: Don't number registers in cpu-feature-registers.rst
From: Mark Brown @ 2026-05-22 17:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Shuah Khan
Cc: Peter Maydell, Joey Gouly, linux-arm-kernel, linux-doc,
linux-kernel, Mark Brown
In-Reply-To: <20260522-arm64-cpu-ftr-regs-v1-0-19775b40faf0@kernel.org>
cpu-feature-regsters.rst documents the set of userspace visible ID
registers. At present the section for each register is numbered, this has
lead to the registers being documented in a haphazard order as new ones
have been added to the end of the list to avoid renumbering. Remove the
numbers so we can avoid this problem in future.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/arch/arm64/cpu-feature-registers.rst | 26 +++++++++++-----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/arch/arm64/cpu-feature-registers.rst b/Documentation/arch/arm64/cpu-feature-registers.rst
index add66afc7b03..c6e5bc053c09 100644
--- a/Documentation/arch/arm64/cpu-feature-registers.rst
+++ b/Documentation/arch/arm64/cpu-feature-registers.rst
@@ -113,7 +113,7 @@ infrastructure:
4. List of registers with visible features
-------------------------------------------
- 1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0
+ ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -146,7 +146,7 @@ infrastructure:
+------------------------------+---------+---------+
- 2) ID_AA64PFR0_EL1 - Processor Feature Register 0
+ ID_AA64PFR0_EL1 - Processor Feature Register 0
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -173,7 +173,7 @@ infrastructure:
+------------------------------+---------+---------+
- 3) ID_AA64PFR1_EL1 - Processor Feature Register 1
+ ID_AA64PFR1_EL1 - Processor Feature Register 1
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -188,7 +188,7 @@ infrastructure:
+------------------------------+---------+---------+
- 4) MIDR_EL1 - Main ID Register
+ MIDR_EL1 - Main ID Register
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -208,7 +208,7 @@ infrastructure:
as available on the CPU where it is fetched and is not a system
wide safe value.
- 5) ID_AA64ISAR1_EL1 - Instruction set attribute register 1
+ ID_AA64ISAR1_EL1 - Instruction set attribute register 1
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -240,7 +240,7 @@ infrastructure:
| DPB | [3-0] | y |
+------------------------------+---------+---------+
- 6) ID_AA64MMFR0_EL1 - Memory model feature register 0
+ ID_AA64MMFR0_EL1 - Memory model feature register 0
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -248,7 +248,7 @@ infrastructure:
| ECV | [63-60] | y |
+------------------------------+---------+---------+
- 7) ID_AA64MMFR2_EL1 - Memory model feature register 2
+ ID_AA64MMFR2_EL1 - Memory model feature register 2
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -256,7 +256,7 @@ infrastructure:
| AT | [35-32] | y |
+------------------------------+---------+---------+
- 8) ID_AA64ZFR0_EL1 - SVE feature ID register 0
+ ID_AA64ZFR0_EL1 - SVE feature ID register 0
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -282,7 +282,7 @@ infrastructure:
| SVEVer | [3-0] | y |
+------------------------------+---------+---------+
- 8) ID_AA64MMFR1_EL1 - Memory model feature register 1
+ ID_AA64MMFR1_EL1 - Memory model feature register 1
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -290,7 +290,7 @@ infrastructure:
| AFP | [47-44] | y |
+------------------------------+---------+---------+
- 9) ID_AA64ISAR2_EL1 - Instruction set attribute register 2
+ ID_AA64ISAR2_EL1 - Instruction set attribute register 2
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -312,7 +312,7 @@ infrastructure:
| WFXT | [3-0] | y |
+------------------------------+---------+---------+
- 10) MVFR0_EL1 - AArch32 Media and VFP Feature Register 0
+ MVFR0_EL1 - AArch32 Media and VFP Feature Register 0
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -320,7 +320,7 @@ infrastructure:
| FPDP | [11-8] | y |
+------------------------------+---------+---------+
- 11) MVFR1_EL1 - AArch32 Media and VFP Feature Register 1
+ MVFR1_EL1 - AArch32 Media and VFP Feature Register 1
+------------------------------+---------+---------+
| Name | bits | visible |
@@ -334,7 +334,7 @@ infrastructure:
| SIMDLS | [11-8] | y |
+------------------------------+---------+---------+
- 12) ID_ISAR5_EL1 - AArch32 Instruction Set Attribute Register 5
+ ID_ISAR5_EL1 - AArch32 Instruction Set Attribute Register 5
+------------------------------+---------+---------+
| Name | bits | visible |
--
2.47.3
^ permalink raw reply related
* [PATCH 0/3] arm64: Fixes and cleanups for cpu-feature-registers.rst
From: Mark Brown @ 2026-05-22 17:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Shuah Khan
Cc: Peter Maydell, Joey Gouly, linux-arm-kernel, linux-doc,
linux-kernel, Mark Brown
Peter Maydell noticed some missing updates to cpu-feature-registers.rst,
while looking at these a number of other other omissions and some
maintainability problems were observed. Several registers and many
bitfields have not been added.
Following discussion with Catalin we remove the numbering of the
registers in the first patch so that when we add the registers we can
add them in a roughly sorted order, then fix up the missing
documentation before sorting the existing entries in the file.
This whole area should have much better tooling, rather than having to
update multiple places and manually cross check several different places
including rarely used documentation we should be marking up the sysreg
descriptions and then either generating the data or validating against
manually updated copies. Manually updated copies seem like a good idea
for the ABI documentation since while it's more work that would force
review. I did start on some sketches, it seemed like it might make
sense to tackle along with using the MRS but the libraries for that
seem not to be progressing at any great rate, I'll dig the sketches out.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Mark Brown (3):
arm64: Don't number registers in cpu-feature-registers.rst
arm64: Document missing bitfields in cpu-feature-registers.rst
arm64: Sort registers in cpu-feature-registers.rst
Documentation/arch/arm64/cpu-feature-registers.rst | 281 ++++++++++++++++-----
1 file changed, 214 insertions(+), 67 deletions(-)
---
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
change-id: 20260521-arm64-cpu-ftr-regs-bceb2d34376f
Best regards,
--
Mark Brown <broonie@kernel.org>
^ permalink raw reply
* [PATCH] arm64: Document SVE constraints on new hwcaps
From: Mark Brown @ 2026-05-22 17:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-doc, linux-kernel, Mark Brown
Two of the SVE hwcaps added for the SVE features in the 2025 dpISA did
not explicitly call out their dependency on SVE in the ABI documentation.
Do so.
While we're here reorder the SVE and fature specific ID registers for
HWCAP3_SVE_LUT6 which did have the SVE dependency but listed it second
unlike the other SVE specific ID registers.
Fixes: abca5e69ab626 ("arm64/cpufeature: Define hwcaps for 2025 dpISA features")
Reported-by: Will Deacon <will@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/arch/arm64/elf_hwcaps.rst | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/arch/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst
index 07ff9ea1d605..f60ca5612daa 100644
--- a/Documentation/arch/arm64/elf_hwcaps.rst
+++ b/Documentation/arch/arm64/elf_hwcaps.rst
@@ -452,10 +452,12 @@ HWCAP3_LS64
memory location, otherwise fallback to the non-atomic alternatives.
HWCAP3_SVE_B16MM
- Functionality implied by ID_AA64ZFR0_EL1.B16B16 == 0b0011
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.B16B16 == 0b0011
HWCAP3_SVE2P3
- Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0100
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.SVEver == 0b0100
HWCAP3_SME_LUT6
Functionality implied by ID_AA64SMFR0_EL1.LUT6 == 0b1
@@ -473,8 +475,9 @@ HWCAP3_F16F32MM
Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0011
HWCAP3_SVE_LUT6
- Functionality implied by ID_AA64ISAR2_EL1.LUT == 0b0010 and
- ID_AA64PFR0_EL1.SVE == 0b0001.
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ISAR2_EL1.LUT == 0b0010.
+
4. Unused AT_HWCAP bits
-----------------------
---
base-commit: abca5e69ab6268cbe1913b19da5a98c3383f8bb3
change-id: 20260522-arm64-elf-hwcaps-sve-cleanup-1af7874ad5b7
Best regards,
--
Mark Brown <broonie@kernel.org>
^ permalink raw reply related
* Re: [PATCH 1/2] drivers/acpi: Move RISC-V interrupt controllers autodep to ACPI IRQ code
From: Rafael J. Wysocki @ 2026-05-22 17:45 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260505-gic-v5-acpi-iwb-probe-deferral-v1-1-b37b85998362@kernel.org>
On Tue, May 5, 2026 at 10:48 AM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> RISC-V implements arch code to detect probe dependencies for devices and
> the interrupt controller the devices GSIs are routed to.
>
> The code itself is arch agnostic apart from an arch specific helper
> function required to retrieve the acpi_handle of the interrupt controller
> that manages the device GSI interrupt.
>
> In order to enable IRQ probe dependencies detection on other
> architectures, move RISC-V IRQ probe dependency detection code to
> generic ACPI IRQ code.
>
> RISC-V IRQ code detecting IRQ probe dependency has some limitations/latent
> bugs:
>
> - riscv_acpi_irq_get_dep() would force the loop in
> riscv_acpi_add_irq_dep() to stop at the first IRQ index that does not
> map to an interrupt controller handle (missing some possible
> dependencies)
> - riscv_acpi_add_prt_dep() does not validate acpi_get_handle() output
> - riscv_acpi_add_prt_dep() logic to handle memory allocation failure is
> forcing the loop to continue on the same PRT entry
>
> Fix the above limitations along with the code move.
I'd rather do the cleanup first, possibly in multiple steps, and then
move the code separately.
As it stands, it's quite hard to figure out what's going on and why.
> Allow interrupt controller drivers to register an arch specific
> function to determine the acpi_handle for a specific GSI number to use
> the mechanism if needed by the respective interrupt controller drivers.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Anup Patel <anup@brainfault.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> Cc: Marc Zyngier <maz@kernel.org>
> ---
> arch/riscv/include/asm/acpi.h | 1 +
> drivers/acpi/irq.c | 172 +++++++++++++++++++++++++++++++++++-
> drivers/acpi/riscv/irq.c | 141 +----------------------------
> drivers/irqchip/irq-gic-v3.c | 2 +-
> drivers/irqchip/irq-gic-v5.c | 2 +-
> drivers/irqchip/irq-gic.c | 2 +-
> drivers/irqchip/irq-loongarch-cpu.c | 2 +-
> drivers/irqchip/irq-riscv-intc.c | 3 +-
> include/linux/acpi.h | 5 +-
> 9 files changed, 181 insertions(+), 149 deletions(-)
>
> diff --git a/arch/riscv/include/asm/acpi.h b/arch/riscv/include/asm/acpi.h
> index 26ab37c171bc..f598520ac903 100644
> --- a/arch/riscv/include/asm/acpi.h
> +++ b/arch/riscv/include/asm/acpi.h
> @@ -67,6 +67,7 @@ int acpi_get_riscv_isa(struct acpi_table_header *table,
>
> void acpi_get_cbo_block_size(struct acpi_table_header *table, u32 *cbom_size,
> u32 *cboz_size, u32 *cbop_size);
> +acpi_handle acpi_get_riscv_gsi_handle(u32 gsi);
> #else
> static inline void acpi_init_rintc_map(void) { }
> static inline struct acpi_madt_rintc *acpi_cpu_get_madt_rintc(int cpu)
> diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
> index d1595156c86a..e4293458bf61 100644
> --- a/drivers/acpi/irq.c
> +++ b/drivers/acpi/irq.c
> @@ -13,6 +13,7 @@
> enum acpi_irq_model_id acpi_irq_model;
>
> static acpi_gsi_domain_disp_fn acpi_get_gsi_domain_id;
> +static acpi_gsi_handle_disp_fn acpi_get_gsi_handle;
> static u32 (*acpi_gsi_to_irq_fallback)(u32 gsi);
>
> /**
> @@ -321,15 +322,19 @@ const struct cpumask *acpi_irq_get_affinity(acpi_handle handle,
>
> /**
> * acpi_set_irq_model - Setup the GSI irqdomain information
> - * @model: the value assigned to acpi_irq_model
> - * @fn: a dispatcher function that will return the domain fwnode
> - * for a given GSI
> + * @model: the value assigned to acpi_irq_model
> + * @fn: a dispatcher function that will return the domain fwnode
> + * for a given GSI
> + * @gsi_dep_fn: a function to retrieve the acpi_handle a GSI interrupt is
> + * dependent on
> + *
> */
> void __init acpi_set_irq_model(enum acpi_irq_model_id model,
> - acpi_gsi_domain_disp_fn fn)
> + acpi_gsi_domain_disp_fn fn, acpi_gsi_handle_disp_fn gsi_dep_fn)
> {
> acpi_irq_model = model;
> acpi_get_gsi_domain_id = fn;
> + acpi_get_gsi_handle = gsi_dep_fn;
> }
>
> /*
> @@ -385,3 +390,162 @@ struct irq_domain *acpi_irq_create_hierarchy(unsigned int flags,
> host_data);
> }
> EXPORT_SYMBOL_GPL(acpi_irq_create_hierarchy);
> +
> +struct acpi_irq_dep_ctx {
> + int rc;
> + unsigned int index;
> + acpi_handle handle;
> +};
> +
> +static acpi_status acpi_irq_get_parent(struct acpi_resource *ares, void *context)
> +{
> + struct acpi_irq_dep_ctx *ctx = context;
> + struct acpi_resource_irq *irq;
> + struct acpi_resource_extended_irq *eirq;
> +
> + switch (ares->type) {
> + case ACPI_RESOURCE_TYPE_IRQ:
> + irq = &ares->data.irq;
> + if (ctx->index >= irq->interrupt_count) {
> + ctx->index -= irq->interrupt_count;
> + return AE_OK;
> + }
> + ctx->handle = acpi_get_gsi_handle(irq->interrupts[ctx->index]);
> + ctx->rc = 0;
> + return AE_CTRL_TERMINATE;
> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + eirq = &ares->data.extended_irq;
> + if (eirq->producer_consumer == ACPI_PRODUCER)
> + return AE_OK;
> +
> + if (ctx->index >= eirq->interrupt_count) {
> + ctx->index -= eirq->interrupt_count;
> + return AE_OK;
> + }
> +
> + /* Support GSIs only */
> + if (eirq->resource_source.string_length)
> + return AE_OK;
> +
> + ctx->handle = acpi_get_gsi_handle(eirq->interrupts[ctx->index]);
> + ctx->rc = 0;
> + return AE_CTRL_TERMINATE;
> + }
> +
> + return AE_OK;
> +}
> +
> +static int acpi_irq_get_dep(acpi_handle handle, unsigned int index, acpi_handle *gsi_handle)
> +{
> + struct acpi_irq_dep_ctx ctx = {-EINVAL, index, NULL};
> +
> + if (!gsi_handle)
> + return -EINVAL;
> +
> + acpi_walk_resources(handle, METHOD_NAME__CRS, acpi_irq_get_parent, &ctx);
> + *gsi_handle = ctx.handle;
> +
> + return ctx.rc;
> +}
> +
> +static bool acpi_prt_entry_valid(void *prt_entry)
> +{
> + struct acpi_pci_routing_table *entry = prt_entry;
> +
> + return entry && entry->length > 0;
> +}
> +
> +static void *acpi_prt_next_entry(void *prt_entry)
> +{
> + struct acpi_pci_routing_table *entry = prt_entry;
> +
> + return prt_entry + entry->length;
> +}
> +
> +static u32 acpi_add_prt_dep(acpi_handle handle)
> +{
> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> + struct acpi_pci_routing_table *entry;
> + struct acpi_handle_list dep_devices;
> + acpi_handle gsi_handle;
> + acpi_handle link_handle;
> + acpi_status status;
> + u32 count = 0;
> +
> + status = acpi_get_irq_routing_table(handle, &buffer);
> + if (ACPI_FAILURE(status)) {
> + acpi_handle_err(handle, "failed to get IRQ routing table\n");
> + kfree(buffer.pointer);
> + return 0;
> + }
> +
> + entry = buffer.pointer;
> + for (; acpi_prt_entry_valid(entry); entry = acpi_prt_next_entry(entry)) {
> + if (entry->source[0]) {
> + status = acpi_get_handle(handle, entry->source, &link_handle);
> + if (ACPI_FAILURE(status))
> + continue;
> + dep_devices.count = 1;
> + dep_devices.handles = kcalloc(1, sizeof(*dep_devices.handles), GFP_KERNEL);
> + if (!dep_devices.handles) {
> + acpi_handle_err(handle, "failed to allocate memory\n");
> + continue;
> + }
> +
> + dep_devices.handles[0] = link_handle;
> + count += acpi_scan_add_dep(handle, &dep_devices);
> + } else {
> + gsi_handle = acpi_get_gsi_handle(entry->source_index);
> + if (!gsi_handle)
> + continue;
> + dep_devices.count = 1;
> + dep_devices.handles = kcalloc(1, sizeof(*dep_devices.handles), GFP_KERNEL);
> + if (!dep_devices.handles) {
> + acpi_handle_err(handle, "failed to allocate memory\n");
> + continue;
> + }
> +
> + dep_devices.handles[0] = gsi_handle;
> + count += acpi_scan_add_dep(handle, &dep_devices);
> + }
> + }
> +
> + kfree(buffer.pointer);
> + return count;
> +}
> +
> +static u32 acpi_add_irq_dep(acpi_handle handle)
> +{
> + struct acpi_handle_list dep_devices;
> + acpi_handle gsi_handle;
> + u32 count = 0;
> + int i;
> +
> + for (i = 0; !acpi_irq_get_dep(handle, i, &gsi_handle); i++) {
> + if (!gsi_handle)
> + continue;
> +
> + dep_devices.count = 1;
> + dep_devices.handles = kcalloc(1, sizeof(*dep_devices.handles), GFP_KERNEL);
> + if (!dep_devices.handles) {
> + acpi_handle_err(handle, "failed to allocate memory\n");
> + continue;
> + }
> +
> + dep_devices.handles[0] = gsi_handle;
> + count += acpi_scan_add_dep(handle, &dep_devices);
> + }
> +
> + return count;
> +}
> +
> +u32 acpi_irq_add_auto_dep(acpi_handle handle)
> +{
> + if (!acpi_get_gsi_handle)
> + return 0;
> +
> + if (acpi_has_method(handle, "_PRT"))
> + return acpi_add_prt_dep(handle);
> +
> + return acpi_add_irq_dep(handle);
> +}
> diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
> index 9b88d0993e88..da2c42e0ebfd 100644
> --- a/drivers/acpi/riscv/irq.c
> +++ b/drivers/acpi/riscv/irq.c
> @@ -23,12 +23,6 @@ struct riscv_ext_intc_list {
> struct list_head list;
> };
>
> -struct acpi_irq_dep_ctx {
> - int rc;
> - unsigned int index;
> - acpi_handle handle;
> -};
> -
> LIST_HEAD(ext_intc_list);
>
> static int irqchip_cmp_func(const void *in0, const void *in1)
> @@ -254,7 +248,7 @@ void __init riscv_acpi_init_gsi_mapping(void)
> acpi_get_devices("RSCV0006", riscv_acpi_create_gsi_map_smsi, NULL, NULL);
> }
>
> -static acpi_handle riscv_acpi_get_gsi_handle(u32 gsi)
> +acpi_handle acpi_get_riscv_gsi_handle(u32 gsi)
> {
> struct riscv_ext_intc_list *ext_intc_element;
> struct list_head *i;
> @@ -269,138 +263,7 @@ static acpi_handle riscv_acpi_get_gsi_handle(u32 gsi)
> return NULL;
> }
>
> -static acpi_status riscv_acpi_irq_get_parent(struct acpi_resource *ares, void *context)
> -{
> - struct acpi_irq_dep_ctx *ctx = context;
> - struct acpi_resource_irq *irq;
> - struct acpi_resource_extended_irq *eirq;
> -
> - switch (ares->type) {
> - case ACPI_RESOURCE_TYPE_IRQ:
> - irq = &ares->data.irq;
> - if (ctx->index >= irq->interrupt_count) {
> - ctx->index -= irq->interrupt_count;
> - return AE_OK;
> - }
> - ctx->handle = riscv_acpi_get_gsi_handle(irq->interrupts[ctx->index]);
> - return AE_CTRL_TERMINATE;
> - case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> - eirq = &ares->data.extended_irq;
> - if (eirq->producer_consumer == ACPI_PRODUCER)
> - return AE_OK;
> -
> - if (ctx->index >= eirq->interrupt_count) {
> - ctx->index -= eirq->interrupt_count;
> - return AE_OK;
> - }
> -
> - /* Support GSIs only */
> - if (eirq->resource_source.string_length)
> - return AE_OK;
> -
> - ctx->handle = riscv_acpi_get_gsi_handle(eirq->interrupts[ctx->index]);
> - return AE_CTRL_TERMINATE;
> - }
> -
> - return AE_OK;
> -}
> -
> -static int riscv_acpi_irq_get_dep(acpi_handle handle, unsigned int index, acpi_handle *gsi_handle)
> -{
> - struct acpi_irq_dep_ctx ctx = {-EINVAL, index, NULL};
> -
> - if (!gsi_handle)
> - return 0;
> -
> - acpi_walk_resources(handle, METHOD_NAME__CRS, riscv_acpi_irq_get_parent, &ctx);
> - *gsi_handle = ctx.handle;
> - if (*gsi_handle)
> - return 1;
> -
> - return 0;
> -}
> -
> -static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> -{
> - struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> - struct acpi_pci_routing_table *entry;
> - struct acpi_handle_list dep_devices;
> - acpi_handle gsi_handle;
> - acpi_handle link_handle;
> - acpi_status status;
> - u32 count = 0;
> -
> - status = acpi_get_irq_routing_table(handle, &buffer);
> - if (ACPI_FAILURE(status)) {
> - acpi_handle_err(handle, "failed to get IRQ routing table\n");
> - kfree(buffer.pointer);
> - return 0;
> - }
> -
> - entry = buffer.pointer;
> - while (entry && (entry->length > 0)) {
> - if (entry->source[0]) {
> - acpi_get_handle(handle, entry->source, &link_handle);
> - dep_devices.count = 1;
> - dep_devices.handles = kzalloc_objs(*dep_devices.handles,
> - 1);
> - if (!dep_devices.handles) {
> - acpi_handle_err(handle, "failed to allocate memory\n");
> - continue;
> - }
> -
> - dep_devices.handles[0] = link_handle;
> - count += acpi_scan_add_dep(handle, &dep_devices);
> - } else {
> - gsi_handle = riscv_acpi_get_gsi_handle(entry->source_index);
> - dep_devices.count = 1;
> - dep_devices.handles = kzalloc_objs(*dep_devices.handles,
> - 1);
> - if (!dep_devices.handles) {
> - acpi_handle_err(handle, "failed to allocate memory\n");
> - continue;
> - }
> -
> - dep_devices.handles[0] = gsi_handle;
> - count += acpi_scan_add_dep(handle, &dep_devices);
> - }
> -
> - entry = (struct acpi_pci_routing_table *)
> - ((unsigned long)entry + entry->length);
> - }
> -
> - kfree(buffer.pointer);
> - return count;
> -}
> -
> -static u32 riscv_acpi_add_irq_dep(acpi_handle handle)
> -{
> - struct acpi_handle_list dep_devices;
> - acpi_handle gsi_handle;
> - u32 count = 0;
> - int i;
> -
> - for (i = 0;
> - riscv_acpi_irq_get_dep(handle, i, &gsi_handle);
> - i++) {
> - dep_devices.count = 1;
> - dep_devices.handles = kzalloc_objs(*dep_devices.handles, 1);
> - if (!dep_devices.handles) {
> - acpi_handle_err(handle, "failed to allocate memory\n");
> - continue;
> - }
> -
> - dep_devices.handles[0] = gsi_handle;
> - count += acpi_scan_add_dep(handle, &dep_devices);
> - }
> -
> - return count;
> -}
> -
> u32 arch_acpi_add_auto_dep(acpi_handle handle)
> {
> - if (acpi_has_method(handle, "_PRT"))
> - return riscv_acpi_add_prt_dep(handle);
> -
> - return riscv_acpi_add_irq_dep(handle);
> + return acpi_irq_add_auto_dep(handle);
> }
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 99444a1b2ffa..2673954d4577 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -2588,7 +2588,7 @@ gic_acpi_init(union acpi_subtable_headers *header, const unsigned long end)
> if (err)
> goto out_fwhandle_free;
>
> - acpi_set_irq_model(ACPI_IRQ_MODEL_GIC, gic_v3_get_gsi_domain_id);
> + acpi_set_irq_model(ACPI_IRQ_MODEL_GIC, gic_v3_get_gsi_domain_id, NULL);
>
> if (static_branch_likely(&supports_deactivate_key))
> gic_acpi_setup_kvm_info();
> diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
> index 6b0903be8ebf..03cc2830b260 100644
> --- a/drivers/irqchip/irq-gic-v5.c
> +++ b/drivers/irqchip/irq-gic-v5.c
> @@ -1242,7 +1242,7 @@ static int __init gic_acpi_init(union acpi_subtable_headers *header, const unsig
> if (ret)
> goto out_irs;
>
> - acpi_set_irq_model(ACPI_IRQ_MODEL_GIC_V5, gic_v5_get_gsi_domain_id);
> + acpi_set_irq_model(ACPI_IRQ_MODEL_GIC_V5, gic_v5_get_gsi_domain_id, NULL);
>
> return 0;
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index ec70c84e9f91..f6bc29f515fb 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -1690,7 +1690,7 @@ static int __init gic_v2_acpi_init(union acpi_subtable_headers *header,
> return ret;
> }
>
> - acpi_set_irq_model(ACPI_IRQ_MODEL_GIC, gic_v2_get_gsi_domain_id);
> + acpi_set_irq_model(ACPI_IRQ_MODEL_GIC, gic_v2_get_gsi_domain_id, NULL);
>
> if (IS_ENABLED(CONFIG_ARM_GIC_V2M))
> gicv2m_init(NULL, gic_data[0].domain);
> diff --git a/drivers/irqchip/irq-loongarch-cpu.c b/drivers/irqchip/irq-loongarch-cpu.c
> index 950bc087e388..84ce24889488 100644
> --- a/drivers/irqchip/irq-loongarch-cpu.c
> +++ b/drivers/irqchip/irq-loongarch-cpu.c
> @@ -168,7 +168,7 @@ static int __init cpuintc_acpi_init(union acpi_subtable_headers *header,
> panic("Failed to add irqdomain for LoongArch CPU");
>
> set_handle_irq(&handle_cpu_irq);
> - acpi_set_irq_model(ACPI_IRQ_MODEL_LPIC, lpic_get_gsi_domain_id);
> + acpi_set_irq_model(ACPI_IRQ_MODEL_LPIC, lpic_get_gsi_domain_id, NULL);
> acpi_set_gsi_to_irq_fallback(lpic_gsi_to_irq);
> ret = acpi_cascade_irqdomain_init();
>
> diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
> index 84418dbd5a27..0595144116e2 100644
> --- a/drivers/irqchip/irq-riscv-intc.c
> +++ b/drivers/irqchip/irq-riscv-intc.c
> @@ -384,7 +384,8 @@ static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header,
> if (rc)
> irq_domain_free_fwnode(fn);
> else
> - acpi_set_irq_model(ACPI_IRQ_MODEL_RINTC, riscv_acpi_get_gsi_domain_id);
> + acpi_set_irq_model(ACPI_IRQ_MODEL_RINTC, riscv_acpi_get_gsi_domain_id,
> + acpi_get_riscv_gsi_handle);
>
> return rc;
> }
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 67effb91fa98..468fc6a54651 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -360,9 +360,10 @@ int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
> int acpi_isa_irq_to_gsi (unsigned isa_irq, u32 *gsi);
>
> typedef struct fwnode_handle *(*acpi_gsi_domain_disp_fn)(u32);
> +typedef acpi_handle (*acpi_gsi_handle_disp_fn)(u32);
>
> void acpi_set_irq_model(enum acpi_irq_model_id model,
> - acpi_gsi_domain_disp_fn fn);
> + acpi_gsi_domain_disp_fn fn, acpi_gsi_handle_disp_fn gsi_dep_fn);
> acpi_gsi_domain_disp_fn acpi_get_gsi_dispatcher(void);
> void acpi_set_gsi_to_irq_fallback(u32 (*)(u32));
>
> @@ -372,6 +373,8 @@ struct irq_domain *acpi_irq_create_hierarchy(unsigned int flags,
> const struct irq_domain_ops *ops,
> void *host_data);
>
> +u32 acpi_irq_add_auto_dep(acpi_handle handle);
> +
> #ifdef CONFIG_X86_IO_APIC
> extern int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity);
> #else
>
> --
> 2.54.0
>
^ 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