* RE: [PATCH 3/3] perf/arm_cspmu: nvidia: fix BDF calculation examples in PCIE PMU docs
From: Besar Wicaksono @ 2026-05-11 21:48 UTC (permalink / raw)
To: Saurav Sachidanand, Will Deacon
Cc: Mark Rutland, Ilkka Koskinen, Jon Hunter,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
aghayev@amazon.com, juew@amazon.com
In-Reply-To: <20260511210905.91917-2-sauravsc@amazon.com>
> -----Original Message-----
> From: Saurav Sachidanand <sauravsc@amazon.com>
> Sent: Monday, May 11, 2026 4:09 PM
> To: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>; Besar Wicaksono
> <bwicaksono@nvidia.com>; Ilkka Koskinen
> <ilkka@os.amperecomputing.com>; Jon Hunter <jonathanh@nvidia.com>;
> linux-arm-kernel@lists.infradead.org; linux-perf-users@vger.kernel.org; linux-
> kernel@vger.kernel.org; aghayev@amazon.com; juew@amazon.com; Saurav
> Sachidanand <sauravsc@amazon.com>
> Subject: [PATCH 3/3] perf/arm_cspmu: nvidia: fix BDF calculation examples in
> PCIE PMU docs
>
> External email: Use caution opening links or attachments
>
>
> The BDF hex values in the documentation examples are inconsistent with
> the stated formula (bus << 8) + (device << 3) + (function):
>
> - BDF 27:01.1: documented as 0x2781, correct value is 0x2709
> (0x27 << 8) + (0x01 << 3) + 0x1 = 0x2709
> - BDF 01:01.0: documented as 0x0180, correct value is 0x0108
> (0x01 << 8) + (0x01 << 3) + 0x0 = 0x0108
>
> It appears (device << 7) was used instead of (device << 3) when
> computing the example values.
>
> Fixes: bf585ba14726 ("perf/arm_cspmu: nvidia: Add Tegra410 PCIE PMU")
> Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
Thanks for the fix.
Reviewed-by: Besar Wicaksono <bwicaksono@nvidia.com>
> ---
> Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> index 0656223b61d47..24f0e801d7b80 100644
> --- a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> +++ b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> @@ -170,7 +170,7 @@ The list of event filters:
> devices in root port 0 to 3.
> * src_bdf: the BDF that will be monitored. This is a 16-bit value that
> follows formula: (bus << 8) + (device << 3) + (function). For example, the
> - value of BDF 27:01.1 is 0x2781.
> + value of BDF 27:01.1 is 0x2709.
> * src_bdf_en: enable the BDF filter. If this is set, the BDF filter value in
> "src_bdf" is used to filter the traffic.
>
> @@ -215,7 +215,7 @@ Example usage:
> * Count event id 0x4 from BDF 01:01.0 of PCIE RC-4 on socket 0 targeting all
> destinations::
>
> - perf stat -a -e
> nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0180,src_bdf_en=0x1/
> + perf stat -a -e
> nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0108,src_bdf_en=0x1/
>
> .. _NVIDIA_T410_PCIE_PMU_RC_Mapping_Section:
>
> --
> 2.47.3
^ permalink raw reply
* RE: [PATCH 2/3] perf/arm_cspmu: nvidia: handle empty resource list in PCIE-TGT init
From: Besar Wicaksono @ 2026-05-11 22:09 UTC (permalink / raw)
To: Saurav Sachidanand, Will Deacon
Cc: Mark Rutland, Ilkka Koskinen, Jon Hunter,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
aghayev@amazon.com, juew@amazon.com
In-Reply-To: <20260511210905.91917-1-sauravsc@amazon.com>
> -----Original Message-----
> From: Saurav Sachidanand <sauravsc@amazon.com>
> Sent: Monday, May 11, 2026 4:09 PM
> To: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>; Besar Wicaksono
> <bwicaksono@nvidia.com>; Ilkka Koskinen
> <ilkka@os.amperecomputing.com>; Jon Hunter <jonathanh@nvidia.com>;
> linux-arm-kernel@lists.infradead.org; linux-perf-users@vger.kernel.org; linux-
> kernel@vger.kernel.org; aghayev@amazon.com; juew@amazon.com; Saurav
> Sachidanand <sauravsc@amazon.com>
> Subject: [PATCH 2/3] perf/arm_cspmu: nvidia: handle empty resource list in
> PCIE-TGT init
>
> External email: Use caution opening links or attachments
>
>
> When acpi_dev_get_memory_resources() returns success but the resource
> list is empty (rentry is NULL), addr_filter_reg remains NULL from
> devm_kzalloc. Since IS_ERR(NULL) is false, the function proceeds
> without error and later dereferences the NULL pointer in
> pcie_tgt_pmu_config_addr_filter().
>
> Set addr_filter_reg to ERR_PTR(-ENODEV) when the resource list is
> empty so the existing IS_ERR check catches it.
>
> Fixes: 3dd73022306b ("perf/arm_cspmu: nvidia: Add Tegra410 PCIE-TGT
> PMU")
> Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
> ---
> drivers/perf/arm_cspmu/nvidia_cspmu.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/perf/arm_cspmu/nvidia_cspmu.c
> b/drivers/perf/arm_cspmu/nvidia_cspmu.c
> index bac83e424d6dc..bae722e263e91 100644
> --- a/drivers/perf/arm_cspmu/nvidia_cspmu.c
> +++ b/drivers/perf/arm_cspmu/nvidia_cspmu.c
> @@ -555,14 +555,16 @@ static int pcie_tgt_init_data(struct arm_cspmu
> *cspmu)
>
> rentry = list_first_entry_or_null(
> &resource_list, struct resource_entry, node);
> - if (rentry) {
> + if (rentry)
> data->addr_filter_reg = devm_ioremap_resource(dev, rentry->res);
> - ret = 0;
> - }
> + else
> + data->addr_filter_reg = ERR_PTR(-ENODEV);
>
> if (IS_ERR(data->addr_filter_reg)) {
> dev_err(dev, "failed to get address filter resource\n");
> ret = PTR_ERR(data->addr_filter_reg);
> + } else {
Thanks for fixing.
Reviewed-by: Besar Wicaksono <bwicaksono@nvidia.com>
> + ret = 0;
> }
>
> acpi_dev_free_resource_list(&resource_list);
> --
> 2.47.3
^ permalink raw reply
* [PATCH 1/1] dt-bindings: display: imx: add deprecated property 'port' and 'display-timings'
From: Frank Li @ 2026-05-11 22:09 UTC (permalink / raw)
To: Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:DRM DRIVERS FOR FREESCALE IMX 5/6,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
Cc: imx
Add deprecated property 'port' and 'display-timings' for i.MX5 SoCs (over
15 years) to fix below CHECK_DTBS warnings:
arm/boot/dts/nxp/imx/imx51-apf51dev.dtb: disp1 (fsl,imx-parallel-display): 'display-timings', 'port' do not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/display/imx/fsl,imx-parallel-display.yaml
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
.../display/imx/fsl,imx-parallel-display.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
index bbcfe7e2958b7..b0c5869771fae 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
@@ -42,6 +42,17 @@ properties:
unevaluatedProperties: false
description: output port connected to a panel
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+ deprecated: true
+ description: input port connected to the IPU display interface, see port@0
+
+ display-timings:
+ $ref: /schemas/display/panel/display-timings.yaml#
+ unevaluatedProperties: false
+ deprecated: true
+
required:
- compatible
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0
From: Andrew Lunn @ 2026-05-11 22:15 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-1-01b855a5ce25@nxp.com>
On Mon, May 11, 2026 at 05:04:56PM -0400, Frank Li wrote:
> According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
> is connected to the station management entity via the mechanical interface
> defined in 22.6 shall always respond to transactions addressed to PHY
> Address zero <00000>.
Did you read 22.6? I've not seen a mechanical interface as defined in
22.6 for at least 20 years, maybe 30 years.
That cause does not apply in this context.
> - ethphy: ethernet-phy {
> + ethphy: ethernet-phy@0 {
> compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
This could very well break this board. Without a reg value, the core
will find the first PHY on the bus, at whatever address it is at. If
you hard code 0, the PHY must be at 0, otherwise it will not be found.
Andrew
^ permalink raw reply
* [PATCH] arm64: dts: allwinner: Cubie A5E: enable SPI flash
From: Andre Przywara @ 2026-05-11 22:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-arm-kernel, linux-sunxi
The Cubie A5E board comes with 16MiB of SPI NOR flash.
Enable the SPI0 DT node and describe the configuration.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../boot/dts/allwinner/sun55i-a527-cubie-a5e.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
index bfdf1728cd14b..7ad22fc85d1fd 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
+++ b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
@@ -344,6 +344,21 @@ &r_pio {
vcc-pm-supply = <®_aldo3>;
};
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pc_pins>, <&spi0_cs0_pc_pin>,
+ <&spi0_hold_pc_pin>, <&spi0_wp_pc_pin>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "winbond,w25q128", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.46.4
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] fbdev: ipu-v3: clean up kernel-doc warnings
From: Sasha Levin @ 2026-05-11 22:19 UTC (permalink / raw)
To: patches, stable
Cc: Randy Dunlap, Philipp Zabel, Helge Deller, Sasha Levin, shawnguo,
linux-fbdev, dri-devel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260511221931.2370053-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit f1fb23a0a0fcbdb66672da51d7d63a259f6396ca ]
Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values
Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
return value of 'ipu_image_convert'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `fbdev: ipu-v3`; action verb `clean up`;
intent is to correct kernel-doc warnings in `include/video/imx-ipu-
image-convert.h`.
Step 1.2 Record: tags in committed message are `Signed-off-by: Randy
Dunlap <rdunlap@infradead.org>`, `Reviewed-by: Philipp Zabel
<p.zabel@pengutronix.de>`, and `Signed-off-by: Helge Deller
<deller@gmx.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-
by:`, `Link:`, or `Cc: stable@vger.kernel.org` tag is present in the
committed message.
Step 1.3 Record: the described problem is seven kernel-doc warnings: one
undocumented/private list member, malformed typedef documentation, and
missing `Returns:` sections. The visible symptom is documentation
tooling warnings, not a runtime crash, hang, data corruption, or
security issue. No affected kernel version is stated. Root cause is
incorrect kernel-doc comment syntax.
Step 1.4 Record: this is not a hidden runtime bug fix. The body and diff
both show a documentation/comment-only cleanup.
## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `include/video/imx-ipu-image-
convert.h`, 11 insertions and 5 deletions. Modified documentation covers
`struct ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`. Scope is single-
file, header-only, surgical.
Step 2.2 Record: hunk behavior:
- `struct ipu_image_convert_run`: before, `list` was documented neither
as a member nor private; after, `/* private: */` tells kernel-doc to
ignore it as an API member.
- `ipu_image_convert_cb_t`: before, kernel-doc treated the typedef
comment as a function prototype mismatch; after, it is marked as a
typedef comment.
- Return docs: before, several returns were plain prose or missing;
after, they use kernel-doc `Returns:` syntax.
- `ipu_image_convert_prepare()`: before, the V4L2 usage note followed
the return prose; after, the return section is last and formatted for
kernel-doc.
Step 2.3 Record: bug category is documentation/kernel-doc warning
cleanup. No error-path, synchronization, refcount, memory-safety,
initialization, type, logic, or hardware workaround change exists.
Step 2.4 Record: fix quality is high for the stated documentation issue:
small, obviously correct kernel-doc syntax changes. Runtime regression
risk is effectively zero because no C declarations, types, function
bodies, data layout, or APIs are changed. Documentation rendering risk
is very low.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the affected header comments and
declarations came from `cd98e85a6b786d` by Steve Longerbeam, dated
2016-09-17. `git describe --contains cd98e85a6b786d` reports it as
present by `v4.9-rc1~41^2~24^2`.
Step 3.2 Record: no `Fixes:` tag is present, so there is no tagged
introducing commit to follow. Blame identifies `cd98e85a6b786d` as the
source of the documented preimage; `git show` confirms that commit added
queued IPU image conversion support and the API documentation.
Step 3.3 Record: recent local history for the file shows `96e9d754b35e8`
removing unused `ipu_image_convert_*` functions, `c942fddf8793b` adding
SPDX boilerplate conversion, and `cd98e85a6b786d` adding the header/API.
No prerequisite commit is needed for this documentation-only patch.
Step 3.4 Record: `git log --author='Randy Dunlap'` under fbdev/include
areas shows Randy has related cleanup/documentation work such as `fbdev:
hgafb: fix kernel-doc comments` and `fbdev: fbmon: fix function name in
kernel-doc`. The patch was reviewed by Philipp Zabel and committed by
Helge Deller, verified from the commit and lore thread.
Step 3.5 Record: no dependencies found. The diff changes only comments
and applies locally with `git apply --check`.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`
failed to find a lore match by patch-id, author/subject, or in-body
From. External fetch found the v3 discussion at
`https://yhbt.net/lore/dri-
devel/20260427183236.656902-1-rdunlap@infradead.org/T/`. The v3 thread
has Helge Deller replying “applied to fbdev git tree.” Web search/fetch
also found v2 and a v2 ping. No NAKs or objections were found.
Step 4.2 Record: `b4 dig -w` also failed for the same reason. The v3
lore mirror shows recipients included `dri-devel`, Philipp Zabel, DRM
maintainers, `imx`, `linux-arm-kernel`, Helge Deller, and `linux-fbdev`.
Step 4.3 Record: no `Reported-by:` or bug-report `Link:` tags exist. No
external crash/security bug report applies.
Step 4.4 Record: this is a standalone one-patch documentation cleanup.
v2 added the reviewed-by and updated Cc list; v3 rebased and resent.
Step 4.5 Record: direct `lore.kernel.org/stable` fetch was blocked by
Anubis. Web search for the exact subject plus `stable` found patch-
thread results but no stable-specific discussion or stable nomination.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified documented symbols are
`ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`.
Step 5.2 Record: `rg` found callers in `drivers/staging/media/imx/imx-
media-csc-scaler.c` for `ipu_image_convert_abort()`,
`ipu_image_convert_queue()`, `ipu_image_convert_adjust()`,
`ipu_image_convert_unprepare()`, and `ipu_image_convert_prepare()`.
Runtime callers are unaffected because only comments changed.
Step 5.3 Record: reading `drivers/gpu/ipu-v3/ipu-image-convert.c`
confirms the documented functions perform image format
adjustment/verification, context allocation, queueing, abort/unprepare,
and single conversion setup. None of those function bodies are touched.
Step 5.4 Record: runtime path is reachable through IPU image conversion
users, but the patch changes no runtime path. The affected path for the
fix is kernel-doc/documentation generation.
Step 5.5 Record: no related same-header kernel-doc fix was found by `git
log --grep='kernel-doc' -- include/video/imx-ipu-image-convert.h`.
## Phase 6: Stable Tree Analysis
Step 6.1 Record: version tags `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.15`, `v6.16`, and `v6.17` all contain `include/video/imx-ipu-image-
convert.h` with the old kernel-doc text. The API was introduced before
`v4.9-rc1`, so active stable trees checked contain the documentation
issue.
Step 6.2 Record: expected backport difficulty is clean or minor. `git
apply --check` succeeds against the current local tree, and the checked
stable tags contain representative preimage lines. Full per-stable
worktree application was not run.
Step 6.3 Record: no related stable fix for this header was found in
local `git log --grep` searches.
## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is fbdev/gpu IPU-v3 image conversion
documentation in an include header. Runtime criticality is
peripheral/driver-specific; documentation-build criticality is low.
Step 7.2 Record: local subsystem history shows ongoing cleanup/removal
activity in `drivers/gpu/ipu-v3` and the header, including unused-
function removals and treewide cleanup. This patch is not part of a
required functional series.
## Phase 8: Impact And Risk
Step 8.1 Record: affected population is kernel documentation builders,
maintainers, and users consuming generated kernel-doc. Runtime users of
IPU-v3 are not affected by behavior.
Step 8.2 Record: trigger is running kernel-doc/documentation tooling
over this header. It is not triggered by boot, device probe, syscalls,
or ordinary runtime use. Unprivileged runtime trigger does not apply.
Step 8.3 Record: failure mode is documentation warnings only. Severity
is LOW. I did not verify any configuration where these warnings are
fatal, so that does not drive the decision.
Step 8.4 Record: benefit is low but real under the documentation-fix
exception: it makes stable documentation builds cleaner. Risk is
extremely low because only comments change. Risk/benefit is favorable if
stable accepts documentation corrections.
## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: pure documentation
correction, explicitly fixes listed kernel-doc warnings, tiny single-
file patch, reviewed by Philipp Zabel, applied by Helge Deller, old text
exists in active stable tags checked, and documentation/comment fixes
are an allowed stable exception. Evidence against: no runtime bug, no
crash/security/data-corruption impact, no stable nomination found, and
b4 could not match the thread. Unresolved: direct stable-lore search was
blocked; full apply checks on every stable branch were not run.
Step 9.2 Record:
1. Obviously correct and tested? Mostly yes for documentation syntax;
reviewed and applied, but no `Tested-by`.
2. Fixes a real bug that affects users? Yes, a real kernel-doc warning
issue; not a runtime bug.
3. Important issue? No runtime severity; LOW documentation-build
severity.
4. Small and contained? Yes, 11 additions and 5 deletions in one header.
5. No new features or APIs? Yes, comments only.
6. Can apply to stable trees? Likely yes; local apply check passed and
stable tags checked contain the preimage.
Step 9.3 Record: exception category applies: documentation/comment fix.
This is the main reason to accept despite lack of runtime impact.
Step 9.4 Decision: backporting is appropriate under the stable
documentation-fix exception. It is not a stability/security fix, but it
is a correct, reviewed, zero-runtime-risk cleanup of real kernel-doc
warnings in code present across active stable trees.
## Verification
- Phase 1: fetched and inspected committed metadata for
`f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`; confirmed tags and
message.
- Phase 2: `git show --stat --patch` confirmed one header, 11
insertions, 5 deletions, comments only.
- Phase 3: `git blame` confirmed changed comment preimage from
`cd98e85a6b786d`; `git describe --contains` placed it before
`v4.9-rc1`; `git show cd98e85a6b786d` confirmed original API addition.
- Phase 3: `git log` on the header/subsystem found no prerequisite
functional series.
- Phase 4: `b4 dig`, `b4 dig -a`, and `b4 dig -w` all failed to match;
recorded as a tool limitation/failure.
- Phase 4: WebFetch of the v3 lore mirror confirmed the patch thread and
Helge Deller’s applied reply; Spinics fetch confirmed v2 and a later
ping.
- Phase 5: `rg` found runtime users; `ReadFile` of implementation
confirmed function bodies exist but are not changed.
- Phase 6: tag checks confirmed the header and old doc text in `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.15`, `v6.16`, and `v6.17`; `git
apply --check` succeeded locally.
- Phase 8: severity/risk assessment is derived from the verified
comments-only diff.
- UNVERIFIED: direct `lore.kernel.org/stable` search content was blocked
by Anubis; no actual `make htmldocs` run was performed; full patch
application against every individual stable branch was not performed.
**YES**
include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/video/imx-ipu-image-convert.h b/include/video/imx-ipu-image-convert.h
index 003b3927ede5c..6b77968a6a150 100644
--- a/include/video/imx-ipu-image-convert.h
+++ b/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
int status;
+ /* private: */
/* internal to image converter, callers don't touch */
struct list_head list;
};
/**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
*
* @run: the completed conversion run pointer
* @ctx: a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu_image *in, struct ipu_image *out,
* @out: output image format
* @rot_mode: rotation mode
*
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
* -EINVAL otherwise.
*/
int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
* @complete: run completion callback
* @complete_context: a context pointer for the completion callback
*
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
* on failure. The input/output formats and rotation mode must already meet
* IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
*/
struct ipu_image_convert_ctx *
ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct ipu_image_convert_ctx *ctx);
* In V4L2, drivers should call ipu_image_convert_queue() while
* streaming to queue the conversion of a received input buffer.
* For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
*/
int ipu_image_convert_queue(struct ipu_image_convert_run *run);
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx);
* On successful return the caller can queue more run requests if needed, using
* the prepared context in run->ctx. The caller is responsible for unpreparing
* the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
*/
struct ipu_image_convert_run *
ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
--
2.53.0
^ permalink raw reply related
* [PATCH 0/8] arm64: dts: qcom: Devicetree support for Kaanapali GPU
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen,
Qingqing Zhou, Jingyi Wang, Gaurav Kohli
This series adds the necessary Device Tree bits to enable GPU support
on the Kaanapali-based devices. The Adreno 840 GPU present in Kaanapali
chipsets is based on the new Adreno A8x family of GPUs. It features a
new slice architecture with 3 slices, raytracing support and other
improvements.
This series includes patches that updates DT schema, add GPU SMMU,
GPU/GMU support, GPU cooling, and enables the GPU on Kaanapali MTP and
QRD platforms.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Akhil P Oommen (5):
dt-bindings: arm-smmu: Update the description for Kaanapali GPU SMMU
dt-bindings: display/msm: gpu: Document Adreno 840
arm64: dts: qcom: Add GPU support for Kaanapali
arm64: dts: qcom: kaanapali-mtp: Enable GPU
arm64: dts: qcom: kaanapali-qrd: Enable GPU
Gaurav Kohli (1):
arm64: dts: qcom: kaanapali: Add GPU cooling
Jingyi Wang (1):
arm64: dts: qcom: kaanapali: Add qfprom node
Qingqing Zhou (1):
arm64: dts: qcom: kaanapali: add the GPU SMMU node
.../devicetree/bindings/display/msm/gpu.yaml | 5 +-
.../devicetree/bindings/iommu/arm,smmu.yaml | 1 +
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 8 +
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 8 +
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 450 +++++++++++++++++++--
5 files changed, 441 insertions(+), 31 deletions(-)
---
base-commit: b462608de92a7cac450781f9d8d4c7cf3ccf82db
change-id: 20260412-kaana-gpu-dt-968a70134c22
prerequisite-message-id: <20260427-gfx-clk-fixes-v2-0-797e54b3d464@oss.qualcomm.com>
prerequisite-patch-id: 82e142b3d904e746db0e288fb7ea6812661c3537
prerequisite-patch-id: d141a83ef741d26b03d931cf120b8b541ec51b9c
prerequisite-patch-id: 5bdaf78fd75be779d4aa73b85a185a10d8458366
prerequisite-patch-id: 0263b47f4e1aeb61fc96c6dbd9f7168ffe0eb04e
prerequisite-patch-id: bed1e449dca0167ed99e8c4f1e544ed60ae17014
prerequisite-patch-id: feda87721f22e443f38165787b2b28fe1a40aa18
prerequisite-message-id: <20260512-glymur-gpu-dt-v3-1-84232dc21c03@oss.qualcomm.com>
prerequisite-patch-id: 9175e9ae77ac032c2f0502e2c63bb7b7d1ae4ead
prerequisite-patch-id: a29ab9cea24f74a76a69f144f76f9860e014ad19
prerequisite-patch-id: 6243ab821a3d9cd641a8dca8cdab167fe9da8735
prerequisite-patch-id: 36f4bb7740fd65d808fa6685bce4b03798a547ff
prerequisite-patch-id: 054631082c45d3ab3117f541f0d4d90b660dac73
Best regards,
--
Akhil P Oommen <akhilpo@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/8] dt-bindings: arm-smmu: Update the description for Kaanapali GPU SMMU
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Extend the sm8750's clock description section to also cover Kaanapali GPU
SMMU since it uses the same single "hlos" vote clock.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index b811ece722c9..d1330fc0178a 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -568,6 +568,7 @@ allOf:
items:
- enum:
- qcom,glymur-smmu-500
+ - qcom,kaanapali-smmu-500
- qcom,sm8750-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
--
2.51.0
^ permalink raw reply related
* [PATCH 2/8] dt-bindings: display/msm: gpu: Document Adreno 840
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Adreno 840 GPU found in Kaanapali chipsets belongs to the A8x family.
It is a new IP which features the new slice architecture with 3 slices,
raytracing support, and the highest GMEM size seen so far on a Snapdragon
mobile chipsets. Update the dt bindings documentation to describe this GPU.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index e67cd708dda2..35c6d38dc379 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -415,7 +415,9 @@ allOf:
properties:
compatible:
contains:
- const: qcom,adreno-44070001
+ enum:
+ - qcom,adreno-44050a01
+ - qcom,adreno-44070001
then:
properties:
reg:
@@ -450,6 +452,7 @@ allOf:
- qcom,adreno-43050a01
- qcom,adreno-43050c01
- qcom,adreno-43051401
+ - qcom,adreno-44050a01
- qcom,adreno-44070001
then: # Starting with A6xx, the clocks are usually defined in the GMU node
--
2.51.0
^ permalink raw reply related
* [PATCH 4/8] arm64: dts: qcom: kaanapali: Add qfprom node
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen, Jingyi Wang
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
From: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Add the qfprom node and gpu related subnodes on Kaanapali SoC.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 26a4de9c8d45..0211fc9f8c88 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -5868,6 +5868,18 @@ rpmhpd_opp_super_turbo_no_cpr: opp-480 {
};
};
+ efuse@221c8000 {
+ compatible = "qcom,kaanapali-qfprom", "qcom,qfprom";
+ reg = <0x0 0x221c8000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ gpu_speed_bin: gpu-speed-bin@142 {
+ reg = <0x142 0x2>;
+ bits = <3 9>;
+ };
+ };
+
nsp_noc: interconnect@260c0000 {
compatible = "qcom,kaanapali-nsp-noc";
reg = <0x0 0x260c0000 0x0 0x21280>;
--
2.51.0
^ permalink raw reply related
* [PATCH 3/8] arm64: dts: qcom: kaanapali: add the GPU SMMU node
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen,
Qingqing Zhou
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
From: Qingqing Zhou <quic_qqzhou@quicinc.com>
Add the Adreno GPU SMMU node for kaanapali platform.
Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 41 +++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index bab654bbd6d0..26a4de9c8d45 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -2597,6 +2597,47 @@ gpucc: clock-controller@3d90000 {
#power-domain-cells = <1>;
};
+ adreno_smmu: iommu@3da0000 {
+ compatible = "qcom,kaanapali-smmu-500", "qcom,adreno-smmu",
+ "qcom,smmu-500", "arm,mmu-500";
+ reg = <0x0 0x3da0000 0x0 0x40000>;
+ #iommu-cells = <2>;
+ #global-interrupts = <1>;
+ dma-coherent;
+
+ power-domains = <&gpucc GPU_CC_CX_GDSC>;
+
+ clocks = <&gpucc GPU_CC_GPU_SMMU_VOTE_CLK>;
+ clock-names = "hlos";
+
+ interrupts = <GIC_SPI 674 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 678 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 679 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 680 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 681 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 682 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 683 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 684 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 685 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 686 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 687 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 476 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 574 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 575 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 576 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 577 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 660 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 662 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 665 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 666 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 667 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 669 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 670 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 700 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
remoteproc_adsp: remoteproc@6800000 {
compatible = "qcom,kaanapali-adsp-pas", "qcom,sm8550-adsp-pas";
reg = <0x0 0x06800000 0x0 0x10000>;
--
2.51.0
^ permalink raw reply related
* [PATCH 5/8] arm64: dts: qcom: Add GPU support for Kaanapali
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Adreno 840 present in Kaanapali SoC is the second generation GPU in
A8x family. It is based on the new slice architecture with 3 slices,
higher GMEM/caches etc.
There is some re-arrangement in the reglist to properly cover maximum
register region. Other than this, the DT description is mostly similar
to the existing chipsets except the OPP tables.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 232 ++++++++++++++++++++++++++++++++
1 file changed, 232 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 0211fc9f8c88..c57aea44218e 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -2573,6 +2573,238 @@ videocc: clock-controller@20f0000 {
#power-domain-cells = <1>;
};
+ gpu: gpu@3d00000 {
+ compatible = "qcom,adreno-44050a01", "qcom,adreno";
+ reg = <0x0 0x03d00000 0x0 0x6c000>,
+ <0x0 0x03d9e000 0x0 0x2000>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem";
+
+ interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+ iommus = <&adreno_smmu 0 0x0>,
+ <&adreno_smmu 1 0x0>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ qcom,gmu = <&gmu>;
+ #cooling-cells = <2>;
+
+ nvmem-cells = <&gpu_speed_bin>;
+ nvmem-cell-names = "speed_bin";
+
+ interconnects = <&gem_noc MASTER_GFX3D QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "gfx-mem";
+
+ gpu_zap_shader: zap-shader {
+ memory-region = <&gpu_microcode_mem>;
+ };
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2-adreno",
+ "operating-points-v2";
+
+ opp-222000000 {
+ opp-hz = /bits/ 64 <222000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D2>;
+ opp-peak-kBps = <2136718>;
+ opp-supported-hw = <0x0f>;
+ /* ACD is disabled */
+ };
+
+ opp-282000000 {
+ opp-hz = /bits/ 64 <282000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1_1>;
+ opp-peak-kBps = <5285156>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xca2e5ffd>;
+ };
+
+ opp-342000000 {
+ opp-hz = /bits/ 64 <342000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+ opp-peak-kBps = <5285156>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xe22a5ffd>;
+ };
+
+ opp-382000000 {
+ opp-hz = /bits/ 64 <382000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D0>;
+ opp-peak-kBps = <5285156>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xa22c5ffd>;
+ };
+
+ opp-422000000 {
+ opp-hz = /bits/ 64 <422000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xa22c5ffd>;
+ };
+
+ opp-461000000 {
+ opp-hz = /bits/ 64 <461000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L0>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xe82e5ffd>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L1>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xe82c5ffd>;
+ };
+
+ opp-539000000 {
+ opp-hz = /bits/ 64 <539000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L2>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xc82b5ffd>;
+ };
+
+ opp-578000000 {
+ opp-hz = /bits/ 64 <578000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xc02c5ffd>;
+ };
+
+ opp-646000000 {
+ opp-hz = /bits/ 64 <646000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L0>;
+ opp-peak-kBps = <8171875>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xc02c5ffd>;
+ };
+
+ opp-726000000 {
+ opp-hz = /bits/ 64 <726000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ opp-peak-kBps = <8171875>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0x882f5ffd>;
+ };
+
+ opp-826000000 {
+ opp-hz = /bits/ 64 <826000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L2>;
+ opp-peak-kBps = <12449218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xa82c5ffd>;
+ };
+
+ opp-902000000 {
+ opp-hz = /bits/ 64 <902000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ opp-peak-kBps = <12449218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xa82b5ffd>;
+ };
+
+ opp-967000000 {
+ opp-hz = /bits/ 64 <967000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
+ opp-peak-kBps = <12449218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0x882a5ffd>;
+ };
+
+ opp-1050000000 {
+ opp-hz = /bits/ 64 <1050000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
+ opp-peak-kBps = <20832031>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0x88295ffd>;
+ };
+
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L3>;
+ opp-peak-kBps = <20832031>;
+ opp-supported-hw = <0x07>;
+ qcom,opp-acd-level = <0xa02e5ffd>;
+ };
+
+ opp-1300000000 {
+ opp-hz = /bits/ 64 <1300000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L4>;
+ opp-peak-kBps = <20832031>;
+ opp-supported-hw = <0x03>;
+ qcom,opp-acd-level = <0x802d5ffd>;
+ };
+ };
+ };
+
+ gmu: gmu@3d6c000 {
+ compatible = "qcom,adreno-gmu-840.1", "qcom,adreno-gmu";
+
+ reg = <0x0 0x03d6c000 0x0 0x68000>;
+ reg-names = "gmu";
+
+ interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = <&gpucc GPU_CC_AHB_CLK>,
+ <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+ <&gcc GCC_GPU_GEMNOC_GFX_CLK>,
+ <&gpucc GPU_CC_HUB_CX_INT_CLK>;
+ clock-names = "ahb",
+ "gmu",
+ "cxo",
+ "memnoc",
+ "hub";
+
+ power-domains = <&gpucc GPU_CC_CX_GDSC>,
+ <&gxclkctl GX_CLKCTL_GX_GDSC>;
+ power-domain-names = "cx",
+ "gx";
+
+ iommus = <&adreno_smmu 5 0x0>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ operating-points-v2 = <&gmu_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-475000000 {
+ opp-hz = /bits/ 64 <475000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+ };
+
+ opp-575000000 {
+ opp-hz = /bits/ 64 <575000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ };
+
+ opp-700000000 {
+ opp-hz = /bits/ 64 <700000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ };
+
+ opp-725000000 {
+ opp-hz = /bits/ 64 <725000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ };
+
+ opp-750000000 {
+ opp-hz = /bits/ 64 <750000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ };
+ };
+ };
+
gxclkctl: clock-controller@3d64000 {
compatible = "qcom,kaanapali-gxclkctl";
reg = <0x0 0x03d64000 0x0 0x6000>;
--
2.51.0
^ permalink raw reply related
* [PATCH 6/8] arm64: dts: qcom: kaanapali: Add GPU cooling
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen, Gaurav Kohli
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
From: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Unlike the CPU, the GPU does not throttle its speed automatically when it
reaches high temperatures.
Set up GPU cooling by throttling the GPU speed
when reaching 105°C.
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 165 ++++++++++++++++++++++++++------
1 file changed, 135 insertions(+), 30 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index c57aea44218e..5089416ec32c 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -26,6 +26,7 @@
#include <dt-bindings/soc/qcom,gpr.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
#include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
+#include <dt-bindings/thermal/thermal.h>
#include "kaanapali-ipcc.h"
@@ -7045,13 +7046,15 @@ nsphmx-3-critical {
};
gpuss-0-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 0>;
trips {
- gpuss-0-hot {
- temperature = <120000>;
+ gpuss_0_alert0: gpuss-0-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-0-critical {
@@ -7060,16 +7063,25 @@ gpuss-0-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-1-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 1>;
trips {
- gpuss-1-hot {
- temperature = <120000>;
+ gpuss_1_alert0: gpuss-1-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-1-critical {
@@ -7078,16 +7090,25 @@ gpuss-1-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_1_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-2-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 2>;
trips {
- gpuss-2-hot {
- temperature = <120000>;
+ gpuss_2_alert0: gpuss-2-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-2-critical {
@@ -7096,16 +7117,25 @@ gpuss-2-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_2_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-3-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 3>;
trips {
- gpuss-3-hot {
- temperature = <120000>;
+ gpuss_3_alert0: gpuss-3-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-3-critical {
@@ -7114,16 +7144,25 @@ gpuss-3-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_3_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-4-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 4>;
trips {
- gpuss-4-hot {
- temperature = <120000>;
+ gpuss_4_alert0: gpuss-4-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-4-critical {
@@ -7132,16 +7171,25 @@ gpuss-4-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_4_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-5-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 5>;
trips {
- gpuss-5-hot {
- temperature = <120000>;
+ gpuss_5_alert0: gpuss-5-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-5-critical {
@@ -7150,16 +7198,25 @@ gpuss-5-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_5_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-6-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 6>;
trips {
- gpuss-6-hot {
- temperature = <120000>;
+ gpuss_6_alert0: gpuss-6-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-6-critical {
@@ -7168,16 +7225,25 @@ gpuss-6-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_6_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-7-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 7>;
trips {
- gpuss-7-hot {
- temperature = <120000>;
+ gpuss_7_alert0: gpuss-7-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-7-critical {
@@ -7186,16 +7252,25 @@ gpuss-7-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_7_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-8-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 8>;
trips {
- gpuss-8-hot {
- temperature = <120000>;
+ gpuss_8_alert0: gpuss-8-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-8-critical {
@@ -7204,16 +7279,25 @@ gpuss-8-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_8_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-9-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 9>;
trips {
- gpuss-9-hot {
- temperature = <120000>;
+ gpuss_9_alert0: gpuss-9-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-9-critical {
@@ -7222,12 +7306,26 @@ gpuss-9-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_9_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-10-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 10>;
trips {
+ gpuss_10_alert0: gpuss-10-alert0 {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
gpuss-10-hot {
temperature = <120000>;
hysteresis = <5000>;
@@ -7240,6 +7338,13 @@ gpuss-10-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_10_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
ddr-thermal {
--
2.51.0
^ permalink raw reply related
* [PATCH 7/8] arm64: dts: qcom: kaanapali-mtp: Enable GPU
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Add the secure firmware name property and enable GPU support on
Kaanapali MTP device.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
index f9b5b5718b90..ba256039dd3c 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
@@ -865,6 +865,14 @@ vreg_l7n_3p3: ldo7 {
};
};
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/kaanapali/gen80200_zap.mbn";
+};
+
&lpass_vamacro {
pinctrl-0 = <&dmic01_default>, <&dmic23_default>;
pinctrl-names = "default";
--
2.51.0
^ permalink raw reply related
* [PATCH 8/8] arm64: dts: qcom: kaanapali-qrd: Enable GPU
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Add the secure firmware name property and enable GPU support on
Kaanapali QRD device.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
index 55d02219ef4e..6bef8ec151f8 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
@@ -693,6 +693,14 @@ vreg_l7n_3p3: ldo7 {
};
};
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/kaanapali/gen80200_zap.mbn";
+};
+
&pmh0101_flash {
status = "okay";
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v3 4/7] PCI: dwc: Use common pci_host_common_link_train_delay() helper
From: Hans Zhang @ 2026-05-12 0:43 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: bhelgaas, lpieralisi, mani, vigneshr, jingoohan1,
thomas.petazzoni, pali, ryder.lee, claudiu.beznea.uj, mpillai,
robh, s-vadapalli, linux-omap, linux-arm-kernel, claudiu.beznea,
linux-mediatek, linux-renesas-soc, linux-pci, linux-kernel
In-Reply-To: <20260511070139.GA1096586@rocinante>
On 5/11/26 15:02, Krzysztof Wilczyński wrote:
> Hello,
>
>> - /*
>> - * As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link
>> - * speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms
>> - * after Link training completes before sending a Configuration Request.
>> - */
>> - if (pci->max_link_speed > 2)
>> - msleep(PCIE_RESET_CONFIG_WAIT_MS);
>> + pci_host_common_link_train_delay(pci->max_link_speed);
>
> This comment could move to the helper you added.
Hi Krzysztof,
Will add.
Best regards,
Hans
>
> Thank you!
>
> Krzysztof
^ permalink raw reply
* Re: [PATCH v19 0/7] ring-buffer: Making persistent ring buffers robust
From: Masami Hiramatsu @ 2026-05-12 0:54 UTC (permalink / raw)
To: Steven Rostedt
Cc: Catalin Marinas, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel
In-Reply-To: <20260511122943.41e204bc@gandalf.local.home>
On Mon, 11 May 2026 12:29:43 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> On Thu, 7 May 2026 13:14:16 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> > > I'll test this some more, and make a proper patch.
> >
> > Ah, indeed. Thanks for fixing!
> >
> > BTW, shouldn't we unify common logic of those functions?
>
> Hmm, there's not much common between the two. One is a consuming read and
> the other is a non-consuming read that needs to test for a bunch of race
> conditions.
>
> If you see something that can be shared, I'm all for it.
Maybe we can introduce a common inline function to calculate
max_loop, or at least replacing "3" with a common macro.
Thank you,
>
> -- Steve
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v3] coresight: fix missing error code when trace ID is invalid
From: Jie Gan @ 2026-05-12 0:54 UTC (permalink / raw)
To: Leo Yan
Cc: Richard Cheng, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260511144556.GA34802@e132581.arm.com>
On 5/11/2026 10:45 PM, Leo Yan wrote:
> On Mon, May 11, 2026 at 05:27:10PM +0800, Jie Gan wrote:
>
> [...]
>
>>>> @@ -755,10 +755,16 @@ void coresight_path_assign_trace_id(struct coresight_path *path,
>>>> * Non 0 is either success or fail.
>>>> */
>>>> if (trace_id != 0) {
>>>> - path->trace_id = trace_id;
>>>> - return;
>>>> + if (IS_VALID_CS_TRACE_ID(trace_id)) {
>>>> + path->trace_id = trace_id;
>>>> + return 0;
>>>> + }
>>>> +
>>>> + return -EINVAL;
>
> I'd advocate a bit early exit style, like:
>
> /* 0 means the device has no ID assignment, so keep searching */
> if (trace_id == 0)
> continue;
>
> if (!IS_VALID_CS_TRACE_ID(trace_id))
> return -EINVAL;
>
> path->trace_id = trace_id;
> return 0;
>
> Early exit can reduce indentation depth, and it handles simple cases
> first and then the complex logic. In some cases (maye not this case),
> we may benefit a bit from compiler optimization [1].
>
Thanks, that's a good suggestion and much simpler than my solution.
> [1] https://xania.org/202512/18-partial-inlining
>
> [...]
>
>> The return value has been ignored in perf mode. It will introduce noisy by
>> adding __must_check. So I think its better without __must_check?
>
> Wouldn't it need to update perf mode as well?
I will also update the perf mode for consistent usage.
Thanks,
Jie
>
> Regarding __must_check, I searched Documentation but didn't find
> guidance on when it should be used. I don't want to use this annotation
> randomly (some functions use it and some not), this will be hard for
> everyone to follow up.
>
> IMO, it's fine not to use __must_check here. I would leave this to
> Suzuki and other maintainers if have different opinions.
>
> Thanks,
> Leo
^ permalink raw reply
* Re: [PATCH 1/2] drm/rockchip: dsi: Add maximum per lane bit rate calculation
From: Chaoyi Chen @ 2026-05-12 1:07 UTC (permalink / raw)
To: Heiko Stübner
Cc: Chaoyi Chen, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Guochun Huang, dri-devel, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260324085838.90-1-kernel@airkyi.com>
Hi,
On 3/24/2026 4:58 PM, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> Different chips have varying support for the maximum bit rate per lane.
>
> Add calculation for the maximum per lane bit rate for various chip
> platforms, and relax the bandwidth margin requirements.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> ---
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 21 +++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 3547d91b25d3..d3bacfae174e 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -268,6 +268,7 @@ struct rockchip_dw_dsi_chip_data {
>
> unsigned int flags;
> unsigned int max_data_lanes;
> + unsigned long max_bit_rate_per_lane;
> };
>
> struct dw_mipi_dsi_rockchip {
> @@ -565,7 +566,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
> int bpp;
> unsigned long mpclk, tmp;
> unsigned int target_mbps = 1000;
> - unsigned int max_mbps = dppa_map[ARRAY_SIZE(dppa_map) - 1].max_mbps;
> + unsigned int max_mbps;
> unsigned long best_freq = 0;
> unsigned long fvco_min, fvco_max, fin, fout;
> unsigned int min_prediv, max_prediv;
> @@ -573,6 +574,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
> unsigned long _fbdiv, best_fbdiv;
> unsigned long min_delta = ULONG_MAX;
>
> + max_mbps = dsi->cdata->max_bit_rate_per_lane;
> dsi->format = format;
> bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> if (bpp < 0) {
> @@ -584,8 +586,8 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
>
> mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
> if (mpclk) {
> - /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
> - tmp = mpclk * (bpp / lanes) * 10 / 8;
> + /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
> + tmp = mpclk * (bpp / lanes) * 10 / 9;
> if (tmp < max_mbps)
> target_mbps = tmp;
> else
> @@ -595,7 +597,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
>
> /* for external phy only a the mipi_dphy_config is necessary */
> if (dsi->phy) {
> - phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 8,
> + phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 9,
> bpp, lanes,
> &dsi->phy_opts.mipi_dphy);
> dsi->lane_mbps = target_mbps;
> @@ -1503,6 +1505,7 @@ static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
> PX30_DSI_FORCETXSTOPMODE), 0),
>
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1000000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1515,6 +1518,7 @@ static const struct rockchip_dw_dsi_chip_data rk3128_chip_data[] = {
> RK3128_DSI_FORCERXMODE |
> RK3128_DSI_FORCETXSTOPMODE), 0),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1000000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1527,6 +1531,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
> .lcdsel_lit = FIELD_PREP_WM16_CONST(RK3288_DSI0_LCDC_SEL, 1),
>
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> {
> .reg = 0xff964000,
> @@ -1535,6 +1540,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
> .lcdsel_lit = FIELD_PREP_WM16_CONST(RK3288_DSI1_LCDC_SEL, 1),
>
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1547,6 +1553,7 @@ static const struct rockchip_dw_dsi_chip_data rk3368_chip_data[] = {
> RK3368_DSI_FORCETXSTOPMODE |
> RK3368_DSI_FORCERXMODE), 0),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1634,6 +1641,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
>
> .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> {
> .reg = 0xff968000,
> @@ -1658,6 +1666,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
>
> .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
>
> .dphy_rx_init = rk3399_dphy_tx1rx1_init,
> .dphy_rx_power_on = rk3399_dphy_tx1rx1_power_on,
> @@ -1674,6 +1683,7 @@ static const struct rockchip_dw_dsi_chip_data rk3506_chip_data[] = {
> FIELD_PREP_WM16_CONST(RK3506_DSI_FORCERXMODE, 0) |
> FIELD_PREP_WM16_CONST(RK3506_DSI_FORCETXSTOPMODE, 0)),
> .max_data_lanes = 2,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1687,6 +1697,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
> FIELD_PREP_WM16_CONST(RK3568_DSI0_TURNDISABLE, 0) |
> FIELD_PREP_WM16_CONST(RK3568_DSI0_FORCERXMODE, 0)),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1200000000UL,
> },
> {
> .reg = 0xfe070000,
> @@ -1696,6 +1707,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
> FIELD_PREP_WM16_CONST(RK3568_DSI1_TURNDISABLE, 0) |
> FIELD_PREP_WM16_CONST(RK3568_DSI1_FORCERXMODE, 0)),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1200000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1708,6 +1720,7 @@ static const struct rockchip_dw_dsi_chip_data rv1126_chip_data[] = {
> FIELD_PREP_WM16_CONST(RV1126_DSI_FORCERXMODE, 0) |
> FIELD_PREP_WM16_CONST(RV1126_DSI_FORCETXSTOPMODE, 0)),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1000000000UL,
> },
> { /* sentinel */ }
> };
Gentle ping about this.
Thanks!
--
Best,
Chaoyi
^ permalink raw reply
* Re: [PATCH v5 0/8] unwind, arm64: add sframe unwinder for kernel
From: Dylan Hatch @ 2026-05-12 1:10 UTC (permalink / raw)
To: Jens Remus
Cc: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan,
Song Liu, joe.lawrence, linux-toolchains, linux-kernel,
live-patching, linux-arm-kernel, Randy Dunlap, Heiko Carstens
In-Reply-To: <549d10b6-ba2b-4ae9-86ef-6157e13b6ee3@linux.ibm.com>
On Thu, Apr 30, 2026 at 3:11 AM Jens Remus <jremus@linux.ibm.com> wrote:
>
> On 4/28/2026 8:36 PM, Dylan Hatch wrote:
> > Implement a generic kernel sframe-based [1] unwinder. The main goal is
> > to improve reliable stacktrace on arm64 by unwinding across exception
> > boundaries.
>
> Please add support to initialize the optional sframe unwinder debug
> information. Either in the appropriate patches in this series or as a
> separate patch.
Sounds good, I'll add this in as a separate patch in the next version.
>
> Note that for the module case I wonder whether it would be preferable
> to somehow indicate that it is a module name in the string, e.g.
> "(<module-name>)" or "<module-name> (module)"?
I don't have a strong preference, though I agree it makes sense to
indicate that the section is from a module. For now I'll add the
parentheses "(<module-name>)".
>
> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> --- a/kernel/unwind/sframe.c
> +++ b/kernel/unwind/sframe.c
> @@ -1028,6 +1028,8 @@ void __init init_sframe_table(void)
> kernel_sfsec.text_start = (unsigned long)_stext;
> kernel_sfsec.text_end = (unsigned long)_etext;
>
> + dbg_init(&kernel_sfsec);
> +
> if (WARN_ON(sframe_read_header(&kernel_sfsec)))
> return;
> if (WARN_ON(sframe_validate_section(&kernel_sfsec)))
> @@ -1047,6 +1049,8 @@ void sframe_module_init(struct module *mod, void *sframe, size_t sframe_size,
> sec->text_start = (unsigned long)text;
> sec->text_end = (unsigned long)text + text_size;
>
> + dbg_init(sec);
> +
> if (WARN_ON(sframe_read_header(sec)))
> return;
> if (WARN_ON(sframe_validate_section(sec)))
> diff --git a/kernel/unwind/sframe_debug.h b/kernel/unwind/sframe_debug.h
> --- a/kernel/unwind/sframe_debug.h
> +++ b/kernel/unwind/sframe_debug.h
> @@ -32,6 +32,18 @@ static inline void dbg_init(struct sframe_section *sec)
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
>
> + if (sec->sec_type == SFRAME_KERNEL) {
> + if (sec == &kernel_sfsec) {
> + sec->filename = kstrdup("(vmlinux)", GFP_KERNEL);
> + } else {
> + struct module *mod = container_of(sec, struct module,
> + arch.sframe_sec);
> + sec->filename = kstrdup(mod->name, GFP_KERNEL);
> + }
> +
> + return;
> + }
> +
> guard(mmap_read_lock)(mm);
> vma = vma_lookup(mm, sec->sframe_start);
> if (!vma)
>
> Regards,
> Jens
> --
> Jens Remus
> Linux on Z Development (D3303)
> jremus@de.ibm.com / jremus@linux.ibm.com
>
> IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
> IBM Data Privacy Statement: https://www.ibm.com/privacy/
>
Thanks for the suggestion,
Dylan
^ permalink raw reply
* Re: [PATCH PARTIAL-RESEND v12 0/5] Add support MT6316/6363/MT6373 PMICs regulators and MFD
From: Mark Brown @ 2026-05-12 1:25 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <20260511101355.122478-1-angelogioacchino.delregno@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Mon, May 11, 2026 at 12:13:50PM +0200, AngeloGioacchino Del Regno wrote:
> Changes in v12:
> - This is a partial resend. MT6373 regulators and MFD patches were not picked.
> - Rebased over next-20260508
Is there a reason why this is a single patch series, are there any
interdependencies here?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: altera_edac: Guard SDRAM irq2 retrieval for Arria10 only
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-05-12 1:37 UTC (permalink / raw)
To: Dinh Nguyen, bp@alien8.de, tony.luck@intel.com
Cc: linux-edac@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <cc767b60-3b91-40d5-aa70-c5f252d1d39b@kernel.org>
On 11/5/2026 7:54 pm, Dinh Nguyen wrote:
>
>
> On 5/8/26 02:52, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>
>> Guard the irq2 retrieval with an of_machine_is_compatible() check so
>> that platform_get_irq(pdev, 1) is only called on Arria10 platforms.
>>
>> Signed-off-by: Nazim Amirul
>> <muhammad.nazim.amirul.nazle.asmade@altera.com>
>> Signed-off-by: Niravkumar L Rabara <nirav.rabara@altera.com>
>> ---
>> drivers/edac/altera_edac.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
>> index 4edd2088c2db..b30302198cd4 100644
>> --- a/drivers/edac/altera_edac.c
>> +++ b/drivers/edac/altera_edac.c
>> @@ -348,7 +348,8 @@ static int altr_sdram_probe(struct platform_device
>> *pdev)
>> }
>> /* Arria10 has a 2nd IRQ */
>> - irq2 = platform_get_irq(pdev, 1);
>> + if (of_machine_is_compatible("altr,socfpga-arria10"))
>> + irq2 = platform_get_irq(pdev, 1);
>> layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
>> layers[0].size = 1;
>
> Why? We already switch on arria10 later in the same function.
>
> Sorry, but NAK.
>
> Dinh
This driver were used by cyclone5 and arria10. Cyclone5 only has one
interrupt whereby arria10 has 2 interrupt. That is the reason why the
interrupt was guard by (of_machine_is_compatible("altr,socfpga-arria10"))
Nazim
^ permalink raw reply
* Re: [PATCH v12 1/5] dt-bindings: regulator: Document MediaTek MT6373 PMIC Regulators
From: Mark Brown @ 2026-05-12 1:39 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <20260511101355.122478-2-angelogioacchino.delregno@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Mon, May 11, 2026 at 12:13:51PM +0200, AngeloGioacchino Del Regno wrote:
> Add bindings for the regulators found in the MediaTek MT6363 PMIC,
> usually found in board designs using the MT6991 Dimensity 9400 and
> on MT8196 Kompanio SoC for Chromebooks, along with the MT6316 and
> MT6363 PMICs.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v4] coresight: fix missing error code when trace ID is invalid
From: Jie Gan @ 2026-05-12 1:56 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, Richard Cheng, Jie Gan
When coresight_path_assign_trace_id() cannot assign a valid trace ID,
coresight_enable_sysfs() takes the err_path goto with ret still 0,
returning success to the caller despite no trace session being started.
Change coresight_path_assign_trace_id() to return int, moving the
IS_VALID_CS_TRACE_ID() check inside it so it returns -EINVAL on failure
and 0 on success. Update both callers to propagate this return value
directly instead of inspecting path->trace_id after the call.
Fixes: d87d76d823d1 ("Coresight: Allocate trace ID after building the path")
Reviewed-by: James Clark <james.clark@linaro.org>
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v4:
- Refactor the coresight_path_assign_trace_id according to Leo's suggestion.
- Link to v3: https://lore.kernel.org/r/20260511-fix-trace-id-error-v3-1-ac4c8356efff@oss.qualcomm.com
Changes in v3:
- directly return the value for clear expression.
- Link to v2: https://lore.kernel.org/r/20260509-fix-trace-id-error-v2-1-c900bcbab3e9@oss.qualcomm.com
Changes in v2:
- Refactor the coresight_path_assign_trace_id function.
- Link to v1: https://lore.kernel.org/r/20260508-fix-trace-id-error-v1-1-5f11a5456fdf@oss.qualcomm.com
---
drivers/hwtracing/coresight/coresight-core.c | 23 +++++++++++++----------
drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +++--
drivers/hwtracing/coresight/coresight-priv.h | 2 +-
drivers/hwtracing/coresight/coresight-sysfs.c | 4 ++--
4 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 46f247f73cf6..2105bb813940 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -739,8 +739,8 @@ static int coresight_get_trace_id(struct coresight_device *csdev,
* Call this after creating the path and before enabling it. This leaves
* the trace ID set on the path, or it remains 0 if it couldn't be assigned.
*/
-void coresight_path_assign_trace_id(struct coresight_path *path,
- enum cs_mode mode)
+int coresight_path_assign_trace_id(struct coresight_path *path,
+ enum cs_mode mode)
{
struct coresight_device *sink = coresight_get_sink(path);
struct coresight_node *nd;
@@ -750,15 +750,18 @@ void coresight_path_assign_trace_id(struct coresight_path *path,
/* Assign a trace ID to the path for the first device that wants to do it */
trace_id = coresight_get_trace_id(nd->csdev, mode, sink);
- /*
- * 0 in this context is that it didn't want to assign so keep searching.
- * Non 0 is either success or fail.
- */
- if (trace_id != 0) {
- path->trace_id = trace_id;
- return;
- }
+ /* 0 means the device has no ID assignment, so keep searching */
+ if (trace_id == 0)
+ continue;
+
+ if (!IS_VALID_CS_TRACE_ID(trace_id))
+ return -EINVAL;
+
+ path->trace_id = trace_id;
+ return 0;
}
+
+ return -EINVAL;
}
/**
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f85dedf89a3f..89ba7c9a6613 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -324,6 +324,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
struct coresight_device *sink = NULL;
struct coresight_device *user_sink = NULL, *last_sink = NULL;
struct etm_event_data *event_data = NULL;
+ int ret;
event_data = alloc_event_data(cpu);
if (!event_data)
@@ -420,8 +421,8 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
}
/* ensure we can allocate a trace ID for this CPU */
- coresight_path_assign_trace_id(path, CS_MODE_PERF);
- if (!IS_VALID_CS_TRACE_ID(path->trace_id)) {
+ ret = coresight_path_assign_trace_id(path, CS_MODE_PERF);
+ if (ret) {
cpumask_clear_cpu(cpu, mask);
coresight_release_path(path);
continue;
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 1ea882dffd70..34c7e792adbd 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -153,7 +153,7 @@ int coresight_make_links(struct coresight_device *orig,
void coresight_remove_links(struct coresight_device *orig,
struct coresight_connection *conn);
u32 coresight_get_sink_id(struct coresight_device *csdev);
-void coresight_path_assign_trace_id(struct coresight_path *path,
+int coresight_path_assign_trace_id(struct coresight_path *path,
enum cs_mode mode);
#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM3X)
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index d2a6ed8bcc74..b6a870399e83 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -211,8 +211,8 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
goto out;
}
- coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
- if (!IS_VALID_CS_TRACE_ID(path->trace_id))
+ ret = coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
+ if (ret)
goto err_path;
ret = coresight_enable_path(path, CS_MODE_SYSFS);
---
base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
change-id: 20260508-fix-trace-id-error-dbfdd4d8f2d1
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v12 2/5] regulator: Add support for MediaTek MT6373 SPMI PMIC Regulators
From: Mark Brown @ 2026-05-12 2:04 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <20260511101355.122478-3-angelogioacchino.delregno@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
On Mon, May 11, 2026 at 12:13:52PM +0200, AngeloGioacchino Del Regno wrote:
> +static int mt6373_buck_unlock(struct regmap *map, bool unlock)
> +{
> + u16 buf = unlock ? MT6373_BUCK_TOP_UNLOCK_VALUE : 0;
> +
> + return regmap_bulk_write(map, MT6373_BUCK_TOP_KEY_PROT_LO, &buf, sizeof(buf));
regmap_bulk_write() takes a number of registers.
> +static irqreturn_t mt6373_oc_isr(int irq, void *data)
> +{
> + struct regulator_dev *rdev = (struct regulator_dev *)data;
> + struct mt6373_regulator_info *info = rdev_get_drvdata(rdev);
> +
> + disable_irq_nosync(info->virq);
> +
> + if (regulator_is_enabled_regmap(rdev))
> + regulator_notifier_call_chain(rdev, REGULATOR_EVENT_OVER_CURRENT, NULL);
If the hardware is reporting an error we should report an error.
> + INIT_DELAYED_WORK(&info->oc_work, mt6373_oc_irq_enable_work);
What stops this work on driver removal/unbind?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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