* Re: [PATCH 3/3] arm64: Sort registers in cpu-feature-registers.rst
From: Catalin Marinas @ 2026-07-02 15:22 UTC (permalink / raw)
To: Mark Brown
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, Peter Maydell,
Joey Gouly, linux-arm-kernel, linux-doc, linux-kernel
In-Reply-To: <20260522-arm64-cpu-ftr-regs-v1-3-19775b40faf0@kernel.org>
On Fri, May 22, 2026 at 06:58:39PM +0100, Mark Brown wrote:
> - 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 |
> +------------------------------+---------+---------+
The patch is fine but I just realised that we are really inconsistent
with the non-visible things. We exposed a few hear, I guess in the early
days, and then we stopped, just adding the occasional visible fields.
Shall we drop the 'visible' column altogether and only document the
visible fields here?
--
Catalin
^ permalink raw reply
* [PATCH v8 17/39] drm/bridge: dw-hdmi-qp: Rate limit i2c read error messages
From: Cristian Ciocaltea @ 2026-07-02 14:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com>
During EDID reads, repeated i2c errors can flood the kernel log:
[ 25.361716] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 25.363376] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
...
[ 25.368671] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 25.369440] dwhdmiqp-rockchip fde80000.hdmi: failed to get edid
Switch to dev_err_ratelimited() in dw_hdmi_qp_i2c_read() to reduce log
spam while still reporting the condition.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
index cfd1b18c06e6..7475b6b71836 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
@@ -561,7 +561,7 @@ static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi,
dev_dbg_ratelimited(hdmi->dev,
"i2c read timed out\n");
else
- dev_err(hdmi->dev, "i2c read timed out\n");
+ dev_err_ratelimited(hdmi->dev, "i2c read timed out\n");
dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
return -EAGAIN;
}
@@ -572,7 +572,7 @@ static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi,
dev_dbg_ratelimited(hdmi->dev,
"i2c read error\n");
else
- dev_err(hdmi->dev, "i2c read error\n");
+ dev_err_ratelimited(hdmi->dev, "i2c read error\n");
dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
return -EIO;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5] dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA
From: Vinod Koul @ 2026-07-02 15:25 UTC (permalink / raw)
To: Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd,
Hongling Zeng
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Frank Li, Frank Li
In-Reply-To: <20260701045733.33654-1-zenghongling@kylinos.cn>
On Wed, 01 Jul 2026 12:57:33 +0800, Hongling Zeng wrote:
> When terminating DMA transfers, active descriptors are not properly
> reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
> descriptors and their LLI chains to be permanently leaked.
>
> Fix by using vchan_terminate_vdesc() which handles both cyclic and
> non-cyclic descriptors by adding them to desc_terminated queue for
> proper cleanup.
>
> [...]
Applied, thanks!
[1/1] dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA
commit: ab1150115e68a46b687eb38c1ab92782018c9f2c
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: can: rockchip: add rk3588 CAN-FD compatible
From: Cunhao Lu @ 2026-07-02 15:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, Rob Herring, Krzysztof Kozlowski, kernel,
Conor Dooley, Heiko Stuebner, Dmitry Torokhov, Shengjiu Wang,
Pengpeng Hou, Russell King, Eric Biggers, Mario Limonciello,
Karl Mehltretter, Yixun Lan, Stephen Boyd, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <ec548326-dd8d-4d81-8500-ed4c4c30ddb2@kernel.org>
Hi Krzysztof,
Thanks for pointing this out.
> > Add a dedicated rockchip,rk3588-canfd compatible to describe this
> > variant. Do not use rockchip,rk3568v2-canfd as a fallback, because that
> > would describe a register layout that does not match the hardware.
> >
> > Changes in v2:
>
> Changelog goes to changelog, so ---.
>
> See also submitting patches or just start using b4, which would solve
> also your broken threading problem.
>
I will move it below --- in v3. At the same time, I'll also spend some time
learning how to use b4, and will use b4 to send the next v3 submission.
Best regards,
Cunhao
^ permalink raw reply
* Re: [PATCH v7 0/9] dmaengine: Add new API to combine configuration and descriptor preparation
From: Vinod Koul @ 2026-07-02 15:26 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel, Frank.Li
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
On Thu, 21 May 2026 11:32:46 -0400, Frank.Li@oss.nxp.com wrote:
> Previously, configuration and preparation required two separate calls. This
> works well when configuration is done only once during initialization.
>
> However, in cases where the burst length or source/destination address must
> be adjusted for each transfer, calling two functions is verbose.
>
> if (dmaengine_slave_config(chan, &sconf)) {
> dev_err(dev, "DMA slave config fail\n");
> return -EIO;
> }
>
> [...]
Applied, thanks!
[1/9] dmaengine: Add API to combine configuration and preparation (sg and single)
commit: 796bdb33e86aec8504bf8868e0665f120638ac72
[2/9] dmaengine: Add safe API to combine configuration and preparation
commit: af900b7dc1e1cdac571ac38e7fee80f1a1776a62
[3/9] PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code
commit: 9605825841061bbdd2fc2a0218098373c539173e
[4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback
commit: bfb66d8098dbbaaada3ab877eda21cd447115c95
[5/9] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()
commit: 1af246e9d222f93aee59f3b47ff3bd59d08725e7
[6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer
commit: bd00d2c4a1b2a1e7ad3060d3d606fb4c9db6a064
[7/9] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
commit: a0fba0a49f77effd3962723b1fa14c766fbc0ec4
[8/9] PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code
commit: 53191cc449db1cf4f25db275978c61b1c6aaeba9
[9/9] crypto: atmel: Use dmaengine_prep_config_sg() API
commit: c9e9927c6d8346cdf6555a8f97da093980172e4b
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 1/6] arm64: make huge_ptep_get handled unaligned addresses
From: David Hildenbrand (Arm) @ 2026-07-02 15:28 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-2-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> huge_ptep_get() can be handed a virtual address pointing to the middle of
> a contpmd/contpte mapped hugetlb folio (examples of callers are
> pagemap_hugetlb_range, page_mapped_in_vma).
>
> The arm64 helper rewalks the pgtables in find_num_contig to answer whether
> the huge pte we have maps a contpmd or a contpte hugetlb folio, and
> returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the
> contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS
> if the addr is not aligned.
>
> Fix this by aligning the pmdp pointer down to a contpmd base before
> checking equality with the passed huge pte pointer, to correctly answer
> whether the huge pte is the base of a contpmd block.
>
> Fixes: 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> arch/arm64/mm/hugetlbpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 30772a909aea3..8e799c1fe0aa6 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -87,7 +87,7 @@ static int find_num_contig(struct mm_struct *mm, unsigned long addr,
> p4dp = p4d_offset(pgdp, addr);
> pudp = pud_offset(p4dp, addr);
> pmdp = pmd_offset(pudp, addr);
> - if ((pte_t *)pmdp == ptep) {
> + if ((pte_t *)PTR_ALIGN_DOWN(pmdp, sizeof(*pmdp) * CONT_PMDS) == ptep) {
> *pgsize = PMD_SIZE;
> return CONT_PMDS;
> }
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: David Hildenbrand (Arm) @ 2026-07-02 15:30 UTC (permalink / raw)
To: Muchun Song, Dev Jain
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable, osalvador, akpm, ljs, liam
In-Reply-To: <CE6E9F6C-8891-40E3-A5B7-BA475070EACD@linux.dev>
On 7/2/26 11:35, Muchun Song wrote:
>
>
>> On Jul 2, 2026, at 17:08, Dev Jain <dev.jain@arm.com> wrote:
>>
>>
>>
>> On 02/07/26 2:17 pm, Muchun Song wrote:
>>>
>>>
>>>
>>> Maybe I didn't express my thoughts clearly in the first version, let me
>>> explain in more detail.
>>>
>>> We should define this stub as a no-op for !CONFIG_HUGETLB_PAGE (like
>>> set_huge_pte_at, that is why I mentioned 5d4af6195c87c6 for your reference
>>> in your previous version). Currently, you've added a declaration, but the
>>> function itself doesn't actually exist, which seems quite strange to me.
>>
>> https://lore.kernel.org/all/a4fe8ba6-2ecd-4bb9-95a9-27f9f1e87d2e@kernel.org/
>>
>> David suggested this. Honestly I quite like David's suggestion, what do you
>> think?
>
> Thanks for pointing that out, I missed it earlier. That said, looking at
> hugetlb.h, it already contains quite a few no-op stubs. To keep things
> consistent, I'd personally prefer a stub here. Since David suggested this,
> I’d love to hear his thoughts on this as well.
It's the shortest possible way to enforce (through the linker!) that you
function is not called from wrong context.
The only alternative is using a stub with a BUILD_BUG() in it. Which will 4 5 LOC :)
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v8 00/39] Add HDMI 2.0 support to DW HDMI QP TX
From: Cristian Ciocaltea @ 2026-07-02 15:31 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
Dmitry Baryshkov, Diederik de Haas, Maud Spierings
In-Reply-To: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com>
Hi,
I've just realized I missed updating the part of the cover letter that
describes the patch structure. Please find the corrected content below.
Regards,
Cristian
On 7/2/26 5:46 PM, Cristian Ciocaltea wrote:
> Enable HDMI 2.0 display modes (e.g. 4K@60Hz) on the Synopsys DW HDMI QP
> TX controller, as found in Rockchip RK3576 & RK3588 SoCs, by adding SCDC
> management for high TMDS clock ratio and scrambling.
Since SCDC state is lost on sink disconnects, the bridge driver needs to
trigger a CRTC reset during connector detection. To support this, the
series first introduces the HDMI version enum and the caps-based HDMI
connector init helper (patches 1-3), then builds the connector and
bridge scrambling infrastructure on top of it - the connector scrambler
support, the scdc-helper additions (connector-prefixed debug macro and
SCDC version helper), and the HDMI scrambling management helpers
including SCDC source-version advertisement (patches 4-8).
It then wires this up through the hdmi-state-helper and bridge connector
layers: fallback TMDS rate validation, hotplug SCDC state sync and the
scrambling requirement (patches 9-11), a bridge cleanup and the new
source-side scrambling bridge ops (patches 12-13), the switch to a
cached-status, atomic-aware .detect_ctx() connector helper (patches
14-15), and finally hooking up the HDMI 2.0 scrambler callbacks (patch
16).
The SCDC scrambling feature itself is implemented in the DW HDMI QP
bridge driver, alongside i2c error-message rate limiting,
.enable_hpd()/.disable_hpd() PHY ops and a dw_hdmi_qp_hpd_notify()
helper (patches 17-20).
Patches 21-28 cover the Rockchip platform driver and HPD handling: minor
cleanups (newlines in dev_err_probe(), consistent local dev variable,
dropping an unnecessary include), deferring HPD IRQ enable until after
connector setup, masking the RK3576 HPD IRQ in io_init, implementing the
.{enable|disable}_hpd() PHY ops, switching HPD reports to
dw_hdmi_qp_hpd_notify() to restrict events to the affected connector,
and dropping the now-unused .setup_hpd() PHY op.
Patches 29-31 convert vc4 HDMI to the common infrastructure as a proof
of reuse: adopting the shared TMDS char rate constants, switching to
drm_hdmi_mode_needs_scrambling(), and replacing the driver-local
scrambling implementation with the common SCDC scrambling helpers.
Patches 32-39 add KUnit tests: HDMI caps-based init coverage and
source-side scrambler validation for the connector, conversion of
hdmi_state_helper to drmm_connector_hdmi_init_with_caps() with
max_tmds_char_rate fallback tests, a new 4K@60Hz 600MHz TMDS EDID,
source-side scrambling decision coverage, and conformity fixes for the
existing 1080p+4K YUV420 200MHz and 4K RGB/YUV 340MHz test EDID blobs.
>
> This has been tested on the following boards:
>
> * Radxa ROCK 5B (RK3588)
> * Radxa ROCK 4D (RK3576)
> * Raspberry Pi 5 Model B Rev 1.1 (BCM2712 D0)
>
> Note that commit d87773de9efe1 ("clocksource/drivers/arm_arch_timer:
> Default to EL2 virtual timer when running VHE"), introduced in v7.2-rc1,
> causes Raspberry Pi 5 to hang during boot. Reverting the commit
> restores normal boot. This issue has already been reported in [1];
> alternatively, the workaround proposed in [2] can be applied.
>
> Regards,
> Cristian
>
> [1] https://lore.kernel.org/all/ea15cce1-b393-43f6-8d58-3d6f90f0c0cd@samsung.com/
> [2] https://lore.kernel.org/all/20260619204832.586079-1-dan@reactivated.net/
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Changes in v8:
> - Added an enum hdmi_version under video/hdmi to describe the HDMI
> specification version a source/sink supports (new patch 1)
> - Introduced HDMI connector capabilities API and reworked the
> infrastructure patches on top of it: drmm_connector_hdmi_init() now
> takes a drm_connector_hdmi_caps struct that carries supported_formats,
> max_bpc, supported_hdmi_ver and max_tmds_char_rate (new patches 2-3)
> - Moved all the new SCDC helpers covering both source and sink to
> display/drm_hdmi_helper.c
> - Renamed drm_scdc_{start,stop}_scrambling() to
> drm_connector_hdmi_{enable,disable}_scrambling() and added a
> connector-state argument so the scrambler_needed flag is checked
> centrally instead of in every driver
> - Renamed drm_scdc_sync_status() to drm_connector_hdmi_sync_scdc(),
> aligned its lifecycle with vc4_hdmi_reset_link(), and removed the
> internal drm_scdc_reset_crtc() helper; it now also gates on CRTC state
> and an in-flight commit (Maxime)
> - Changed the prototype of drm_atomic_helper_connector_hdmi_hotplug() to
> take an acquire context and an int return, instead of adding a new
> _ctx variant (Maxime)
> - Added drm_hdmi_mode_needs_scrambling() to centralise the above-340 MHz
> decision (new patch 7)
> - Made SCDC source version negotiation optional and moved it to a
> dedicated patch "drm/display: hdmi: Advertise SCDC source version when
> scrambling" (new patch 8), backed by a new
> drm_scdc_set_source_version() helper in "drm/display: scdc-helper: Add
> helper to set SCDC version information" (new patch 6)
> - Added a fallback TMDS rate validation patch using the connector-level
> max_tmds_char_rate when the driver provides no .tmds_char_rate_valid()
> hook (new patch 9)
> - Split scrambler_needed flag handling into its own hdmi-state-helper
> dedicate change (new patch 11)
> - VC4:
> * Replaced vc4_hdmi_mode_needs_scrambling() with
> drm_hdmi_mode_needs_scrambling() (new patch 30)
> * Restored drm_dev_{enter,exit}() pairing around the converted
> scrambling paths
> * Removed now unused output_{bpc,color_format} fields from vc4_hdmi as
> part of the SCDC conversion
> - KUnit:
> * Covered the caps-based connector init path: NULL caps, inferred
> max_tmds_char_rate per supported_hdmi_ver, and override validation
> (new patch 32)
> * Switched drm_hdmi_state_helper_test to the caps-based init helper
> and exposed it through
> drm_kunit_helper_connector_hdmi_init_with_caps_edid_funcs() (new
> patch 34)
> * Added max_tmds_char_rate fallback coverage in
> drm_hdmi_state_helper_test (new patch 35)
> - Rebased onto latest drm-misc-next and dropped the already applied
> "drm/fb-helper: Remove unused local variable in hotplug_event()" patch
> - Link to v7: https://patch.msgid.link/20260602-dw-hdmi-qp-scramb-v7-0-445eb54ee1ed@collabora.com
[...]
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: xlnx,axi-dma: Restore xlnx,flush-fsync as u32
From: Vinod Koul @ 2026-07-02 15:31 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, michal.simek,
radhey.shyam.pandey, Suraj Gupta
Cc: dmaengine, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260625161016.1249570-1-suraj.gupta2@amd.com>
On Thu, 25 Jun 2026 21:40:16 +0530, Suraj Gupta wrote:
> The DT schema conversion incorrectly changed xlnx,flush-fsync from a u32
> property to a boolean. The original binding documented values 1, 2, and 3
> to select which VDMA channel(s) flush on frame sync.
> Restore the uint32 type with the documented enum values and fix the
> example accordingly.
>
>
> [...]
Applied, thanks!
[1/1] dt-bindings: dma: xlnx,axi-dma: Restore xlnx,flush-fsync as u32
commit: 287bdea77529e6abac5fe15461d93c1acdcb07e9
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: xilinx: Fix "xlnx,irq-delay" type
From: Vinod Koul @ 2026-07-02 15:32 UTC (permalink / raw)
To: Frank Li, Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Shyam Pandey, Abin Joseph, Rob Herring (Arm)
Cc: dmaengine, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260612215226.1887726-1-robh@kernel.org>
On Fri, 12 Jun 2026 16:52:25 -0500, Rob Herring (Arm) wrote:
> "xlnx,irq-delay" programs an 8-bit delay field in the DMA control
> register, and the driver stores and reads it as a byte. The binding
> described the property as a uint32 cell, which made the helper type
> check report the driver as wrong.
>
> Document "xlnx,irq-delay" as uint8 so the generated schema reflects
> the hardware field width and the existing driver access.
>
> [...]
Applied, thanks!
[1/1] dt-bindings: dma: xilinx: Fix "xlnx,irq-delay" type
commit: fa9cb11584851414b25fd8bf9f59518424b5917c
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation failure
From: Vinod Koul @ 2026-07-02 15:32 UTC (permalink / raw)
To: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno, Frank Li,
Vladimir Zapolskiy
Cc: Long Cheng, dmaengine, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260701200703.117929-1-vz@kernel.org>
On Wed, 01 Jul 2026 23:07:03 +0300, Vladimir Zapolskiy wrote:
> If dynamic memory allocation in driver's probe function execution fails, it
> should be reported to the driver's framework with -ENOMEM error code.
>
>
Applied, thanks!
[1/1] dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation failure
commit: 467265c750edd7ab43803deeafe7d3120a791d32
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: mediatek,uart-dma: add support for MT8189 SoC
From: Vinod Koul @ 2026-07-02 15:32 UTC (permalink / raw)
To: Sean Wang, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Long Cheng, Louis-Alexis Eyraud
Cc: kernel, dmaengine, linux-arm-kernel, linux-mediatek, devicetree,
linux-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-uart-dma-v1-1-c7106216a40d@collabora.com>
On Wed, 01 Jul 2026 17:47:20 +0200, Louis-Alexis Eyraud wrote:
> Add the compatible string for the APDMA IP found in MT8189 SoC,
> that supports 35-bits addressing as MT6985 SoC.
>
>
Applied, thanks!
[1/1] dt-bindings: dma: mediatek,uart-dma: add support for MT8189 SoC
commit: 0d2b094b1c10be619a63f53a610587bcabbee06b
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: David Hildenbrand (Arm) @ 2026-07-02 15:32 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-3-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> try_to_unmap_one() handles hugetlb folios when memory failure needs
> to replace a poisoned hugetlb mapping with a hwpoison entry. In that
> case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio
> in pvmw.pte, but the code reads it with ptep_get().
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
> etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
>
> Just use huge_ptep_get() for dereferencing a huge pte pointer.
>
> Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")
> Cc: stable@vger.kernel.org
> Reported-by: David Hildenbrand <david@kernel.org>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> include/linux/hugetlb.h | 3 +++
> mm/rmap.c | 16 ++++++++++------
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 2abaf99321e90..fdb7bdf7645c5 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
> {
> }
>
> +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
> + pte_t *ptep);
Two tabs, or just in a single line.
If others prefer a stub, I don't care. This here is shortest to let the linker
bail out.
> +
> static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep)
> {
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 1c77d5dc06e9f..aa8a254efaecc 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
> /* Unexpected PMD-mapped THP? */
> VM_BUG_ON_FOLIO(!pvmw.pte, folio);
>
> - /*
> - * Handle PFN swap PTEs, such as device-exclusive ones, that
> - * actually map pages.
> - */
That comment now actually belongs above the pte_present() check below.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v4] KVM: arm64: Record whether pKVM stage 2 mapping is cacheable
From: Marc Zyngier @ 2026-07-02 15:34 UTC (permalink / raw)
To: Bradley Morgan
Cc: Leonardo Bras, Oliver Upton, Fuad Tabba, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon, Quentin Perret, Vincent Donnefort, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <6495D546-8FC7-4A31-B18C-88F34E1B64BB@grrlz.net>
On Thu, 02 Jul 2026 15:52:14 +0100,
Bradley Morgan <include@grrlz.net> wrote:
>
> I'll test it. If it's good. I'll do
>
> Suggested-by? Or co-developed by?
Sb if you want, definitely not Cdb. More importantly, I expect to you
to follow the process described at [1]. Nothing there is optional.
Thanks,
M.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 3/6] mm/rmap: use huge_ptep_get() in try_to_migrate_one()
From: David Hildenbrand (Arm) @ 2026-07-02 15:34 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-4-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> try_to_migrate_one() is used by folio migration to replace a present
> mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk()
> returns the pte pointer to the hugetlb folio in pvmw.pte, but the code
> reads the huge pte entry with ptep_get().
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
> etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
>
> Use huge_ptep_get() to dereference a huge pte pointer.
>
> Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into
> try_to_migrate_one.
>
> Fixes: a98a2f0c8ce1 ("mm/rmap: split migration into its own function")
> Cc: stable@vger.kernel.org
> Acked-by: Muchun Song <muchun.song@linux.dev>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> mm/rmap.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index aa8a254efaecc..abc3a44baaa3d 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -2505,11 +2505,16 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
> /* Unexpected PMD-mapped THP? */
> VM_BUG_ON_FOLIO(!pvmw.pte, folio);
>
> - /*
> - * Handle PFN swap PTEs, such as device-exclusive ones, that
> - * actually map pages.
> - */
> - pteval = ptep_get(pvmw.pte);
> + address = pvmw.address;
> + if (folio_test_hugetlb(folio)) {
> + pteval = huge_ptep_get(mm, address, pvmw.pte);
> + } else {
> + /*
> + * Handle PFN swap PTEs, such as device-exclusive ones,
> + * that actually map pages.
> + */
Again, the comment is related to the pte_present() handling, so best to move it
down there.
Apart from that LGTM.
--
Cheers,
David
^ permalink raw reply
* [PATCH v8 04/39] drm/connector: Add HDMI 2.0 scrambler infrastructure
From: Cristian Ciocaltea @ 2026-07-02 14:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com>
Add the connector-level infrastructure to support HDMI 2.0 scrambling:
- A scrambler_supported flag to indicate whether the source supports the
scrambling capability, in which case the newly introduced
.scrambler_{enable|disable}() callbacks in drm_connector_hdmi_funcs
are mandatory
- A scrambler_needed flag to be managed by the hdmi state helpers based
on the negotiated TMDS character rate and the source/sink scrambling
capabilities
- A scrambler_enabled flag to track whether scrambling is currently
active
- A delayed work item (scdc_work) with an associated callback (scdc_cb)
to monitor sink-side scrambling status and retry the setup if the sink
resets it
These are intended to be used by SCDC scrambling helpers to coordinate
scrambling setup and teardown between the source driver and the DRM
core.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/drm_connector.c | 26 ++++++++++++--
include/drm/drm_connector.h | 77 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 100 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index c7ce6b7bd8b0..deecfc582f09 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -220,6 +220,19 @@ void drm_connector_free_work_fn(struct work_struct *work)
}
}
+static void drm_connector_hdmi_scdc_work(struct work_struct *work)
+{
+ struct drm_connector *connector;
+ struct drm_connector_hdmi *hdmi;
+
+ hdmi = container_of(to_delayed_work(work), struct drm_connector_hdmi,
+ scdc_work);
+ connector = container_of(hdmi, struct drm_connector, hdmi);
+
+ if (hdmi->scdc_cb)
+ hdmi->scdc_cb(connector);
+}
+
static int drm_connector_init_only(struct drm_device *dev,
struct drm_connector *connector,
const struct drm_connector_funcs *funcs,
@@ -285,6 +298,7 @@ static int drm_connector_init_only(struct drm_device *dev,
mutex_init(&connector->edid_override_mutex);
mutex_init(&connector->hdmi.infoframes.lock);
mutex_init(&connector->hdmi_audio.lock);
+ INIT_DELAYED_WORK(&connector->hdmi.scdc_work, drm_connector_hdmi_scdc_work);
connector->edid_blob_ptr = NULL;
connector->epoch_counter = 0;
connector->tile_blob_ptr = NULL;
@@ -624,12 +638,18 @@ int drmm_connector_hdmi_init_with_caps(struct drm_device *dev,
* inferred limit with the actual controller capability. A value of
* zero keeps the default limit inferred from supported_hdmi_ver.
*/
- if (caps->supported_hdmi_ver >= HDMI_VERSION_2_0)
+ if (caps->supported_hdmi_ver >= HDMI_VERSION_2_0) {
+ if (!hdmi_funcs->scrambler_enable ||
+ !hdmi_funcs->scrambler_disable)
+ return -EINVAL;
+
+ connector->hdmi.scrambler_supported = true;
connector->hdmi.max_tmds_char_rate = HDMI_2_0_TMDS_CHAR_RATE_MAX_HZ;
- else if (caps->supported_hdmi_ver >= HDMI_VERSION_1_3)
+ } else if (caps->supported_hdmi_ver >= HDMI_VERSION_1_3) {
connector->hdmi.max_tmds_char_rate = HDMI_1_3_TMDS_CHAR_RATE_MAX_HZ;
- else if (caps->supported_hdmi_ver >= HDMI_VERSION_1_0)
+ } else if (caps->supported_hdmi_ver >= HDMI_VERSION_1_0) {
connector->hdmi.max_tmds_char_rate = HDMI_1_0_TMDS_CHAR_RATE_MAX_HZ;
+ }
if (caps->max_tmds_char_rate) {
if (caps->max_tmds_char_rate > connector->hdmi.max_tmds_char_rate)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 961a729d0869..c70b57963f28 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -28,6 +28,7 @@
#include <linux/ctype.h>
#include <linux/hdmi.h>
#include <linux/notifier.h>
+#include <linux/workqueue.h>
#include <drm/drm_mode_object.h>
#include <drm/drm_util.h>
#include <drm/drm_property.h>
@@ -1131,6 +1132,19 @@ struct drm_connector_hdmi_state {
* @tmds_char_rate: TMDS Character Rate, in Hz.
*/
unsigned long long tmds_char_rate;
+
+ /**
+ * @scrambler_needed: Whether HDMI 2.0 SCDC scrambling is required
+ * for the negotiated mode/bpc/format.
+ *
+ * Computed by drm_atomic_helper_connector_hdmi_check() from
+ * @tmds_char_rate and the source/sink scrambling capabilities.
+ *
+ * Per HDMI 2.0, scrambling is mandatory above 340 MHz TMDS
+ * character rate. Optional scrambling at lower rates is
+ * deliberately not requested by the helper.
+ */
+ bool scrambler_needed;
};
/**
@@ -1439,6 +1453,36 @@ struct drm_connector_hdmi_funcs {
*/
const struct drm_edid *(*read_edid)(struct drm_connector *connector);
+ /**
+ * @scrambler_enable:
+ *
+ * The callback is invoked via @drm_connector_hdmi_enable_scrambling
+ * during commit to setup SCDC scrambling and high TMDS clock ratio on
+ * the source side.
+ *
+ * The @scrambler_enable callback is mandatory if HDMI 2.0 is to be
+ * supported.
+ *
+ * Returns:
+ * 0 on success, a negative error code otherwise
+ */
+ int (*scrambler_enable)(struct drm_connector *connector);
+
+ /**
+ * @scrambler_disable:
+ *
+ * The callback is invoked via @drm_connector_hdmi_disable_scrambling
+ * during commit to tear down SCDC scrambling and high TMDS clock ratio
+ * on the source side.
+ *
+ * The @scrambler_disable callback is mandatory if HDMI 2.0 is to be
+ * supported.
+ *
+ * Returns:
+ * 0 on success, a negative error code otherwise
+ */
+ int (*scrambler_disable)(struct drm_connector *connector);
+
/**
* @avi:
*
@@ -2098,6 +2142,39 @@ struct drm_connector_hdmi {
*/
unsigned long long max_tmds_char_rate;
+ /**
+ * @scrambler_supported: Indicates whether the HDMI controller
+ * (source) supports HDMI 2.0 SCDC scrambling.
+ *
+ * This is set by the HDMI connector init helpers if the provided
+ * capabilities advertise HDMI_VERSION_2_0 support.
+ *
+ * When true, @drm_connector_hdmi_funcs.scrambler_enable and
+ * @drm_connector_hdmi_funcs.scrambler_disable are mandatory.
+ */
+ bool scrambler_supported;
+
+ /**
+ * @scrambler_enabled: Tracks whether HDMI 2.0 scrambler is currently enabled.
+ */
+ bool scrambler_enabled;
+
+ /**
+ * @scdc_work: Work item currently used to monitor sink-side scrambling
+ * status and retry setup if the sink resets it.
+ */
+ struct delayed_work scdc_work;
+
+ /** @scdc_cb: Callback to be invoked as part of @scdc_work.
+ *
+ * Currently used to monitor sink-side scrambling status and retry
+ * setup if the sink resets it.
+ *
+ * This is assigned by the framework when making use of
+ * drm_connector_hdmi_enable_scrambling() helper.
+ */
+ void (*scdc_cb)(struct drm_connector *connector);
+
/**
* @funcs: HDMI connector Control Functions
*/
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: Sort registers in cpu-feature-registers.rst
From: Mark Brown @ 2026-07-02 15:38 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, Peter Maydell,
Joey Gouly, linux-arm-kernel, linux-doc, linux-kernel
In-Reply-To: <akaCJvZkdqigcQUZ@arm.com>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
On Thu, Jul 02, 2026 at 04:22:14PM +0100, Catalin Marinas wrote:
> The patch is fine but I just realised that we are really inconsistent
> with the non-visible things. We exposed a few hear, I guess in the early
> days, and then we stopped, just adding the occasional visible fields.
> Shall we drop the 'visible' column altogether and only document the
> visible fields here?
Yeah, I was struggling to understand the logic and would certainly
prefer to not have to type in every single bitfield in yet another
location. I'll add a patch on top that does as you suggest, see if
anyone objects.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu-v3: Shrink command/event/PRI queues in kdump kernel
From: Kiryl Shutsemau @ 2026-07-02 15:38 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Jason Gunthorpe,
Nicolin Chen, Kyle McMartin, Breno Leitao, Usama Arif,
linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <akZ-KIVJlmP4LEcQ@google.com>
On Thu, Jul 02, 2026 at 03:05:12PM +0000, Pranjal Shrivastava wrote:
> On Thu, Jul 02, 2026 at 12:28:25PM +0100, Kiryl Shutsemau (Meta) wrote:
> > The command, event and PRI queues are sized from the maxima the hardware
>
> A minor note here is PRI & EVT queues are disabled for the kdump kernel
> (see arm_smmu_device_reset). We could just mention all SMMU queues are
> sized [...] in the commit message.
Fair enough.
Here's updated commit message (I will send v3 in few days, if no new
feedback):
Subject: [PATCH v3] iommu/arm-smmu-v3: Shrink command/event/PRI queues in
kdump kernel
All SMMU queues are sized from the maxima the hardware advertises in IDR1,
which can be several megabytes each, and are allocated at probe. The kdump
kernel already disables the event and PRI queues (arm_smmu_device_reset()
drops CR0_EVTQEN/CR0_PRIQEN) but still allocates them at full size. On
systems with many SMMUv3 instances that cost is paid per instance and adds
up to tens of megabytes of coherent DMA in the capture kernel.
A kdump capture kernel runs from a small crashkernel reservation and only
has to drive the few devices used to save the dump, so deep queues serve
no purpose. The queues are not on the DMA data path, so dump throughput is
unaffected; a shallower command queue only bounds how many commands may be
in flight before a sync, which does not matter for the capture kernel's
small device count and modest I/O.
Clamp every queue to a single page when is_kdump_kernel() is true. Doing
it in arm_smmu_init_one_queue() covers the command, event and PRI queues
in one place. The command queue still holds at least one batch plus a sync
(256 entries on a 4K-page kernel, well above CMDQ_BATCH_ENTRIES), so
command batching keeps working.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v2 4/6] mm/migrate: use huge_ptep_get() in remove_migration_pte()
From: David Hildenbrand (Arm) @ 2026-07-02 15:44 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-5-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> remove_migration_pte() converts migration entries back to present PTEs
> after folio migration completes. For hugetlb folios,
> page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in
> pvmw.pte, but the code reads it with ptep_get().
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(),
> pte_present() etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
Right, for non-present entries it's even weirder. Fortunately your patch #1 also
handles that.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 5/6] mm/page_vma_mapped: use huge_ptep_get() for hugetlb
From: David Hildenbrand (Arm) @ 2026-07-02 15:44 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-6-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> check_pte() is the final validation step in page_vma_mapped_walk().
> It reads pvmw->pte with ptep_get() to decide whether the entry maps
> the PFN range being walked. For hugetlb VMAs, that pointer refers
> to a hugetlb entry.
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(),
> pte_present() etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
>
> Use huge_ptep_get() to dereference a huge pte pointer.
>
> Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH RFC 0/8] clk: sunxi-ng: Add support for Allwinner A733 CCU and PRCM
From: Junhui Liu @ 2026-07-02 15:44 UTC (permalink / raw)
To: Enzo Adriano, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Andre Przywara, Jerome Brunet,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Richard Cochran, linux-clk, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, netdev
In-Reply-To: <20260701160055.320000-a733-ccu-status-enzo.adriano.code@gmail.com>
Hi Enzo,
On Thu Jul 2, 2026 at 12:07 AM CST, Enzo Adriano wrote:
> Hi Junhui,
>
> Thanks for the A733 CCU/PRCM RFC v1. I've been reading through the
> series and the review feedback, including the NSI clock/reset handling,
> the binding naming and ordering comments, the SDM macro cleanup, and the
> question around modeled but otherwise-unused clocks such as the GIC clock.
>
> I do not see a v2 on the list yet, so I wanted to check in: are you still
> planning to take this series forward? No rush at all, and I am happy to
> leave it entirely with you if so.
>
> If you have moved on to other things, I would be glad to help carry the
> series forward and address the review comments, keeping your authorship
> and prior work intact. I have A733 hardware here and can help test the
> changes.
>
> Either way, please let me know what works best for you.
Thanks for reaching out. I have already been preparing a v2 based on
Jerome's new RTC patch series. I moved to a new city this week though,
so there may be some delay, but I will try to get it out as soon as
possible.
>
> Thanks,
> Enzo
--
Best regards,
Junhui Liu
^ permalink raw reply
* [GIT PULL] Reset controller fixes for v7.2
From: Philipp Zabel @ 2026-07-02 15:46 UTC (permalink / raw)
To: soc; +Cc: linux-arm-kernel, kernel, Philipp Zabel
Dear arm-soc maintainers,
The following changes since commit dc59e4fea9d83f03bad6bddf3fa2e52491777482:
Linux 7.2-rc1 (2026-06-28 12:01:31 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pza/linux.git tags/reset-fixes-for-v7.2
for you to fetch changes up to 71827776667f4e4677a4fa806bcfb24d4b8dd9d7:
reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ (2026-07-01 15:08:14 +0200)
----------------------------------------------------------------
Reset controller fixes for v7.2
* Fix the SpacemiT K3 USB2 AHB reset bit location.
* Add missing COMBOPHY_RESET definition for Altera Agilex5.
* Fix the reset-sunxi initialization error path to release the
requested memory region.
* Correct polarity of MIPI CSI resets on NXP i.MX8MQ. The corresponding
fix in the CSI2 driver, 6d79bb8fd2aa, is already contained in v7.2-rc1.
----------------------------------------------------------------
Robby Cai (1):
reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ
Tanmay Kathpalia (1):
dt-bindings: reset: altr: add COMBOPHY_RESET for Agilex5
Yixun Lan (1):
reset: spacemit: k3: fix USB2 ahb reset
Zhao Dongdong (1):
reset: sunxi: fix memory region leak on ioremap failure
drivers/reset/reset-imx7.c | 6 ++++++
drivers/reset/reset-sunxi.c | 4 +++-
drivers/reset/spacemit/reset-spacemit-k3.c | 2 +-
include/dt-bindings/reset/altr,rst-mgr-s10.h | 2 +-
4 files changed, 11 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH v4 5/5] arm64: mpam: Add memory bandwidth usage (MBWU) documentation
From: Fenghua Yu @ 2026-07-02 15:46 UTC (permalink / raw)
To: Ben Horgan, Reinette Chatre
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, rohit.mathew, scott, sdonthineni, tan.shaopeng, xhao,
zengheng4, x86
In-Reply-To: <5bba66e2-f671-4bdb-a2e5-f2cf9fb1f9f4@arm.com>
Hi, Ben,
On 7/2/26 07:58, Ben Horgan wrote:
> Hi Reinette,
>
> On 7/2/26 15:46, Reinette Chatre wrote:
>> Hi Ben,
>>
>> On 7/2/26 2:20 AM, Ben Horgan wrote:
>>> On 7/1/26 23:38, Reinette Chatre wrote:
>>>> On 5/20/26 2:24 PM, Ben Horgan wrote:
>>
>> ...
>>
>>>>> --- a/Documentation/arch/arm64/mpam.rst
>>>>> +++ b/Documentation/arch/arm64/mpam.rst
>>>>> @@ -65,6 +65,23 @@ The supported features are:
>>>>> there is at least one CSU monitor on each MSC that makes up the L3 group.
>>>>> Exposing CSU counters from other caches or devices is not supported.
>>>>>
>>>>> +* Memory Bandwidth Usage (MBWU) on or after the L3 cache. resctrl uses the
>>>>> + L3 cache-id to identify where the memory bandwidth is measured. For this
>>>>> + reason the platform must have an L3 cache with cache-id's supplied by
>>>>> + firmware. (It doesn't need to support MPAM.)
s/It/The platform/?
>>>>> +
>>>>> + Memory bandwidth monitoring makes use of MBWU monitors in each MSC that
>>>>> + makes up the L3 group. If the memory bandwidth monitoring is on the memory
>>>>> + rather than the L3 then there must be a single global L3 as otherwise it
s/a single global L3/a single global L3 cache id/?
>>>>> + is unknown which L3 the traffic came from.
>>>>> +
>>>>> + To expose 'mbm_total_bytes', the topology of the group of MSC chosen must
>>>>> + match the topology of the L3 cache so that the cache-id's can be
>>>>> + repainted. For example: Platforms with Memory bandwidth monitors on
>>>>> + CPU-less NUMA nodes cannot expose 'mbm_total_bytes' as these nodes do not
>>>>> + have a corresponding L3 cache. 'mbm_local_bytes' is not exposed as MPAM
Maybe remove the CPU-less example here since you will add CPU-less info
later?
The CPU-less patches will update this document accordingly.
>>>>> + cannot distinguish local traffic from global traffic.
>>>>
>>>> Hopefully we can get to a point where memory bandwidth monitoring data from
>>>> CPU-less NUMA nodes can be exposed via resctrl. When considering such possible
>>>
>>> Thank you for your interest here. I hope so too.
>>>
>>>> future I think it may make this work easier to build on if the documentation
>>>> focuses on what the current implementation supports and leave room for
>>>> future enhancements by not constraining user space expectation with an absolute
>>>> like "CPU-less NUMA nodes cannot expose 'mbm_total_bytes'".
>>>
>>> The intention was to describe the current limitations but I do see how
>>> this can come across as fundamental problems rather than just that we
>>> need to do some more work to establish how this can be done and
>>> implement it.
>>>
>>> How about if I add this paragraph at the end?
>>>
>>> All these restrictions based on L3 cache are due to resctrl, currently,
>>> only supporting monitoring at the scope of the L3 scope. It is expected
>>
>> How about "at L3 scope" instead of "at the scope of the L3 scope"?
>
> Sure, that reads better.
>
> Ben
>
>>
>>> that going forward more MBWU monitors can be exposed to the user after
>>> support for more monitoring scopes is added to resctrl.
>> Looks good to me, thank you.
>>
>> Reinette
>
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH] mfd: db8500-prcmu: Fold dbx500 header into db8500
From: Lee Jones @ 2026-07-02 15:47 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Ulf Hansson, Michael Turquette, Stephen Boyd,
Brian Masney, Rafael J. Wysocki, Daniel Lezcano, Christian Loehle,
Liam Girdwood, Mark Brown, Zhang Rui, Lukasz Luba,
Wim Van Sebroeck, Guenter Roeck, Jaroslav Kysela, Takashi Iwai,
linux-arm-kernel, linux-clk, linux-pm, linux-watchdog,
linux-sound, kernel test robot
In-Reply-To: <20260619-mfd-prcmu-merge-headers-v1-1-8ea0ee23b4d6@kernel.org>
I won't hold you to these for this submission, but they're probably
worth looking at:
/* Sashiko Automation: Reviewed (4 Findings) */
On Fri, 19 Jun 2026, Linus Walleij wrote:
> Move the DBx500 PRCMU definitions into the DB8500 PRCMU
> header and delete the wrapper header.
>
> Convert users of simple PRCMU wrappers to call the DB8500 helpers
> directly.
>
> The dbx500-prcmu.h header was the result of an earlier attempt to
> abstract several DBx5x SoC PRCMU units to use the same abstract
> header. They are deleted from the kernel and this is not just
> causing maintenance burden and build errors.
>
> The stub code is using -ENOSYS in a way checkpatch complains about
> so replace these with -EINVAL while we're at it.
>
> Assisted-by: Codex:gpt-5-5
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> ---
> arch/arm/mach-ux500/cpu-db8500.c | 6 +-
> drivers/clk/ux500/clk-prcmu.c | 20 +-
> drivers/clk/ux500/u8500_of_clk.c | 2 +-
> drivers/cpuidle/cpuidle-ux500.c | 6 +-
> drivers/mfd/ab8500-core.c | 2 +-
> drivers/mfd/db8500-prcmu.c | 6 +-
> drivers/regulator/db8500-prcmu.c | 12 +-
> drivers/thermal/db8500_thermal.c | 10 +-
> drivers/watchdog/db8500_wdt.c | 22 +-
> include/linux/mfd/db8500-prcmu.h | 252 ++++++++++++++++-
> include/linux/mfd/dbx500-prcmu.h | 575 ---------------------------------------
> sound/soc/ux500/ux500_msp_dai.c | 2 +-
> 12 files changed, 294 insertions(+), 621 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
> index b1a70f203372..0d7530fb6ad0 100644
> --- a/arch/arm/mach-ux500/cpu-db8500.c
> +++ b/arch/arm/mach-ux500/cpu-db8500.c
> @@ -12,7 +12,7 @@
> #include <linux/irq.h>
> #include <linux/irqchip.h>
> #include <linux/irqchip/arm-gic.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
> #include <linux/platform_data/arm-ux500-pm.h>
> #include <linux/platform_device.h>
> #include <linux/io.h>
> @@ -81,7 +81,7 @@ static void __init ux500_init_irq(void)
> struct resource r;
>
> irqchip_init();
> - prcmu_early_init();
> + db8500_prcmu_early_init();
> np = of_find_compatible_node(NULL, NULL, "stericsson,db8500-prcmu");
> of_address_to_resource(np, 0, &r);
> of_node_put(np);
[Severity: High]
This isn't a bug introduced by this patch, but does this code use an
uninitialized resource if of_address_to_resource() fails?
In ux500_init_irq(), struct resource r is declared on the stack without
initialization. If of_address_to_resource() returns an error (for example, if
the device tree node is missing a reg property), it does not populate r.
The return value of of_address_to_resource() is ignored, and the code later
checks:
if (!r.start) {
Because r.start contains uninitialized stack memory, could it evaluate to a
non-zero value, causing the kernel to call ux500_pm_init() with garbage
physical memory addresses?
> @@ -101,7 +101,7 @@ static void ux500_restart(enum reboot_mode mode, const char *cmd)
> local_irq_disable();
> local_fiq_disable();
>
> - prcmu_system_reset(0);
> + db8500_prcmu_system_reset(0);
> }
>
> static const struct of_device_id u8500_local_bus_nodes[] = {
> diff --git a/drivers/clk/ux500/clk-prcmu.c b/drivers/clk/ux500/clk-prcmu.c
> index ddc86551bf57..ac96c46bd1bb 100644
> --- a/drivers/clk/ux500/clk-prcmu.c
> +++ b/drivers/clk/ux500/clk-prcmu.c
> @@ -7,7 +7,7 @@
> */
>
> #include <linux/clk-provider.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
> #include <linux/slab.h>
> #include <linux/io.h>
> #include <linux/err.h>
> @@ -35,13 +35,13 @@ static int clk_prcmu_prepare(struct clk_hw *hw)
> {
> struct clk_prcmu *clk = to_clk_prcmu(hw);
>
> - return prcmu_request_clock(clk->cg_sel, true);
> + return db8500_prcmu_request_clock(clk->cg_sel, true);
> }
>
> static void clk_prcmu_unprepare(struct clk_hw *hw)
> {
> struct clk_prcmu *clk = to_clk_prcmu(hw);
> - if (prcmu_request_clock(clk->cg_sel, false))
> + if (db8500_prcmu_request_clock(clk->cg_sel, false))
> pr_err("clk_prcmu: %s failed to disable %s.\n", __func__,
> clk_hw_get_name(hw));
> }
> @@ -86,7 +86,7 @@ static int clk_prcmu_opp_prepare(struct clk_hw *hw)
> clk->opp_requested = 1;
> }
>
> - err = prcmu_request_clock(clk->cg_sel, true);
> + err = db8500_prcmu_request_clock(clk->cg_sel, true);
> if (err) {
> prcmu_qos_remove_requirement(PRCMU_QOS_APE_OPP,
> (char *)clk_hw_get_name(hw));
> @@ -101,7 +101,7 @@ static void clk_prcmu_opp_unprepare(struct clk_hw *hw)
> {
> struct clk_prcmu *clk = to_clk_prcmu(hw);
>
> - if (prcmu_request_clock(clk->cg_sel, false)) {
> + if (db8500_prcmu_request_clock(clk->cg_sel, false)) {
> pr_err("clk_prcmu: %s failed to disable %s.\n", __func__,
> clk_hw_get_name(hw));
> return;
> @@ -120,7 +120,7 @@ static int clk_prcmu_opp_volt_prepare(struct clk_hw *hw)
> struct clk_prcmu *clk = to_clk_prcmu(hw);
>
> if (!clk->opp_requested) {
> - err = prcmu_request_ape_opp_100_voltage(true);
> + err = db8500_prcmu_request_ape_opp_100_voltage(true);
[Severity: High]
This is a pre-existing issue, but does db8500_prcmu_request_ape_opp_100_voltage()
fail to rollback the requests counter on error?
When enable is true and requests is 0, the static requests counter is
incremented to 1 before sending the hardware mailbox request:
drivers/mfd/db8500-prcmu.c:db8500_prcmu_request_ape_opp_100_voltage() {
if (enable) {
if (0 != requests++)
goto unlock_and_return;
...
if ((mb1_transfer.ack.header != header) ||
((mb1_transfer.ack.ape_voltage_status & BIT(0)) != 0))
r = -EIO;
unlock_and_return:
If the hardware responds with an error, the function returns -EIO but appears
to fail to decrement the requests counter back to 0.
> if (err) {
> pr_err("clk_prcmu: %s fail req APE OPP VOLT for %s.\n",
> __func__, clk_hw_get_name(hw));
> @@ -129,9 +129,9 @@ static int clk_prcmu_opp_volt_prepare(struct clk_hw *hw)
> clk->opp_requested = 1;
> }
>
> - err = prcmu_request_clock(clk->cg_sel, true);
> + err = db8500_prcmu_request_clock(clk->cg_sel, true);
> if (err) {
> - prcmu_request_ape_opp_100_voltage(false);
> + db8500_prcmu_request_ape_opp_100_voltage(false);
> clk->opp_requested = 0;
> return err;
> }
> @@ -143,14 +143,14 @@ static void clk_prcmu_opp_volt_unprepare(struct clk_hw *hw)
> {
> struct clk_prcmu *clk = to_clk_prcmu(hw);
>
> - if (prcmu_request_clock(clk->cg_sel, false)) {
> + if (db8500_prcmu_request_clock(clk->cg_sel, false)) {
> pr_err("clk_prcmu: %s failed to disable %s.\n", __func__,
> clk_hw_get_name(hw));
> return;
> }
>
> if (clk->opp_requested) {
> - prcmu_request_ape_opp_100_voltage(false);
> + db8500_prcmu_request_ape_opp_100_voltage(false);
> clk->opp_requested = 0;
> }
> }
> diff --git a/drivers/clk/ux500/u8500_of_clk.c b/drivers/clk/ux500/u8500_of_clk.c
> index 6f78808387b1..d2499815226f 100644
> --- a/drivers/clk/ux500/u8500_of_clk.c
> +++ b/drivers/clk/ux500/u8500_of_clk.c
> @@ -9,7 +9,7 @@
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/clk-provider.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
>
> #include "clk.h"
> #include "prcc.h"
> diff --git a/drivers/cpuidle/cpuidle-ux500.c b/drivers/cpuidle/cpuidle-ux500.c
> index f7d778580e9b..6d6c52c0bcc2 100644
> --- a/drivers/cpuidle/cpuidle-ux500.c
> +++ b/drivers/cpuidle/cpuidle-ux500.c
> @@ -11,7 +11,7 @@
> #include <linux/spinlock.h>
> #include <linux/atomic.h>
> #include <linux/smp.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
> #include <linux/platform_data/arm-ux500-pm.h>
> #include <linux/platform_device.h>
>
> @@ -66,7 +66,7 @@ static inline int ux500_enter_idle(struct cpuidle_device *dev,
> /* Go to the retention state, the prcmu will wait for the
> * cpu to go WFI and this is what happens after exiting this
> * 'master' critical section */
> - if (prcmu_set_power_state(PRCMU_AP_IDLE, true, true))
> + if (db8500_prcmu_set_power_state(PRCMU_AP_IDLE, true, true))
> goto out;
[Severity: High]
This isn't a bug introduced by this patch, but does calling this function
acquire a standard spinlock in the cpuidle execution path?
The cpuidle callback ux500_enter_idle() executes with local hardware interrupts
disabled. It calls db8500_prcmu_set_power_state(), which acquires a spinlock:
drivers/mfd/db8500-prcmu.c:db8500_prcmu_set_power_state() {
...
spin_lock_irqsave(&mb0_transfer.lock, flags);
>
> /* When we switch to retention, the prcmu is in charge
> @@ -109,7 +109,7 @@ static struct cpuidle_driver ux500_idle_driver = {
> static int dbx500_cpuidle_probe(struct platform_device *pdev)
> {
> /* Configure wake up reasons */
> - prcmu_enable_wakeups(PRCMU_WAKEUP(ARM) | PRCMU_WAKEUP(RTC) |
> + db8500_prcmu_enable_wakeups(PRCMU_WAKEUP(ARM) | PRCMU_WAKEUP(RTC) |
> PRCMU_WAKEUP(ABB));
>
> return cpuidle_register(&ux500_idle_driver, NULL);
> diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
> index f0bc0b5a6f4a..86fa99022cb3 100644
> --- a/drivers/mfd/ab8500-core.c
> +++ b/drivers/mfd/ab8500-core.c
> @@ -19,7 +19,7 @@
> #include <linux/mfd/core.h>
> #include <linux/mfd/abx500.h>
> #include <linux/mfd/abx500/ab8500.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
> #include <linux/of.h>
>
> /*
> diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
> index 21e68a382b11..6672c55f2ebc 100644
> --- a/drivers/mfd/db8500-prcmu.c
> +++ b/drivers/mfd/db8500-prcmu.c
> @@ -32,7 +32,7 @@
> #include <linux/platform_device.h>
> #include <linux/uaccess.h>
> #include <linux/mfd/core.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
> #include <linux/mfd/abx500/ab8500.h>
> #include <linux/regulator/db8500-prcmu.h>
> #include <linux/regulator/machine.h>
> @@ -2285,7 +2285,7 @@ void db8500_prcmu_system_reset(u16 reset_code)
> /**
> * db8500_prcmu_get_reset_code - Retrieve SW reset reason code
> *
> - * Retrieves the reset reason code stored by prcmu_system_reset() before
> + * Retrieves the reset reason code stored by db8500_prcmu_system_reset() before
> * last restart.
> */
> u16 db8500_prcmu_get_reset_code(void)
> @@ -3041,7 +3041,7 @@ static int db8500_prcmu_probe(struct platform_device *pdev)
>
> db8500_irq_init(np);
>
> - prcmu_config_esram0_deep_sleep(ESRAM0_DEEP_SLEEP_STATE_RET);
> + db8500_prcmu_config_esram0_deep_sleep(ESRAM0_DEEP_SLEEP_STATE_RET);
>
> err = mfd_add_devices(&pdev->dev, 0, common_prcmu_devs,
> ARRAY_SIZE(common_prcmu_devs), NULL, 0, db8500_irq_domain);
> diff --git a/drivers/regulator/db8500-prcmu.c b/drivers/regulator/db8500-prcmu.c
> index 1ec2e1348891..751fe36580fa 100644
> --- a/drivers/regulator/db8500-prcmu.c
> +++ b/drivers/regulator/db8500-prcmu.c
> @@ -13,7 +13,7 @@
> #include <linux/err.h>
> #include <linux/spinlock.h>
> #include <linux/platform_device.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
> #include <linux/regulator/driver.h>
> #include <linux/regulator/machine.h>
> #include <linux/regulator/db8500-prcmu.h>
> @@ -93,13 +93,13 @@ static int enable_epod(u16 epod_id, bool ramret)
>
> if (ramret) {
> if (!epod_on[epod_id]) {
> - ret = prcmu_set_epod(epod_id, EPOD_STATE_RAMRET);
> + ret = db8500_prcmu_set_epod(epod_id, EPOD_STATE_RAMRET);
> if (ret < 0)
> return ret;
> }
> epod_ramret[epod_id] = true;
> } else {
> - ret = prcmu_set_epod(epod_id, EPOD_STATE_ON);
> + ret = db8500_prcmu_set_epod(epod_id, EPOD_STATE_ON);
> if (ret < 0)
> return ret;
> epod_on[epod_id] = true;
> @@ -114,18 +114,18 @@ static int disable_epod(u16 epod_id, bool ramret)
>
> if (ramret) {
> if (!epod_on[epod_id]) {
> - ret = prcmu_set_epod(epod_id, EPOD_STATE_OFF);
> + ret = db8500_prcmu_set_epod(epod_id, EPOD_STATE_OFF);
> if (ret < 0)
> return ret;
> }
> epod_ramret[epod_id] = false;
> } else {
> if (epod_ramret[epod_id]) {
> - ret = prcmu_set_epod(epod_id, EPOD_STATE_RAMRET);
> + ret = db8500_prcmu_set_epod(epod_id, EPOD_STATE_RAMRET);
> if (ret < 0)
> return ret;
> } else {
> - ret = prcmu_set_epod(epod_id, EPOD_STATE_OFF);
> + ret = db8500_prcmu_set_epod(epod_id, EPOD_STATE_OFF);
> if (ret < 0)
> return ret;
> }
> diff --git a/drivers/thermal/db8500_thermal.c b/drivers/thermal/db8500_thermal.c
> index 576f88b6a1b3..cf1706569e6d 100644
> --- a/drivers/thermal/db8500_thermal.c
> +++ b/drivers/thermal/db8500_thermal.c
> @@ -10,7 +10,7 @@
>
> #include <linux/cpu_cooling.h>
> #include <linux/interrupt.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/platform_device.h>
> @@ -82,7 +82,7 @@ static void db8500_thermal_update_config(struct db8500_thermal_zone *th,
> unsigned long next_low,
> unsigned long next_high)
> {
> - prcmu_stop_temp_sense();
> + db8500_prcmu_stop_temp_sense();
>
> th->cur_index = idx;
> th->interpolated_temp = (next_low + next_high)/2;
> @@ -91,8 +91,8 @@ static void db8500_thermal_update_config(struct db8500_thermal_zone *th,
> * The PRCMU accept absolute temperatures in celsius so divide
> * down the millicelsius with 1000
> */
> - prcmu_config_hotmon((u8)(next_low/1000), (u8)(next_high/1000));
> - prcmu_start_temp_sense(PRCMU_DEFAULT_MEASURE_TIME);
> + db8500_prcmu_config_hotmon((u8)(next_low / 1000), (u8)(next_high / 1000));
> + db8500_prcmu_start_temp_sense(PRCMU_DEFAULT_MEASURE_TIME);
> }
>
> static irqreturn_t prcmu_low_irq_handler(int irq, void *irq_data)
[Severity: High]
This is a pre-existing issue, but do prcmu_low_irq_handler() and
prcmu_high_irq_handler() race to update the shared thermal state without
locking?
These two threaded IRQ handlers are registered for separate interrupt lines and
can be scheduled concurrently on different CPUs. Both handlers read and modify
th->cur_index and invoke hardware configuration functions without any
synchronization:
drivers/thermal/db8500_thermal.c:prcmu_low_irq_handler() {
struct db8500_thermal_zone *th = irq_data;
unsigned int idx = th->cur_index;
...
db8500_thermal_update_config(th, idx, next_low, next_high);
drivers/thermal/db8500_thermal.c:prcmu_high_irq_handler() {
struct db8500_thermal_zone *th = irq_data;
unsigned int idx = th->cur_index;
...
db8500_thermal_update_config(th, idx, next_low, next_high);
Could this data race corrupt the thermal zone state machine, leading to
incorrect temperature thresholds being programmed and out-of-sync
software/hardware states?
> @@ -204,7 +204,7 @@ static int db8500_thermal_probe(struct platform_device *pdev)
> static int db8500_thermal_suspend(struct platform_device *pdev,
> pm_message_t state)
> {
> - prcmu_stop_temp_sense();
> + db8500_prcmu_stop_temp_sense();
>
> return 0;
> }
> diff --git a/drivers/watchdog/db8500_wdt.c b/drivers/watchdog/db8500_wdt.c
> index 97148ac0aa54..70ccea13288d 100644
> --- a/drivers/watchdog/db8500_wdt.c
> +++ b/drivers/watchdog/db8500_wdt.c
> @@ -16,7 +16,7 @@
> #include <linux/watchdog.h>
> #include <linux/platform_device.h>
>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
>
> #define WATCHDOG_TIMEOUT 600 /* 10 minutes */
>
> @@ -37,24 +37,24 @@ MODULE_PARM_DESC(nowayout,
>
> static int db8500_wdt_start(struct watchdog_device *wdd)
> {
> - return prcmu_enable_a9wdog(PRCMU_WDOG_ALL);
> + return db8500_prcmu_enable_a9wdog(PRCMU_WDOG_ALL);
> }
>
> static int db8500_wdt_stop(struct watchdog_device *wdd)
> {
> - return prcmu_disable_a9wdog(PRCMU_WDOG_ALL);
> + return db8500_prcmu_disable_a9wdog(PRCMU_WDOG_ALL);
> }
>
> static int db8500_wdt_keepalive(struct watchdog_device *wdd)
> {
> - return prcmu_kick_a9wdog(PRCMU_WDOG_ALL);
> + return db8500_prcmu_kick_a9wdog(PRCMU_WDOG_ALL);
> }
>
> static int db8500_wdt_set_timeout(struct watchdog_device *wdd,
> unsigned int timeout)
> {
> db8500_wdt_stop(wdd);
> - prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
> + db8500_prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
> db8500_wdt_start(wdd);
>
> return 0;
> @@ -91,10 +91,10 @@ static int db8500_wdt_probe(struct platform_device *pdev)
> watchdog_set_nowayout(&db8500_wdt, nowayout);
>
> /* disable auto off on sleep */
> - prcmu_config_a9wdog(PRCMU_WDOG_CPU1, false);
> + db8500_prcmu_config_a9wdog(PRCMU_WDOG_CPU1, false);
>
> /* set HW initial value */
> - prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
> + db8500_prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
>
> ret = devm_watchdog_register_device(dev, &db8500_wdt);
> if (ret)
> @@ -110,9 +110,9 @@ static int db8500_wdt_suspend(struct platform_device *pdev,
> {
> if (watchdog_active(&db8500_wdt)) {
> db8500_wdt_stop(&db8500_wdt);
> - prcmu_config_a9wdog(PRCMU_WDOG_CPU1, true);
> + db8500_prcmu_config_a9wdog(PRCMU_WDOG_CPU1, true);
>
> - prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
> + db8500_prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
> db8500_wdt_start(&db8500_wdt);
> }
> return 0;
> @@ -122,9 +122,9 @@ static int db8500_wdt_resume(struct platform_device *pdev)
> {
> if (watchdog_active(&db8500_wdt)) {
> db8500_wdt_stop(&db8500_wdt);
> - prcmu_config_a9wdog(PRCMU_WDOG_CPU1, false);
> + db8500_prcmu_config_a9wdog(PRCMU_WDOG_CPU1, false);
>
> - prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
> + db8500_prcmu_load_a9wdog(PRCMU_WDOG_ALL, timeout * 1000);
> db8500_wdt_start(&db8500_wdt);
> }
> return 0;
> diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h
> index a62de3d155ed..c939c9a1170a 100644
> --- a/include/linux/mfd/db8500-prcmu.h
> +++ b/include/linux/mfd/db8500-prcmu.h
> @@ -12,6 +12,9 @@
>
> #include <linux/interrupt.h>
> #include <linux/bitops.h>
> +#include <linux/err.h>
> +
> +#include <dt-bindings/mfd/dbx500-prcmu.h> /* For clock identifiers */
>
> /*
> * Registers
> @@ -24,6 +27,38 @@
> #define DB8500_PRCM_DSI_SW_RESET_DSI1_SW_RESETN BIT(1)
> #define DB8500_PRCM_DSI_SW_RESET_DSI2_SW_RESETN BIT(2)
>
> +/* Offset for the firmware version within the TCPM */
> +#define DB8500_PRCMU_FW_VERSION_OFFSET 0xA4
> +
> +#define DB8500_PRCMU_LEGACY_OFFSET 0xDD4
> +
> +/*
> + * CLKOUT sources
> + */
> +#define PRCMU_CLKSRC_CLK38M 0x00
> +#define PRCMU_CLKSRC_ACLK 0x01
> +#define PRCMU_CLKSRC_SYSCLK 0x02
> +#define PRCMU_CLKSRC_LCDCLK 0x03
> +#define PRCMU_CLKSRC_SDMMCCLK 0x04
> +#define PRCMU_CLKSRC_TVCLK 0x05
> +#define PRCMU_CLKSRC_TIMCLK 0x06
> +#define PRCMU_CLKSRC_CLK009 0x07
> +/* These are only valid for CLKOUT1: */
> +#define PRCMU_CLKSRC_SIAMMDSPCLK 0x40
> +#define PRCMU_CLKSRC_I2CCLK 0x41
> +#define PRCMU_CLKSRC_MSP02CLK 0x42
> +#define PRCMU_CLKSRC_ARMPLL_OBSCLK 0x43
> +#define PRCMU_CLKSRC_HSIRXCLK 0x44
> +#define PRCMU_CLKSRC_HSITXCLK 0x45
> +#define PRCMU_CLKSRC_ARMCLKFIX 0x46
> +#define PRCMU_CLKSRC_HDMICLK 0x47
> +
> +/*
> + * Definitions for controlling ESRAM0 in deep sleep.
> + */
> +#define ESRAM0_DEEP_SLEEP_STATE_OFF 1
> +#define ESRAM0_DEEP_SLEEP_STATE_RET 2
> +
> /* This portion previously known as <mach/prcmu-fw-defs_v1.h> */
>
> /**
> @@ -451,10 +486,173 @@ enum prcmu_power_status {
> PRCMU_ARMPENDINGIT_ER = 0x93,
> };
>
> +/* PRCMU Wakeup defines */
> +enum prcmu_wakeup_index {
> + PRCMU_WAKEUP_INDEX_RTC,
> + PRCMU_WAKEUP_INDEX_RTT0,
> + PRCMU_WAKEUP_INDEX_RTT1,
> + PRCMU_WAKEUP_INDEX_HSI0,
> + PRCMU_WAKEUP_INDEX_HSI1,
> + PRCMU_WAKEUP_INDEX_USB,
> + PRCMU_WAKEUP_INDEX_ABB,
> + PRCMU_WAKEUP_INDEX_ABB_FIFO,
> + PRCMU_WAKEUP_INDEX_ARM,
> + PRCMU_WAKEUP_INDEX_CD_IRQ,
> + NUM_PRCMU_WAKEUP_INDICES
> +};
> +
> +#define PRCMU_WAKEUP(_name) (BIT(PRCMU_WAKEUP_INDEX_##_name))
> +
> +/**
> + * enum prcmu_wdog_id - PRCMU watchdog IDs
> + * @PRCMU_WDOG_ALL: use all timers
> + * @PRCMU_WDOG_CPU1: use first CPU timer only
> + * @PRCMU_WDOG_CPU2: use second CPU timer conly
> + */
> +enum prcmu_wdog_id {
> + PRCMU_WDOG_ALL = 0x00,
> + PRCMU_WDOG_CPU1 = 0x01,
> + PRCMU_WDOG_CPU2 = 0x02,
> +};
> +
> +/**
> + * enum ape_opp - APE OPP states definition
> + * @APE_OPP_INIT:
> + * @APE_NO_CHANGE: The APE operating point is unchanged
> + * @APE_100_OPP: The new APE operating point is ape100opp
> + * @APE_50_OPP: 50%
> + * @APE_50_PARTLY_25_OPP: 50%, except some clocks at 25%.
> + */
> +enum ape_opp {
> + APE_OPP_INIT = 0x00,
> + APE_NO_CHANGE = 0x01,
> + APE_100_OPP = 0x02,
> + APE_50_OPP = 0x03,
> + APE_50_PARTLY_25_OPP = 0xFF,
> +};
> +
> +/**
> + * enum arm_opp - ARM OPP states definition
> + * @ARM_OPP_INIT:
> + * @ARM_NO_CHANGE: The ARM operating point is unchanged
> + * @ARM_100_OPP: The new ARM operating point is arm100opp
> + * @ARM_50_OPP: The new ARM operating point is arm50opp
> + * @ARM_MAX_OPP: Operating point is "max" (more than 100)
> + * @ARM_MAX_FREQ100OPP: Set max opp if available, else 100
> + * @ARM_EXTCLK: The new ARM operating point is armExtClk
> + */
> +enum arm_opp {
> + ARM_OPP_INIT = 0x00,
> + ARM_NO_CHANGE = 0x01,
> + ARM_100_OPP = 0x02,
> + ARM_50_OPP = 0x03,
> + ARM_MAX_OPP = 0x04,
> + ARM_MAX_FREQ100OPP = 0x05,
> + ARM_EXTCLK = 0x07
> +};
> +
> +/**
> + * enum ddr_opp - DDR OPP states definition
> + * @DDR_100_OPP: The new DDR operating point is ddr100opp
> + * @DDR_50_OPP: The new DDR operating point is ddr50opp
> + * @DDR_25_OPP: The new DDR operating point is ddr25opp
> + */
> +enum ddr_opp {
> + DDR_100_OPP = 0x00,
> + DDR_50_OPP = 0x01,
> + DDR_25_OPP = 0x02,
> +};
> +
> +/**
> + * enum ddr_pwrst - DDR power states definition
> + * @DDR_PWR_STATE_UNCHANGED: SDRAM and DDR controller state is unchanged
> + * @DDR_PWR_STATE_ON:
> + * @DDR_PWR_STATE_OFFLOWLAT:
> + * @DDR_PWR_STATE_OFFHIGHLAT:
> + */
> +enum ddr_pwrst {
> + DDR_PWR_STATE_UNCHANGED = 0x00,
> + DDR_PWR_STATE_ON = 0x01,
> + DDR_PWR_STATE_OFFLOWLAT = 0x02,
> + DDR_PWR_STATE_OFFHIGHLAT = 0x03
> +};
> +
> /*
> * Definitions for autonomous power management configuration.
> */
>
> +/* EPOD (power domain) IDs */
> +
> +/*
> + * DB8500 EPODs
> + * - EPOD_ID_SVAMMDSP: power domain for SVA MMDSP
> + * - EPOD_ID_SVAPIPE: power domain for SVA pipe
> + * - EPOD_ID_SIAMMDSP: power domain for SIA MMDSP
> + * - EPOD_ID_SIAPIPE: power domain for SIA pipe
> + * - EPOD_ID_SGA: power domain for SGA
> + * - EPOD_ID_B2R2_MCDE: power domain for B2R2 and MCDE
> + * - EPOD_ID_ESRAM12: power domain for ESRAM 1 and 2
> + * - EPOD_ID_ESRAM34: power domain for ESRAM 3 and 4
> + * - NUM_EPOD_ID: number of power domains
> + *
> + * TODO: These should be prefixed.
> + */
> +#define EPOD_ID_SVAMMDSP 0
> +#define EPOD_ID_SVAPIPE 1
> +#define EPOD_ID_SIAMMDSP 2
> +#define EPOD_ID_SIAPIPE 3
> +#define EPOD_ID_SGA 4
> +#define EPOD_ID_B2R2_MCDE 5
> +#define EPOD_ID_ESRAM12 6
> +#define EPOD_ID_ESRAM34 7
> +#define NUM_EPOD_ID 8
> +
> +/*
> + * state definition for EPOD (power domain)
> + * - EPOD_STATE_NO_CHANGE: The EPOD should remain unchanged
> + * - EPOD_STATE_OFF: The EPOD is switched off
> + * - EPOD_STATE_RAMRET: The EPOD is switched off with its internal RAM in
> + * retention
> + * - EPOD_STATE_ON_CLK_OFF: The EPOD is switched on, clock is still off
> + * - EPOD_STATE_ON: Same as above, but with clock enabled
> + */
> +#define EPOD_STATE_NO_CHANGE 0x00
> +#define EPOD_STATE_OFF 0x01
> +#define EPOD_STATE_RAMRET 0x02
> +#define EPOD_STATE_ON_CLK_OFF 0x03
> +#define EPOD_STATE_ON 0x04
> +
> +#define PRCMU_FW_PROJECT_U8500 2
> +#define PRCMU_FW_PROJECT_U8400 3
> +#define PRCMU_FW_PROJECT_U9500 4 /* Customer specific */
> +#define PRCMU_FW_PROJECT_U8500_MBB 5
> +#define PRCMU_FW_PROJECT_U8500_C1 6
> +#define PRCMU_FW_PROJECT_U8500_C2 7
> +#define PRCMU_FW_PROJECT_U8500_C3 8
> +#define PRCMU_FW_PROJECT_U8500_C4 9
> +#define PRCMU_FW_PROJECT_U9500_MBL 10
> +#define PRCMU_FW_PROJECT_U8500_SSG1 11 /* Samsung specific */
> +#define PRCMU_FW_PROJECT_U8500_MBL2 12 /* Customer specific */
> +#define PRCMU_FW_PROJECT_U8520 13
> +#define PRCMU_FW_PROJECT_U8420 14
> +#define PRCMU_FW_PROJECT_U8500_SSG2 15 /* Samsung specific */
> +#define PRCMU_FW_PROJECT_U8420_SYSCLK 17
> +#define PRCMU_FW_PROJECT_A9420 20
> +/* [32..63] 9540 and derivatives */
> +#define PRCMU_FW_PROJECT_U9540 32
> +/* [64..95] 8540 and derivatives */
> +#define PRCMU_FW_PROJECT_L8540 64
> +/* [96..126] 8580 and derivatives */
> +#define PRCMU_FW_PROJECT_L8580 96
> +
> +#define PRCMU_FW_PROJECT_NAME_LEN 20
> +
> +/* PRCMU QoS APE OPP class */
> +#define PRCMU_QOS_APE_OPP 1
> +#define PRCMU_QOS_DDR_OPP 2
> +#define PRCMU_QOS_ARM_OPP 3
> +#define PRCMU_QOS_DEFAULT_VALUE -1
> +
> #define PRCMU_AUTO_PM_OFF 0
> #define PRCMU_AUTO_PM_ON 1
>
> @@ -469,6 +667,14 @@ enum prcmu_auto_pm_policy {
> PRCMU_AUTO_PM_POLICY_DSP_CLK_OFF_HWP_CLK_OFF,
> };
>
> +struct prcmu_fw_version {
> + u32 project; /* Notice, project shifted with 8 on ux540 */
> + u8 api_version;
> + u8 func_version;
> + u8 errata;
> + char project_name[PRCMU_FW_PROJECT_NAME_LEN];
> +};
> +
> /**
> * struct prcmu_auto_pm_config - Autonomous power management configuration.
> * @sia_auto_pm_enable: SIA autonomous pm enable. (PRCMU_AUTO_PM_{OFF,ON})
> @@ -501,6 +707,9 @@ void prcmu_configure_auto_pm(struct prcmu_auto_pm_config *sleep,
> bool prcmu_is_auto_pm_enabled(void);
>
> int prcmu_config_clkout(u8 clkout, u8 source, u8 div);
> +unsigned long prcmu_clock_rate(u8 clock);
> +long prcmu_round_clock_rate(u8 clock, unsigned long rate);
> +int prcmu_set_clock_rate(u8 clock, unsigned long rate);
> int prcmu_set_clock_divider(u8 clock, u8 divider);
> int db8500_prcmu_config_hotdog(u8 threshold);
> int db8500_prcmu_config_hotmon(u8 low, u8 high);
> @@ -508,6 +717,8 @@ int db8500_prcmu_start_temp_sense(u16 cycles32k);
> int db8500_prcmu_stop_temp_sense(void);
> int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size);
> int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size);
> +int prcmu_abb_write_masked(u8 slave, u8 reg, u8 *value,
> + u8 *mask, u8 size);
>
> int prcmu_ac_wake_req(void);
> void prcmu_ac_sleep_req(void);
> @@ -610,6 +821,21 @@ static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
> return 0;
> }
>
> +static inline unsigned long prcmu_clock_rate(u8 clock)
> +{
> + return 0;
> +}
> +
> +static inline long prcmu_round_clock_rate(u8 clock, unsigned long rate)
> +{
> + return 0;
> +}
> +
> +static inline int prcmu_set_clock_rate(u8 clock, unsigned long rate)
> +{
> + return 0;
> +}
> +
> static inline int prcmu_set_clock_divider(u8 clock, u8 divider)
> {
> return 0;
> @@ -637,12 +863,18 @@ static inline int db8500_prcmu_stop_temp_sense(void)
>
> static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
> {
> - return -ENOSYS;
> + return -EINVAL;
> }
>
> static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
> {
> - return -ENOSYS;
> + return -EINVAL;
> +}
> +
> +static inline int prcmu_abb_write_masked(u8 slave, u8 reg,
> + u8 *value, u8 *mask, u8 size)
> +{
> + return -EINVAL;
> }
>
> static inline int prcmu_ac_wake_req(void)
> @@ -745,4 +977,20 @@ static inline void db8500_prcmu_write_masked(unsigned int reg, u32 mask,
>
> #endif /* !CONFIG_MFD_DB8500_PRCMU */
>
> +static inline int prcmu_qos_add_requirement(int prcmu_qos_class,
> + char *name, s32 value)
> +{
> + return 0;
> +}
> +
> +static inline int prcmu_qos_update_requirement(int prcmu_qos_class,
> + char *name, s32 new_value)
> +{
> + return 0;
> +}
> +
> +static inline void prcmu_qos_remove_requirement(int prcmu_qos_class, char *name)
> +{
> +}
> +
> #endif /* __MFD_DB8500_PRCMU_H */
> diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h
> deleted file mode 100644
> index 828362b7860c..000000000000
> --- a/include/linux/mfd/dbx500-prcmu.h
> +++ /dev/null
> @@ -1,575 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -/*
> - * Copyright (C) ST Ericsson SA 2011
> - *
> - * STE Ux500 PRCMU API
> - */
> -#ifndef __MACH_PRCMU_H
> -#define __MACH_PRCMU_H
> -
> -#include <linux/interrupt.h>
> -#include <linux/notifier.h>
> -#include <linux/err.h>
> -
> -#include <dt-bindings/mfd/dbx500-prcmu.h> /* For clock identifiers */
> -
> -/* Offset for the firmware version within the TCPM */
> -#define DB8500_PRCMU_FW_VERSION_OFFSET 0xA4
> -#define DBX540_PRCMU_FW_VERSION_OFFSET 0xA8
> -
> -/* PRCMU Wakeup defines */
> -enum prcmu_wakeup_index {
> - PRCMU_WAKEUP_INDEX_RTC,
> - PRCMU_WAKEUP_INDEX_RTT0,
> - PRCMU_WAKEUP_INDEX_RTT1,
> - PRCMU_WAKEUP_INDEX_HSI0,
> - PRCMU_WAKEUP_INDEX_HSI1,
> - PRCMU_WAKEUP_INDEX_USB,
> - PRCMU_WAKEUP_INDEX_ABB,
> - PRCMU_WAKEUP_INDEX_ABB_FIFO,
> - PRCMU_WAKEUP_INDEX_ARM,
> - PRCMU_WAKEUP_INDEX_CD_IRQ,
> - NUM_PRCMU_WAKEUP_INDICES
> -};
> -#define PRCMU_WAKEUP(_name) (BIT(PRCMU_WAKEUP_INDEX_##_name))
> -
> -/* EPOD (power domain) IDs */
> -
> -/*
> - * DB8500 EPODs
> - * - EPOD_ID_SVAMMDSP: power domain for SVA MMDSP
> - * - EPOD_ID_SVAPIPE: power domain for SVA pipe
> - * - EPOD_ID_SIAMMDSP: power domain for SIA MMDSP
> - * - EPOD_ID_SIAPIPE: power domain for SIA pipe
> - * - EPOD_ID_SGA: power domain for SGA
> - * - EPOD_ID_B2R2_MCDE: power domain for B2R2 and MCDE
> - * - EPOD_ID_ESRAM12: power domain for ESRAM 1 and 2
> - * - EPOD_ID_ESRAM34: power domain for ESRAM 3 and 4
> - * - NUM_EPOD_ID: number of power domains
> - *
> - * TODO: These should be prefixed.
> - */
> -#define EPOD_ID_SVAMMDSP 0
> -#define EPOD_ID_SVAPIPE 1
> -#define EPOD_ID_SIAMMDSP 2
> -#define EPOD_ID_SIAPIPE 3
> -#define EPOD_ID_SGA 4
> -#define EPOD_ID_B2R2_MCDE 5
> -#define EPOD_ID_ESRAM12 6
> -#define EPOD_ID_ESRAM34 7
> -#define NUM_EPOD_ID 8
> -
> -/*
> - * state definition for EPOD (power domain)
> - * - EPOD_STATE_NO_CHANGE: The EPOD should remain unchanged
> - * - EPOD_STATE_OFF: The EPOD is switched off
> - * - EPOD_STATE_RAMRET: The EPOD is switched off with its internal RAM in
> - * retention
> - * - EPOD_STATE_ON_CLK_OFF: The EPOD is switched on, clock is still off
> - * - EPOD_STATE_ON: Same as above, but with clock enabled
> - */
> -#define EPOD_STATE_NO_CHANGE 0x00
> -#define EPOD_STATE_OFF 0x01
> -#define EPOD_STATE_RAMRET 0x02
> -#define EPOD_STATE_ON_CLK_OFF 0x03
> -#define EPOD_STATE_ON 0x04
> -
> -/*
> - * CLKOUT sources
> - */
> -#define PRCMU_CLKSRC_CLK38M 0x00
> -#define PRCMU_CLKSRC_ACLK 0x01
> -#define PRCMU_CLKSRC_SYSCLK 0x02
> -#define PRCMU_CLKSRC_LCDCLK 0x03
> -#define PRCMU_CLKSRC_SDMMCCLK 0x04
> -#define PRCMU_CLKSRC_TVCLK 0x05
> -#define PRCMU_CLKSRC_TIMCLK 0x06
> -#define PRCMU_CLKSRC_CLK009 0x07
> -/* These are only valid for CLKOUT1: */
> -#define PRCMU_CLKSRC_SIAMMDSPCLK 0x40
> -#define PRCMU_CLKSRC_I2CCLK 0x41
> -#define PRCMU_CLKSRC_MSP02CLK 0x42
> -#define PRCMU_CLKSRC_ARMPLL_OBSCLK 0x43
> -#define PRCMU_CLKSRC_HSIRXCLK 0x44
> -#define PRCMU_CLKSRC_HSITXCLK 0x45
> -#define PRCMU_CLKSRC_ARMCLKFIX 0x46
> -#define PRCMU_CLKSRC_HDMICLK 0x47
> -
> -/**
> - * enum prcmu_wdog_id - PRCMU watchdog IDs
> - * @PRCMU_WDOG_ALL: use all timers
> - * @PRCMU_WDOG_CPU1: use first CPU timer only
> - * @PRCMU_WDOG_CPU2: use second CPU timer conly
> - */
> -enum prcmu_wdog_id {
> - PRCMU_WDOG_ALL = 0x00,
> - PRCMU_WDOG_CPU1 = 0x01,
> - PRCMU_WDOG_CPU2 = 0x02,
> -};
> -
> -/**
> - * enum ape_opp - APE OPP states definition
> - * @APE_OPP_INIT:
> - * @APE_NO_CHANGE: The APE operating point is unchanged
> - * @APE_100_OPP: The new APE operating point is ape100opp
> - * @APE_50_OPP: 50%
> - * @APE_50_PARTLY_25_OPP: 50%, except some clocks at 25%.
> - */
> -enum ape_opp {
> - APE_OPP_INIT = 0x00,
> - APE_NO_CHANGE = 0x01,
> - APE_100_OPP = 0x02,
> - APE_50_OPP = 0x03,
> - APE_50_PARTLY_25_OPP = 0xFF,
> -};
> -
> -/**
> - * enum arm_opp - ARM OPP states definition
> - * @ARM_OPP_INIT:
> - * @ARM_NO_CHANGE: The ARM operating point is unchanged
> - * @ARM_100_OPP: The new ARM operating point is arm100opp
> - * @ARM_50_OPP: The new ARM operating point is arm50opp
> - * @ARM_MAX_OPP: Operating point is "max" (more than 100)
> - * @ARM_MAX_FREQ100OPP: Set max opp if available, else 100
> - * @ARM_EXTCLK: The new ARM operating point is armExtClk
> - */
> -enum arm_opp {
> - ARM_OPP_INIT = 0x00,
> - ARM_NO_CHANGE = 0x01,
> - ARM_100_OPP = 0x02,
> - ARM_50_OPP = 0x03,
> - ARM_MAX_OPP = 0x04,
> - ARM_MAX_FREQ100OPP = 0x05,
> - ARM_EXTCLK = 0x07
> -};
> -
> -/**
> - * enum ddr_opp - DDR OPP states definition
> - * @DDR_100_OPP: The new DDR operating point is ddr100opp
> - * @DDR_50_OPP: The new DDR operating point is ddr50opp
> - * @DDR_25_OPP: The new DDR operating point is ddr25opp
> - */
> -enum ddr_opp {
> - DDR_100_OPP = 0x00,
> - DDR_50_OPP = 0x01,
> - DDR_25_OPP = 0x02,
> -};
> -
> -/*
> - * Definitions for controlling ESRAM0 in deep sleep.
> - */
> -#define ESRAM0_DEEP_SLEEP_STATE_OFF 1
> -#define ESRAM0_DEEP_SLEEP_STATE_RET 2
> -
> -/**
> - * enum ddr_pwrst - DDR power states definition
> - * @DDR_PWR_STATE_UNCHANGED: SDRAM and DDR controller state is unchanged
> - * @DDR_PWR_STATE_ON:
> - * @DDR_PWR_STATE_OFFLOWLAT:
> - * @DDR_PWR_STATE_OFFHIGHLAT:
> - */
> -enum ddr_pwrst {
> - DDR_PWR_STATE_UNCHANGED = 0x00,
> - DDR_PWR_STATE_ON = 0x01,
> - DDR_PWR_STATE_OFFLOWLAT = 0x02,
> - DDR_PWR_STATE_OFFHIGHLAT = 0x03
> -};
> -
> -#define DB8500_PRCMU_LEGACY_OFFSET 0xDD4
> -
> -#define PRCMU_FW_PROJECT_U8500 2
> -#define PRCMU_FW_PROJECT_U8400 3
> -#define PRCMU_FW_PROJECT_U9500 4 /* Customer specific */
> -#define PRCMU_FW_PROJECT_U8500_MBB 5
> -#define PRCMU_FW_PROJECT_U8500_C1 6
> -#define PRCMU_FW_PROJECT_U8500_C2 7
> -#define PRCMU_FW_PROJECT_U8500_C3 8
> -#define PRCMU_FW_PROJECT_U8500_C4 9
> -#define PRCMU_FW_PROJECT_U9500_MBL 10
> -#define PRCMU_FW_PROJECT_U8500_SSG1 11 /* Samsung specific */
> -#define PRCMU_FW_PROJECT_U8500_MBL2 12 /* Customer specific */
> -#define PRCMU_FW_PROJECT_U8520 13
> -#define PRCMU_FW_PROJECT_U8420 14
> -#define PRCMU_FW_PROJECT_U8500_SSG2 15 /* Samsung specific */
> -#define PRCMU_FW_PROJECT_U8420_SYSCLK 17
> -#define PRCMU_FW_PROJECT_A9420 20
> -/* [32..63] 9540 and derivatives */
> -#define PRCMU_FW_PROJECT_U9540 32
> -/* [64..95] 8540 and derivatives */
> -#define PRCMU_FW_PROJECT_L8540 64
> -/* [96..126] 8580 and derivatives */
> -#define PRCMU_FW_PROJECT_L8580 96
> -
> -#define PRCMU_FW_PROJECT_NAME_LEN 20
> -struct prcmu_fw_version {
> - u32 project; /* Notice, project shifted with 8 on ux540 */
> - u8 api_version;
> - u8 func_version;
> - u8 errata;
> - char project_name[PRCMU_FW_PROJECT_NAME_LEN];
> -};
> -
> -#include <linux/mfd/db8500-prcmu.h>
> -
> -#if defined(CONFIG_UX500_SOC_DB8500)
> -
> -static inline void __init prcmu_early_init(void)
> -{
> - db8500_prcmu_early_init();
> -}
> -
> -static inline int prcmu_set_power_state(u8 state, bool keep_ulp_clk,
> - bool keep_ap_pll)
> -{
> - return db8500_prcmu_set_power_state(state, keep_ulp_clk,
> - keep_ap_pll);
> -}
> -
> -static inline u8 prcmu_get_power_state_result(void)
> -{
> - return db8500_prcmu_get_power_state_result();
> -}
> -
> -static inline int prcmu_set_epod(u16 epod_id, u8 epod_state)
> -{
> - return db8500_prcmu_set_epod(epod_id, epod_state);
> -}
> -
> -static inline void prcmu_enable_wakeups(u32 wakeups)
> -{
> - db8500_prcmu_enable_wakeups(wakeups);
> -}
> -
> -static inline void prcmu_disable_wakeups(void)
> -{
> - prcmu_enable_wakeups(0);
> -}
> -
> -static inline void prcmu_config_abb_event_readout(u32 abb_events)
> -{
> - db8500_prcmu_config_abb_event_readout(abb_events);
> -}
> -
> -static inline void prcmu_get_abb_event_buffer(void __iomem **buf)
> -{
> - db8500_prcmu_get_abb_event_buffer(buf);
> -}
> -
> -int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size);
> -int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size);
> -int prcmu_abb_write_masked(u8 slave, u8 reg, u8 *value, u8 *mask, u8 size);
> -
> -int prcmu_config_clkout(u8 clkout, u8 source, u8 div);
> -
> -static inline int prcmu_request_clock(u8 clock, bool enable)
> -{
> - return db8500_prcmu_request_clock(clock, enable);
> -}
> -
> -unsigned long prcmu_clock_rate(u8 clock);
> -long prcmu_round_clock_rate(u8 clock, unsigned long rate);
> -int prcmu_set_clock_rate(u8 clock, unsigned long rate);
> -
> -static inline int prcmu_get_ddr_opp(void)
> -{
> - return db8500_prcmu_get_ddr_opp();
> -}
> -
> -static inline int prcmu_set_arm_opp(u8 opp)
> -{
> - return db8500_prcmu_set_arm_opp(opp);
> -}
> -
> -static inline int prcmu_get_arm_opp(void)
> -{
> - return db8500_prcmu_get_arm_opp();
> -}
> -
> -static inline int prcmu_set_ape_opp(u8 opp)
> -{
> - return db8500_prcmu_set_ape_opp(opp);
> -}
> -
> -static inline int prcmu_get_ape_opp(void)
> -{
> - return db8500_prcmu_get_ape_opp();
> -}
> -
> -static inline int prcmu_request_ape_opp_100_voltage(bool enable)
> -{
> - return db8500_prcmu_request_ape_opp_100_voltage(enable);
> -}
> -
> -static inline void prcmu_system_reset(u16 reset_code)
> -{
> - db8500_prcmu_system_reset(reset_code);
> -}
> -
> -static inline u16 prcmu_get_reset_code(void)
> -{
> - return db8500_prcmu_get_reset_code();
> -}
> -
> -int prcmu_ac_wake_req(void);
> -void prcmu_ac_sleep_req(void);
> -static inline void prcmu_modem_reset(void)
> -{
> - db8500_prcmu_modem_reset();
> -}
> -
> -static inline bool prcmu_is_ac_wake_requested(void)
> -{
> - return db8500_prcmu_is_ac_wake_requested();
> -}
> -
> -static inline int prcmu_config_esram0_deep_sleep(u8 state)
> -{
> - return db8500_prcmu_config_esram0_deep_sleep(state);
> -}
> -
> -static inline int prcmu_config_hotdog(u8 threshold)
> -{
> - return db8500_prcmu_config_hotdog(threshold);
> -}
> -
> -static inline int prcmu_config_hotmon(u8 low, u8 high)
> -{
> - return db8500_prcmu_config_hotmon(low, high);
> -}
> -
> -static inline int prcmu_start_temp_sense(u16 cycles32k)
> -{
> - return db8500_prcmu_start_temp_sense(cycles32k);
> -}
> -
> -static inline int prcmu_stop_temp_sense(void)
> -{
> - return db8500_prcmu_stop_temp_sense();
> -}
> -
> -static inline u32 prcmu_read(unsigned int reg)
> -{
> - return db8500_prcmu_read(reg);
> -}
> -
> -static inline void prcmu_write(unsigned int reg, u32 value)
> -{
> - db8500_prcmu_write(reg, value);
> -}
> -
> -static inline void prcmu_write_masked(unsigned int reg, u32 mask, u32 value)
> -{
> - db8500_prcmu_write_masked(reg, mask, value);
> -}
> -
> -static inline int prcmu_enable_a9wdog(u8 id)
> -{
> - return db8500_prcmu_enable_a9wdog(id);
> -}
> -
> -static inline int prcmu_disable_a9wdog(u8 id)
> -{
> - return db8500_prcmu_disable_a9wdog(id);
> -}
> -
> -static inline int prcmu_kick_a9wdog(u8 id)
> -{
> - return db8500_prcmu_kick_a9wdog(id);
> -}
> -
> -static inline int prcmu_load_a9wdog(u8 id, u32 timeout)
> -{
> - return db8500_prcmu_load_a9wdog(id, timeout);
> -}
> -
> -static inline int prcmu_config_a9wdog(u8 num, bool sleep_auto_off)
> -{
> - return db8500_prcmu_config_a9wdog(num, sleep_auto_off);
> -}
> -#else
> -
> -static inline void prcmu_early_init(void) {}
> -
> -static inline int prcmu_set_power_state(u8 state, bool keep_ulp_clk,
> - bool keep_ap_pll)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_set_epod(u16 epod_id, u8 epod_state)
> -{
> - return 0;
> -}
> -
> -static inline void prcmu_enable_wakeups(u32 wakeups) {}
> -
> -static inline void prcmu_disable_wakeups(void) {}
> -
> -static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
> -{
> - return -ENOSYS;
> -}
> -
> -static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
> -{
> - return -ENOSYS;
> -}
> -
> -static inline int prcmu_abb_write_masked(u8 slave, u8 reg, u8 *value, u8 *mask,
> - u8 size)
> -{
> - return -ENOSYS;
> -}
> -
> -static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_request_clock(u8 clock, bool enable)
> -{
> - return 0;
> -}
> -
> -static inline long prcmu_round_clock_rate(u8 clock, unsigned long rate)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_set_clock_rate(u8 clock, unsigned long rate)
> -{
> - return 0;
> -}
> -
> -static inline unsigned long prcmu_clock_rate(u8 clock)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_set_ape_opp(u8 opp)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_get_ape_opp(void)
> -{
> - return APE_100_OPP;
> -}
> -
> -static inline int prcmu_request_ape_opp_100_voltage(bool enable)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_set_arm_opp(u8 opp)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_get_arm_opp(void)
> -{
> - return ARM_100_OPP;
> -}
> -
> -static inline int prcmu_get_ddr_opp(void)
> -{
> - return DDR_100_OPP;
> -}
> -
> -static inline void prcmu_system_reset(u16 reset_code) {}
> -
> -static inline u16 prcmu_get_reset_code(void)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_ac_wake_req(void)
> -{
> - return 0;
> -}
> -
> -static inline void prcmu_ac_sleep_req(void) {}
> -
> -static inline void prcmu_modem_reset(void) {}
> -
> -static inline bool prcmu_is_ac_wake_requested(void)
> -{
> - return false;
> -}
> -
> -static inline int prcmu_config_esram0_deep_sleep(u8 state)
> -{
> - return 0;
> -}
> -
> -static inline void prcmu_config_abb_event_readout(u32 abb_events) {}
> -
> -static inline void prcmu_get_abb_event_buffer(void __iomem **buf)
> -{
> - *buf = NULL;
> -}
> -
> -static inline int prcmu_config_hotdog(u8 threshold)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_config_hotmon(u8 low, u8 high)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_start_temp_sense(u16 cycles32k)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_stop_temp_sense(void)
> -{
> - return 0;
> -}
> -
> -static inline u32 prcmu_read(unsigned int reg)
> -{
> - return 0;
> -}
> -
> -static inline void prcmu_write(unsigned int reg, u32 value) {}
> -
> -static inline void prcmu_write_masked(unsigned int reg, u32 mask, u32 value) {}
> -
> -#endif
> -
> -static inline void prcmu_set(unsigned int reg, u32 bits)
> -{
> - prcmu_write_masked(reg, bits, bits);
> -}
> -
> -static inline void prcmu_clear(unsigned int reg, u32 bits)
> -{
> - prcmu_write_masked(reg, bits, 0);
> -}
> -
> -/* PRCMU QoS APE OPP class */
> -#define PRCMU_QOS_APE_OPP 1
> -#define PRCMU_QOS_DDR_OPP 2
> -#define PRCMU_QOS_ARM_OPP 3
> -#define PRCMU_QOS_DEFAULT_VALUE -1
> -
> -static inline int prcmu_qos_add_requirement(int prcmu_qos_class,
> - char *name, s32 value)
> -{
> - return 0;
> -}
> -
> -static inline int prcmu_qos_update_requirement(int prcmu_qos_class,
> - char *name, s32 new_value)
> -{
> - return 0;
> -}
> -
> -static inline void prcmu_qos_remove_requirement(int prcmu_qos_class, char *name)
> -{
> -}
> -
> -#endif /* __MACH_PRCMU_H */
> diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
> index 7798957c6504..499e826d7120 100644
> --- a/sound/soc/ux500/ux500_msp_dai.c
> +++ b/sound/soc/ux500/ux500_msp_dai.c
> @@ -14,7 +14,7 @@
> #include <linux/clk.h>
> #include <linux/of.h>
> #include <linux/regulator/consumer.h>
> -#include <linux/mfd/dbx500-prcmu.h>
> +#include <linux/mfd/db8500-prcmu.h>
>
> #include <sound/soc.h>
> #include <sound/soc-dai.h>
>
> ---
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
> change-id: 20260619-mfd-prcmu-merge-headers-bc84905195b4
>
> Best regards,
> --
> Linus Walleij <linusw@kernel.org>
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v2 6/6] mm/mprotect: use huge_ptep_get() for hugetlb
From: David Hildenbrand (Arm) @ 2026-07-02 15:47 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual
In-Reply-To: <20260702051341.126509-7-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> prot_none_hugetlb_entry() is the hugetlb callback for the early
> mprotect(PROT_NONE) PFN permission walk on x86.
>
> The callback passes the decoded PFN to pfn_modify_allowed(). For a
> hugetlb callback, the pte pointer refers to a hugetlb entry. On
> architectures where hugetlb entries need huge_ptep_get(), reading that
> entry with ptep_get() can make the permission check use the wrong PFN.
>
> Use huge_ptep_get() before decoding the hugetlb PFN.
>
> Currently there is no path which can trigger a bug: huge_ptep_get() is a
> simple ptep_get() for x86, and the prot_none walk occurs only for x86.
>
> So no need to backport - use the correct helper anyways.
>
> Fixes: 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> mm/mprotect.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 9cbf932b028cf..23779632d18bf 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
> 0 : -EACCES;
> }
>
> +#ifdef CONFIG_HUGETLB_PAGE
> static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
> unsigned long addr, unsigned long next,
> struct mm_walk *walk)
> {
> - return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
> + pte_t entry = huge_ptep_get(walk->mm, addr, pte);
Nit: can be const :)
> +
> + return pfn_modify_allowed(pte_pfn(entry),
> *(pgprot_t *)(walk->private)) ?
> 0 : -EACCES;
Indentation is odd.
Can we just make this readable?
if (pfn_modify_allowed ...)
return 0
return -EACCESS;
--
Cheers,
David
^ 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