* [PATCH] ARM: dma-mapping: Fix wrong free function in __iommu_alloc_simple() error path
From: lirongqing @ 2026-06-26 10:11 UTC (permalink / raw)
To: Russell King, Marek Szyprowski, Leon Romanovsky, Danilo Krummrich,
Matthew Wilcox, Jason Gunthorpe, Li RongQing, Kees Cook,
Douglas Anderson, Gregory CLEMENT, linux-arm-kernel, linux-kernel
From: Li RongQing <lirongqing@baidu.com>
In __iommu_alloc_simple(), when IOMMU mapping creation fails, the error
path unconditionally called __free_from_pool() regardless of the
allocation path taken.
For the COHERENT case, memory is allocated via __alloc_simple_buffer(),
which does not use the atomic pool. Calling __free_from_pool() on such
memory silently returns without freeing, causing a page memory leak.
Fix this by matching the free function to the allocation path:
- COHERENT: use __dma_free_buffer(virt_to_page(addr), size)
- non-COHERENT: use __free_from_pool(addr, size)
Fixes: 565068221b905 ("ARM: 8561/4: dma-mapping: Fix the coherent case when iommu is used")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
arch/arm/mm/dma-mapping.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f9bc53b..55d3d3b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1056,7 +1056,10 @@ static void *__iommu_alloc_simple(struct device *dev, size_t size, gfp_t gfp,
return addr;
err_mapping:
- __free_from_pool(addr, size);
+ if (coherent_flag == COHERENT)
+ __dma_free_buffer(virt_to_page(addr), size);
+ else
+ __free_from_pool(addr, size);
return NULL;
}
--
2.9.4
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-26 10:30 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <065853f5-b11b-4316-814e-202f07acb6ea@oss.qualcomm.com>
Hi Jie,
On Fri, Jun 26, 2026 at 10:03:41AM +0800, Jie Gan wrote:
[...]
> Hi Leo,
>
> To be honest, I would prefer not to modify the interconnect platform driver.
> On some Qualcomm platforms, multiple itnoc devices reside within small
> blocks(one or more than one for each block) and are connected to a dummy
> source. In such cases, two ATIDs are allocated for a path (the dummy source
> and the itnoc), which is inefficient. This is why the itnoc platform driver
> created to avoid this waste.
>
> The TraceNoC (called as AG TraceNoC) is a generic TraceNoC device which
> connected to multiple source and link devices, aggregating data from all
> source devices into a single output path.
As I said, it may be fragile to couple a specific device property (ATID)
to the AMBA driver.
You're now facing a case where a device cannot be registered as an AMBA
device, so it cannot use ATID. Likewise, I can imagine in future where a
device is registered as an AMBA device, but you don't want ATID.
> This device is implemented as an AMBA device but lacks proper hardware
> configuration. As a result, it must be handled in the driver as a
> workaround, which unfortunately breaks the original design intent.
Seems to me, it is not reasonable to pretend an AMBA device but AMBA
ID registers are absent.
How about add a new DT property ("qcom,tnoc-enable-atid") to force
enabling ATID?
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH net-next 6/9] net: sparx5: vcap: add lpm vcap implementation
From: Jens Emil Schulz Ostergaard @ 2026-06-26 10:16 UTC (permalink / raw)
To: Jakub Kicinski
Cc: horatiu.vultur, UNGLinuxDriver, andrew+netdev, davem, edumazet,
pabeni, daniel.machon, Steen.Hegelund, kees, gustavoars, netdev,
linux-kernel, linux-arm-kernel, linux-hardening
In-Reply-To: <20260615233849.1042290-1-kuba@kernel.org>
On Mon, 2026-06-15 at 16:38 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: sparx5: vcap: add lpm vcap implementation
>
> Add the implementation for the LPM VCAP for lan969x and sparx5. The LPM
> VCAP has a static keyset configuration, and a single lookup dedicated to
> LPM, so this is straight forward, and many functions can use existing
> functionality.
>
> > diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_vcap_impl.c b/drivers/net/ethernet/microchip/sparx5/sparx5_vcap_impl.c
> > index 95b93e46a41dc..e25e759c24f60 100644
> > --- a/drivers/net/ethernet/microchip/sparx5/sparx5_vcap_impl.c
> > +++ b/drivers/net/ethernet/microchip/sparx5/sparx5_vcap_impl.c
> > @@ -1083,6 +1146,46 @@ static void sparx5_vcap_es2_cache_write(struct sparx5 *sparx5,
> > }
> > }
> >
> > +static void sparx5_vcap_lpm_cache_write(struct sparx5 *sparx5,
> > + struct vcap_admin *admin,
> > + enum vcap_selection sel,
> > + u32 start,
> > + u32 count)
> > +{
> > + u32 *keystr, *mskstr, *actstr;
> > + int idx;
> > +
> > + keystr = &admin->cache.keystream[start];
> > + mskstr = &admin->cache.maskstream[start];
> > + actstr = &admin->cache.actionstream[start];
> > +
> > + switch (sel) {
> > + case VCAP_SEL_ENTRY:
> > + for (idx = 0; idx < count; ++idx) {
> > + /* Avoid 'match-off' by setting value & mask */
> > + spx5_wr(keystr[idx] & mskstr[idx], sparx5,
> > + VCAP_SUPER_VCAP_ENTRY_DAT(idx));
>
> [Severity: High]
> Are concurrent writes to the shared VCAP_SUPER_VCAP_ENTRY_DAT registers
> safe here without a global hardware lock across the different VCAP types?
>
> It looks like IS0 and IS2 rules are updated via vcap_add_rule() under the
> rtnl_lock(). However, the LPM rules are updated under the
> sparx5->router->lock inside a workqueue.
>
> Since both execution paths share the Super VCAP hardware block, could
> concurrent updates from TC (IS0/IS2) and routing (LPM) race on these shared
> cache registers, and also on VCAP_SUPER_CTRL in sparx5_vcap_super_update(),
> garbling the hardware command and corrupting the cache memory?
>
Very nice catch, I missed this. This is even reachable before this series
because the debugfs dump also uses these registers, and runs outside of
rtnl.
I will send a fix to net which replaces the per instance locks with a single
vcap_control global mutex.
> > + spx5_wr(~mskstr[idx], sparx5,
> > + VCAP_SUPER_VCAP_MASK_DAT(idx));
> > + }
> > + break;
>
> [ ... ]
>
> > @@ -1379,6 +1523,7 @@ static void sparx5_vcap_update(struct net_device *ndev,
> > struct sparx5 *sparx5 = port->sparx5;
> >
> > switch (admin->vtype) {
> > + case VCAP_TYPE_LPM:
> > case VCAP_TYPE_IS0:
> > case VCAP_TYPE_IS2:
> > sparx5_vcap_super_update(sparx5, cmd, sel, addr);
^ permalink raw reply
* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Maxime Ripard @ 2026-06-26 10:09 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJHEAWSEZR79.19UFIKS8QJBQ7@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 3421 bytes --]
On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote:
> On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
> > Hi,x
> >
> > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote:
> >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote:
> >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
> >> >> In preparation to introduce bridge hotplug, split out from
> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> dedicated function. This will be needed to be able to add (and re-add) the
> >> >> connector from different code paths.
> >> >
> >> > Same story here, explaining what you need later on that calls for that
> >> > change would be nice.
> >>
> >> Here's a more verbose version:
> >>
> >> Currently drm_bridge_connector_init() does two things:
> >>
> >> * allocate and initialize the drm_bridge_connector
> >> (which embeds a drm_connector)
> >> * initialize and register the embedded drm_connector
> >>
> >> For bridge hotplug we need to separate these two actions:
> >>
> >> * the drm_connector needs to be added and removed at any time based on
> >> hotplug events
> >> * the drm_bridge_connector is designated to create and remove the
> >> drm_connector, so it must be persistent for the card lifetime
> >>
> >> As the lifetimes of drm_bridge_connector and drm_connector become
> >> different, we need to create them in different moments.
> >>
> >> In preparation to support that, split out from
> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> dedicated function. No functional changes, just moving code around for
> >> now. A future commit will make the drm_connector be created based on
> >> hotplug events.
> >>
> >> Looks good?
> >
> > The message itself, yes, thanks.
> >
> > However, I have questions now :)
> >
> > Do we really expect drm_bridge_connector to stick around when a bridge
> > gets unplugged? If so, how does it cope with having, say, an HDMI
> > connector, and then swapping out the hotplugged part for an LVDS one?
> > Does the HDMI connector sticks around indefinitely?
>
> In your example, the HDMI drm_connector would be unregistered and put on
> hotunplug. Its allocation will stick around until the last put but that's
> quite irrelevant. Then, on plugging the LVDS addon, a new LVDS
> drm_connector will be created and registered.
>
> > *Especially* if we're using overlays for this, I'd expect everything
> > after the first hotplugged bridge to be destroyed, no?
>
> As said, it would be unregistered immediately but might be freed later on
> if still refcounted.
>
> This is visible in patches 36+15, the path to follow is:
>
> drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36]
> -> drm_bridge_connector_dynconn_release() [patch 15]
>
> Does this solve your concern?
Not really, I'm talking about drm_bridge_connector. The fact that
bridges are destroyed make sense to me. The fact that
drm_bridge_connector sticks around doesn't. It's supposed to be a
connector for bridges. If you don't have bridges because they got
destroyed, and connector, drm_bridge_connector doesn't have a reason to
exist anymore, unless it's drm_bridge_hotplug in a trench coat :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/9] net: microchip: vcap: fix rule move for rules of coprime size
From: Jens Emil Schulz Ostergaard @ 2026-06-26 10:07 UTC (permalink / raw)
To: Jakub Kicinski
Cc: horatiu.vultur, UNGLinuxDriver, andrew+netdev, davem, edumazet,
pabeni, daniel.machon, Steen.Hegelund, kees, gustavoars, netdev,
linux-kernel, linux-arm-kernel, linux-hardening
In-Reply-To: <20260615233845.1042219-1-kuba@kernel.org>
On Mon, 2026-06-15 at 16:38 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> Subject: net: microchip: vcap: fix rule move for rules of coprime size
>
> This patch addresses a discrepancy in how software and hardware move rule
> addresses on insert and delete for the LPM VCAP. It introduces a uniform
> offset computation aligned to the least common multiple of all rule sizes
> in a block. This ensures that hardware and software representations remain
> synchronized and all rules land on correctly aligned addresses.
>
> > diff --git a/drivers/net/ethernet/microchip/vcap/vcap_api.c b/drivers/net/ethernet/microchip/vcap/vcap_api.c
> > index 0fdb5e363badc..6946fd7384581 100644
> > --- a/drivers/net/ethernet/microchip/vcap/vcap_api.c
> > +++ b/drivers/net/ethernet/microchip/vcap/vcap_api.c
>
> [ ... ]
>
> > @@ -2275,8 +2336,7 @@ int vcap_add_rule(struct vcap_rule *rule)
> > __func__, __LINE__, ret);
> > goto out;
> > }
> > - if (move.count > 0)
> > - vcap_move_rules(ri, &move);
> > + vcap_move_rules(ri, &move);
> >
> > /* Set the counter to zero */
> > ret = vcap_write_counter(ri, &ctr);
>
> [Severity: High]
> This is a pre-existing issue, but does vcap_add_rule() leak the newly
> duplicated rule if operations like vcap_write_counter() or
> vcap_write_rule() fail later on?
>
> If a failure occurs, the code takes the goto out path:
>
> vcap_add_rule() {
> ...
> ret = vcap_write_rule(ri);
> if (ret) {
> pr_err("%s:%d: rule write error: %d\n", __func__, __LINE__, ret);
> goto out;
> }
> out:
> mutex_unlock(&ri->admin->lock);
> return ret;
> }
>
> This seems to exit without reverting the earlier list insertions and
> hardware moves.
>
> Could this leave the software and hardware states permanently inconsistent
> and leak the newly duplicated rule?
>
I think this is latent, and not actually reachable by current callers.
1. vcap_write_counter always returns 0
2. vcap_encode_rule can not error if vcap_val_rule is called before vcap_add_rule
3. vcap_write_rule can not error if vcap_val_rule is called before vcap_add_rule
So I propose this is fixed in seperate series.
> [ ... ]
>
> > @@ -2488,59 +2548,52 @@ int vcap_mod_rule(struct vcap_rule *rule)
> > }
> > EXPORT_SYMBOL_GPL(vcap_mod_rule);
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does vcap_mod_rule() discard
> the active software rule pointer and overwrite hardware with stale addresses?
>
> Looking at vcap_mod_rule(), the function validates the rule using
> vcap_get_locked_rule() but ignores the returned pointer:
>
> vcap_mod_rule(struct vcap_rule *rule) {
> struct vcap_rule_internal *ri = to_intrule(rule);
> ...
> if (!vcap_get_locked_rule(ri->vctrl, ri->data.id))
> return -ENOENT;
> ...
> err = vcap_encode_rule(ri);
> if (err)
> goto out;
>
> err = vcap_write_rule(ri);
> }
>
> Because the function continues to use the caller provided copy ri, it
> doesn't see updates to the real rule in the admin->rules list.
>
> If the real rule's hardware address was previously shifted due to insertions
> or deletions, could writing to the stale address in ri->addr corrupt other
> rules in the hardware VCAP?
>
This is also true but latent again. To trigger this we would need concurrency
against the same vcap instance. Before this series vcap_mod_rule was only
called under rtnl. This series introduces a call outside rtnl, but the new LPM VCAP
is not usable by tc only the routing module, which serializes everything under
one mutex.
So I think this should be fixed in a seperate series.
> [ ... ]
>
> One other pre-existing issue noticed while reviewing this subsystem:
>
> [Severity: High]
> This is a pre-existing issue, but is it safe to iterate over the admin->rules
> list across different VCAP instances without acquiring admin->lock for
> each instance?
>
> In vcap_rule_exists():
>
> static bool vcap_rule_exists(struct vcap_control *vctrl, u32 id) {
> ...
> list_for_each_entry(admin, &vctrl->list, list)
> list_for_each_entry(ri, &admin->rules, list)
> if (ri->data.id == id)
> return true;
> return false;
> }
>
> If another thread is concurrently inserting or deleting a rule on another
> VCAP instance while holding that instance's lock, could this unprotected
> concurrent access encounter a data race and dereference a poisoned pointer?
Yes this becomes reachable with this series, due to calls outside rtnl.
It is a symptom of a wider issue with the per instance locking in the VCAP
api. Sashiko found another existing bug with the shared SUPER vcap registers
also caused by this, and that one is reachable in mainline, so I will send a
fix to net for the vcap locking which will also fix this problem, then send
v2 once that is settled.
> --
> pw-bot: cr
^ permalink raw reply
* Re: [PATCH v4 00/32] pinctrl: mediatek: Enable module build support for all drivers
From: AngeloGioacchino Del Regno @ 2026-06-26 10:04 UTC (permalink / raw)
To: Justin Yeh, Sean Wang, Linus Walleij, Matthias Brugger
Cc: Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260626040112.2436185-1-justin.yeh@mediatek.com>
On 6/26/26 06:00, Justin Yeh wrote:
> Sorry for the quick v4 - v3 was sent with an incomplete cover letter
> (template placeholders) by mistake. This v4 also unifies MODULE_LICENSE
> to consistently use "GPL v2" across all patches.
>
> This series enables all MediaTek pinctrl drivers to be built as loadable
> kernel modules. This is required for Android GKI (Generic Kernel Image) +
> vendor_dlkm deployments where vendor-specific drivers must be kept separate
> from the GKI vmlinux.
>
> Each patch adds MODULE_LICENSE("GPL v2") and MODULE_DESCRIPTION() macros where
> missing, and changes the Kconfig option from bool to tristate. This allows
> these drivers to be properly packaged as vendor kernel modules while
> maintaining the existing built-in option.
>
The entire series is
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
...but I'm not sure if one commit for each is ok, makes reverting easy but that
may be too much noise. Should Linus ask for joining them all, feel free to still
keep my R-b tag, as I'd be fine with that as well.
Cheers,
Angelo
> Changes in v4:
> * Fix cover letter content (v3 accidentally sent with template placeholders)
> * Unify MODULE_LICENSE to use "GPL v2" consistently across all drivers
> * Update all commit messages to reflect "GPL v2" instead of "GPL"
>
> Changes in v3:
> * Add MODULE_DESCRIPTION() for all drivers (even those that already had MODULE_LICENSE)
> * Update commit messages to reflect that we're adding MODULE_DESCRIPTION too
>
> Changes in v2:
> * Squash MODULE_LICENSE and tristate changes into single patch per driver
> * Extend fix to all MediaTek pinctrl drivers (32 total), not just MT8189
> * Add Android GKI + vendor_dlkm context to cover letter
> * Add MODULE_DESCRIPTION() where it was missing
> * Add Fixes: tags referencing the original commits that added each driver
>
> Justin Yeh (32):
> pinctrl: mediatek: mt8189: Enable module build support
> pinctrl: mediatek: mt6878: Enable module build support
> pinctrl: mediatek: mt6893: Enable module build support
> pinctrl: mediatek: mt7622: Enable module build support
> pinctrl: mediatek: mt7981: Enable module build support
> pinctrl: mediatek: mt7986: Enable module build support
> pinctrl: mediatek: mt7988: Enable module build support
> pinctrl: mediatek: mt8167: Enable module build support
> pinctrl: mediatek: mt8173: Enable module build support
> pinctrl: mediatek: mt8183: Enable module build support
> pinctrl: mediatek: mt8186: Enable module build support
> pinctrl: mediatek: mt8188: Enable module build support
> pinctrl: mediatek: mt8192: Enable module build support
> pinctrl: mediatek: mt8195: Enable module build support
> pinctrl: mediatek: mt8196: Enable module build support
> pinctrl: mediatek: mt8365: Enable module build support
> pinctrl: mediatek: mt8516: Enable module build support
> pinctrl: mediatek: mt2701: Enable module build support
> pinctrl: mediatek: mt7623: Enable module build support
> pinctrl: mediatek: mt7629: Enable module build support
> pinctrl: mediatek: mt8135: Enable module build support
> pinctrl: mediatek: mt8127: Enable module build support
> pinctrl: mediatek: mt7620: Enable module build support
> pinctrl: mediatek: mt7621: Enable module build support
> pinctrl: mediatek: mt76x8: Enable module build support
> pinctrl: mediatek: rt2880: Enable module build support
> pinctrl: mediatek: rt305x: Enable module build support
> pinctrl: mediatek: rt3883: Enable module build support
> pinctrl: mediatek: mt6397: Enable module build support
> pinctrl: mediatek: mt2712: Enable module build support
> pinctrl: mediatek: mt6795: Enable module build support
> pinctrl: mediatek: mt6797: Enable module build support
>
> drivers/pinctrl/mediatek/Kconfig | 64 +++++++++++------------
> drivers/pinctrl/mediatek/pinctrl-mt2701.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt2712.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt6397.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt6795.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt6797.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt6878.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt6893.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt7620.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7621.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7622.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7623.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7629.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt76x8.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7981.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7986.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7988.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8127.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8135.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8167.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8173.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8183.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8186.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8188.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8189.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8192.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8195.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8196.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8365.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8516.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-rt2880.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-rt305x.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-rt3883.c | 3 ++
> 33 files changed, 114 insertions(+), 32 deletions(-)
>
^ permalink raw reply
* [ANNOUNCEMENT] LPC 2026: System Monitoring and Observability Microconference
From: Breno Leitao @ 2026-06-26 9:56 UTC (permalink / raw)
To: linux-acpi, linux-hwmon, netdev, linux-kernel, linux-arm-kernel,
kernel-team, linux-mm
Cc: Breno Leitao, kerneljasonxing, iipeace5, gavinguo, linux,
amscanne, sj, gpiccoli, Daniel Gomez, mfo, platform-driver-x86,
acpica-devel
We are pleased to announce the Call for Proposals (CFP) for another
edition of System Monitoring and Observability Microconference, this
time at the 2026 Linux Plumbers Conference (LPC), taking place in
Prague, Czechia, from Oct 5-7, 2026.
https://lpc.events/event/20/sessions/262/
This microconference provides a valuable forum for key engineering areas
such as:
- Kernel Health and Runtime Monitoring
- Hardware Integration and Error Detection
- Correlation of Issues (crashes, stalls, bugs)
- Virtualization Stack Monitoring
- Memory Management Monitoring and Observability
- Anomaly Detection Algorithms for System Behavior
- Automated Analysis, Remediation and post mortem analyzes
The purpose of each talk is to share challenges and discuss potential
improvements. Sessions will last 20 to 30 minutes and aim to encourage
brainstorming and open dialogue about ongoing issues rather than
delivering immediate solutions.
The conference acts as both a knowledge-sharing platform and a strategic
venue for guiding the future of kernel technologies to better meet the
demands of large-scale infrastructure.
We invite you to submit your proposals here:
https://lpc.events/event/20/abstracts/
Please select track "Linux System Monitoring and Observability MC"
^ permalink raw reply
* Re: [PATCH v3 0/4] soc: amlogic: clk-measure: add A1 and T7 support
From: Jian Hu @ 2026-06-26 9:54 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Conor Dooley
In-Reply-To: <20260421-clkmsr_a1_t7-v3-0-efc00b0f9e6b@amlogic.com>
Hi Neil,
On 4/21/2026 4:17 PM, Jian Hu via B4 Relay wrote:
> [ EXTERNAL EMAIL ]
>
> This series adds Amlogic clock measurement support for A1 and T7 SoCs,
> including binding updates, driver additions, and device tree enablement.
Gentle ping. The patches have received review, could you please take
another look when you have time?
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> Changes in v3:
> - Place the clock-measure node after pwm_ao_gh node for t7.
> - Link to v2: https://lore.kernel.org/r/20260415-clkmsr_a1_t7-v2-0-02b6314427e6@amlogic.com
>
> Changes in v2:
> - Add const for a1 and t7 clock measure table.
> - Use b4 to send this series.
> - Link to v1: https://lore.kernel.org/all/20260410100329.3167482-1-jian.hu@amlogic.com
>
> ---
> Jian Hu (4):
> dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
> soc: amlogic: clk-measure: Add A1 and T7 support
> arm64: dts: meson: a1: Add clk measure support
> arm64: dts: amlogic: t7: Add clk measure support
>
> .../soc/amlogic/amlogic,meson-gx-clk-measure.yaml | 2 +
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +
> arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 5 +
> drivers/soc/amlogic/meson-clk-measure.c | 272 +++++++++++++++++++++
> 4 files changed, 284 insertions(+)
> ---
> base-commit: 401e5c73eedde8225e87bd11c794b8409248ff41
> change-id: 20260415-clkmsr_a1_t7-9820984d0af1
>
> Best regards,
> --
> Jian Hu <jian.hu@amlogic.com>
>
>
^ permalink raw reply
* Re: [RFC] drm/imx: upstream direction for i.MX95 display support
From: Liu Ying @ 2026-06-26 9:53 UTC (permalink / raw)
To: Piyush Patle
Cc: dri-devel, imx, linux-arm-kernel, marex, daniel.baluta, Frank.Li,
shawnguo, tzimmermann, maarten.lankhorst, mripard, airlied,
simona
In-Reply-To: <20260624100326.413699-1-piyushpatle228@gmail.com>
On Wed, Jun 24, 2026 at 03:33:18PM +0530, Piyush Patle wrote:
[...]
> The current dc/ implementation is a multi-device component driver with one
> platform_driver per block bound via the component framework. The downstream
> i.MX95 driver is a single monolithic platform_driver mapping all blocks from
> one register base. Unifying appears to require reconciling two bind models,
> rather than only adding match_data.
I think that upstream i.MX95 display controller driver would also be based
on the component helper. That's something for sure.
[...]
> There is also anticipated divergence which is not yet upstream (i.MX8QXP
> prefetch/PRG, LTS and tiling modifiers, and the downstream i.MX95 blit
> engine), although mainline dc/ is KMS-only today.
Just want to point out that I sent out v5 patch set[2] to add i.MX8QXP
prefetch engine(DPRC + PRG) support for KMS. That changes the driver's
mode setting code a lot.
[2] https://lore.kernel.org/all/20251027-imx8-dc-prefetch-v5-0-4ecb6c6d4941@nxp.com/
[...]
> One question for Liu Ying is whether the separate-driver plus shared
> helper-library approach is still the preferred direction, and where the
> helper boundary would be drawn (which blocks/ops are shared versus
> implemented per driver).
Yes, separate DRM drivers + a helper library approach is still the direction
I want. I think that the drivers and library would sit in the same
directory drivers/gpu/drm/imx/dc/.
The purpose to add a library is to share code to reduce overall code lines.
I'd assume that shared blocks or common part of slightly different blocks
should be covered by the library.
[...]
> how the component and monolithic driver models
> would be reconciled given the differences described above.
Like I said above, I don't think upstream driver would be monolithic.
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v3 00/15] drm/tidss: Add BeagleY-AI display support (and some more)
From: Shubham @ 2026-06-26 9:49 UTC (permalink / raw)
To: tomi.valkeinen
Cc: a-bhatia1, afd, airlied, aradhya.bhatia, conor+dt, devarsht,
devicetree, dri-devel, j-choudhary, krzk+dt, lee,
linux-arm-kernel, linux-kernel, louis.chauvet, maarten.lankhorst,
mripard, nm, robertcnelson, robh, s-jain1, simona, tzimmermann,
vigneshr
In-Reply-To: <20260529-beagley-ai-display-v3-0-7fefdc5d1adf@ideasonboard.com>
Hi Tomi,
A big update on the Raspberry Pi Touch Display 2 (5-inch, native ILI9881C
MIPI-DSI, 720x1280, 2 lanes) bring-up on BeagleY-AI (AM67A/J722S), still on
Robert's v7.0.x-arm64-k3 tree (7.0.11-arm64-k3-r20): tidss + cdns-dsi +
cdns-dphy, DSS = ti,am62p-dss (dispc_am625_feats).
The earlier "tidss comes up before the DSI bridge is added" problem is
resolved (cdns-dsi now adds its input bridge in probe, so tidss attaches it),
and after fixing two more issues the panel is now alive -- but I'm stuck on
one last step and would value your read.
What is now confirmed working
-----------------------------
- DSI-1 connector is created, tidss initializes, no probe errors, nothing
left in /sys/kernel/debug/devices_deferred.
- The panel is ALIVE and initialized: a DCS read of GET_POWER_MODE (0x0A)
returns 0x9c (booster on, sleep-out, display-on). So the LP command path
over the cdns works and the ILI9881C processed its init sequence.
- cdns-dsi looks healthy while a test pattern streams:
MCTL_MAIN_STS = 0x0000000F (PLL_LOCKED + CLK_LANE_RDY + DATA_LANE_RDY 0/1)
MCTL_DPHY_ERR = 0x00000000 (no D-PHY errors)
VID_MODE_STS = 0x00000001 (VSG_RUNNING, no error bits)
MCTL_LANE_STS -> clock lane in HS
VID_MAIN_CTL = 0x80A0FE00 (RGB888, packed-pixel DT 0x3E)
VID_HSIZE2 hact = 2160 (720*3), VID_VSIZE2 vact = 1280
cdns-dphy PLL locks (no "Failed to lock PLL").
- The DSS is scanning out:
modetest -M tidss -s <dsi>@<crtc>:720x1280 -v -> steady 60.01 Hz.
(For reference, the two fixes that got the panel this far were: nesting the
DSS port@1 under the controller's "ports" node in my overlay, and correcting
the BeagleY-AI MIPI mux OE polarity -- it is active-low, and the data-lane
mux had been left disabled while i2c still worked through a separate path.)
The problem: cdns data lanes never transmit
-------------------------------------------
Sampling MCTL_LANE_STS 20000 times while the pattern is actively streaming
(modetest -v at 60 Hz, from a second session):
DATA0 states: {'IDLE': 20000}
DATA1 states: {'IDLE': 20000}
So the clock lane is in HS and the VSG reports "running", but the data lanes
are 100% IDLE -- the cdns is in video mode yet never emits pixel packets.
The DSS VP does not appear to feed the cdns DPI input even though the VP
timing generator runs at 60 Hz, and the panel (correctly initialized) just
shows backlight, no image.
What I have ruled out
---------------------
- Videoport selection: I tried the DSI on DSS port@1 (VP2 = DISPC_VP_DPI)
and on DSS port@0 (VP1 = DISPC_VP_INTERNAL). Identical result, data lanes
IDLE in both.
- tidss correctly treats the cdns as internal: the bridge of_node
compatible "ti,j721e-dsi" is in tidss_internal_bridge_compatibles[], so
dpi_output is false and it does not touch ti,am625-dss-dpi0-clk-ctrl for
this videoport.
- Overlay/graph: cdns DSI_OUTPUT_PORT=0 (panel) / DSI_INPUT_PORT=1 (DSS)
wired accordingly; panel attaches; no -ENODEV; VID timing is correct.
Questions
---------
1. On AM67A/J722S, what internally connects a DSS video port's DPI to the
cdns-dsi DPI input, and is there a clock/enable/routing step (beyond the
DT graph and dpi0-clk-ctrl, which tidss skips for the internal path)
required for the DSS to actually feed the cdns?
2. Which DSS VP is wired to the internal DSI on this SoC (VP1/INTERNAL vs
VP2/DPI), and does the DISPC_VP_INTERNAL path need any handling that the
DISPC_VP_DPI path does not get?
3. Any reason the cdns VSG would report VSG_RUNNING with the clock lane in
HS and both data lanes "ready", yet never drive the data lanes (no pixel
packets) while the DSS VP is visibly scanning at 60 Hz?
I'm happy to share the full overlay, dmesg and register dumps, and to test
patches.
Thanks,
Shubham
^ permalink raw reply
* Re: [PATCH v3 2/3] selftests/resctrl: Replace counter index references with pointers
From: wuyifan @ 2026-06-26 9:41 UTC (permalink / raw)
To: Reinette Chatre, tony.luck, Dave.Martin, james.morse, babu.moger,
shuah, tan.shaopeng, fenghuay, ben.horgan, zengheng4,
linux-kernel, linux-arm-kernel, linux-kselftest, linuxarm
Cc: xiaqinxin, prime.zeng, wangyushan12, xuwei5, fanghao11, wangzhou1
In-Reply-To: <77d30d2d-91db-456e-bf41-2cc31165bd2d@intel.com>
Hi Reinette,
Thanks for the review.
On 6/26/2026 6:14 AM, Reinette Chatre wrote:
> On 5/22/26 2:05 AM, Yifan Wu wrote:
>> Replace direct counter number references with pointers to remove the
>> dependency on fixed array indexing and enable the use of different
>> data structures for counter management.
>>
>> Signed-off-by: Yifan Wu<wuyifan50@huawei.com>
>> ---
> Please improve readibility here by moving the above two lines up while ensuring alignment with
> open parenthesis. Specifically:
> imc_counter->fd = perf_event_open(&imc_counter->pe, -1, cpu_no, -1,
> PERF_FLAG_FD_CLOEXEC);
> ...
>
> With the style fixups:
> | Reviewed-by: Reinette Chatre<reinette.chatre@intel.com>
>
> Reinette
I will fix that.
Thanks,
Yifan
^ permalink raw reply
* Re: [PATCH v3 2/2] ARM: mm: protect show_pte() in do_DataAbort() fallback path
From: Russell King @ 2026-06-26 9:45 UTC (permalink / raw)
To: Qi Xi
Cc: Andrew Morton, linux-arm-kernel, linux-kernel, Yuanbin Xie,
Nanyong Sun
In-Reply-To: <20260626073048.3595106-3-xiqi2@huawei.com>
On Fri, Jun 26, 2026 at 03:30:48PM +0800, Qi Xi wrote:
> The do_DataAbort() fallback path handles FSR types not serviced by
> do_page_fault() (fsr_info entries with fn=do_bad). This path also
> calls show_pte() without holding mmap_read_lock, exposing it to
> the same use-after-free issue.
>
> Since do_DataAbort() is an exception entry point that can be reached
> from contexts where sleeping is not allowed, use mmap_read_trylock().
> If the lock cannot be acquired, the page table dump is skipped.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Suggested-by: Yuanbin Xie <xieyuanbin1@huawei.com>
> Signed-off-by: Qi Xi <xiqi2@huawei.com>
Same reason as patch 1. We can't take locks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v3 1/2] ARM: mm: fix use-after-free in __do_user_fault() under CONFIG_DEBUG_USER
From: Russell King @ 2026-06-26 9:44 UTC (permalink / raw)
To: Qi Xi
Cc: Andrew Morton, linux-arm-kernel, linux-kernel, Yuanbin Xie,
Nanyong Sun
In-Reply-To: <20260626073048.3595106-2-xiqi2@huawei.com>
On Fri, Jun 26, 2026 at 03:30:47PM +0800, Qi Xi wrote:
> When CONFIG_DEBUG_USER is enabled with user_debug=31 on 32-bit ARM,
> a user page fault triggers show_pte() via __do_user_fault() after
> do_page_fault() has already released mmap_read_lock. If another
> thread concurrently calls munmap(), the page table pages can be
> freed while show_pte() is still reading them, causing a
> use-after-free in show_pte().
>
> The race can be reproduced on multi_v7_defconfig with:
> CONFIG_DEBUG_USER=y
> CONFIG_ARM_LPAE=y
> kernel command line: user_debug=31
>
> A delay inserted in show_pte() for testing widens the race window and
> makes the UAF reliably reproducible. On LPAE, the race works as
> follows:
>
> CPU 0 (fault path) CPU 1 (munmap)
> munmap(page 0) -> clears PTE[0]
> PTE/PMD pages remain
>
> read page 0 -> page fault
> -> do_DataAbort()
> -> do_page_fault()
> -> lock_mm_and_find_vma() -> no VMA
> (mmap_read_lock released)
> -> __do_user_fault()
> -> show_pte(tsk->mm, addr)
> -> *pgd (valid)
> -> p4d/pud checks pass
>
> -> [delay] munmap(page 1)
> -> clears PTE[1]
> -> PTE/PMD pages freed
> -> PGD cleared
>
> -> pmd_offset(pud, addr)
> -> *pud=0 -> __va(0)
> -> dereference
> -> secondary data abort (kernel)
>
> Fix by taking mmap_read_lock() around show_pte() in __do_user_fault().
> __do_user_fault() is called from process context with interrupts
> enabled, so the context can sleep and mmap_read_lock() is safe here.
This is a fault path which should only be called when something is
already wrong, the mm lock may already be held (e.g. a kernel
fault while already holding the mmap lock.) We can't take any locks
here.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v3 3/3] selftests/resctrl: Enable dynamic management of IMC counters via linked list
From: wuyifan @ 2026-06-26 9:43 UTC (permalink / raw)
To: Reinette Chatre, tony.luck, Dave.Martin, james.morse, babu.moger,
shuah, tan.shaopeng, fenghuay, ben.horgan, zengheng4,
linux-kernel, linux-arm-kernel, linux-kselftest, linuxarm
Cc: xiaqinxin, prime.zeng, wangyushan12, xuwei5, fanghao11, wangzhou1
In-Reply-To: <8b51dca5-d1fe-492d-8d54-7709aee4a6c5@intel.com>
Hi Reinette,
On 6/26/2026 6:14 AM, Reinette Chatre wrote:
> With fixup applied and nit addressed:
> | Reviewed-by: Reinette Chatre<reinette.chatre@intel.com>
>
> Reinette
Thanks for the review. I will fix that.
Thanks,
Yifan
^ permalink raw reply
* Re: [PATCH 0/3] KVM: arm64: nv: Shadow ptdump fixes
From: Wei-Lin Chang @ 2026-06-26 9:37 UTC (permalink / raw)
To: Marc Zyngier
Cc: Itaru Kitayama, linux-arm-kernel, kvmarm, linux-kernel,
Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <86h5mrq71b.wl-maz@kernel.org>
On Thu, Jun 25, 2026 at 10:54:40AM +0100, Marc Zyngier wrote:
> On Thu, 25 Jun 2026 08:47:04 +0100,
> Wei-Lin Chang <weilin.chang@arm.com> wrote:
> >
> > I don't see a way out with this per-mmu file scheme. The core issue is
> > mmus have a different lifetime than the VM's debugfs directory, and
> > both's removal can happen in parallel, i.e. the VM debugfs directory
> > can be removed anytime we are in mmu notifier release freeing the mmus
> > and their shadow ptdump files.
>
> Why isn't that a problem with the existing S2 ptdump code?
For existing stuff, in terms of the ptdump files:
- For the canonical s2, the ptdump files are only removed in
kvm_destroy_vm_debugfs().
- For nested s2, files are removed in two places: "manually" removed
at mmu<->context unbind time in get_s2_mmu_nested() and in
kvm_destroy_vm_debugfs(). get_s2_mmu_nested() is only called before
kvm_destroy_vm_debugfs() of course.
So no dentry UAF in the current code.
Putting everything together, the situation is pretty complicated. The
canonical mmu, nested mmu, canonical mmu->pgt, nested mmu->pgt all have
different lifetimes, and kvm_destroy_vm_debugfs() can run in parallel
with mmu notifier release (like said above), which frees nested mmus and
canonical + nested pgts. Additionally, the .show() callback can be
called after mmu notifier release (Sashiko).
Now having thought about this again, per-mmu file can work, just defend
against freed mmu or pgt.
What I'm thinking now:
- Just have all ptdump files removed at kvm_destroy_vm_debugfs(), to
avoid accessing the dentry in mmu notifier release.
- Revert effects of 204f7c018d76 ("KVM: arm64: ptdump: Make KVM ptdump
code s2 mmu aware") because the mmu pointer stored in i_private and
the ptdump state is simply invalid after mmu notifier release for
nested.
- Only store the kvm pointer in inode->i_private or seq_file->private.
- For nested, check both mmu and mmu->pgt in .show() under the
mmu_lock. For canonical only mmu->pgt check will be needed.
- Guard nested_mmus freeing and setting nested_mmus = NULL with the
mmu_lock so .show() won't have nested mmus disappear after checking
nested_mmus exist.
I *think* this solves all problems known at the moment...
Thanks,
Wei-Lin Chang
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Icenowy Zheng @ 2026-06-26 9:33 UTC (permalink / raw)
To: Conor Dooley
Cc: Conor Dooley, Joey Lu, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626-everybody-epilogue-8fb298a54981@wendy>
在 2026-06-26五的 10:26 +0100，Conor Dooley写道：
> On Fri, Jun 26, 2026 at 05:00:35PM +0800, Icenowy Zheng wrote:
> > 在 2026-06-26五的 08:19 +0100，Conor Dooley写道：
> > > On Fri, Jun 26, 2026 at 01:27:21PM +0800, Icenowy Zheng wrote:
> > > > 在 2026-06-25四的 17:33 +0100，Conor Dooley写道：
> > > > > On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> > > > > > +allOf:
> > > > > > + - if:
> > > > > > + properties:
> > > > > > + compatible:
> > > > > > + contains:
> > > > > > + const: thead,th1520-dc8200
> > > > > > + then:
> > > > > > + properties:
> > > > > > + clocks:
> > > > > > + minItems: 5
> > > > > > + maxItems: 5
> > > > > > +
> > > > > > + clock-names:
> > > > > > + minItems: 5
> > > > > > + maxItems: 5
> > > > >
> > > > > All the maxItems here repeat the maximum constraint and do
> > > > > nothing.
> > > > >
> > > > > Since you didn't change the minimum constraint at the top
> > > > > level,
> > > > > your
> > > > > minItems also do nothing.
> > > > >
> > > > > > +
> > > > > > + resets:
> > > > > > + minItems: 3
> > > > > > + maxItems: 3
> > > > > > +
> > > > > > + reset-names:
> > > > > > + minItems: 3
> > > > > > + maxItems: 3
> > > > > > +
> > > > > > + required:
> > > > > > + - resets
> > > > > > + - reset-names
> > > > >
> > > > > Both conditional sections have this, but the original binding
> > > > > doesn't
> > > > > require these for the thead device. This is a functional
> > > > > change
> > > > > therefore and shouldn't be in a patch calling itself
> > > > > "generalise
> > > > > for
> > > > > single ended variants".
> > > >
> > > > Well yes they're required.
> > > >
> > > > Should I send a patch adding the `thead,th1520-dc8200` part of
> > > > the
> > > > schema?
> > >
> > > If you mean the code above, no. Adding a conditional section when
> > > there's only that compatible doesn't make sense.
> > >
> > > What you could do is just add it at the top level though, which
> > > would
> > > also benefit this patch since it'd not have to be conditionally
> > > added
> > > for the new nuvoton device.
> > > Just note in your commit message about what the ABI impact of the
> > > change
> > > to required properties is (effectively nothing because it's
> > > optional
> > > in
> > > the driver and the only user has the properties).
> >
> > Okay, I will craft such a patch and send it.
> >
> > >
> > > > > > +
> > > > > > + resets:
> > > > > > + minItems: 1
> > > > > > + maxItems: 1
> > > > > > +
> > > > > > + reset-names:
> > > > > > + items:
> > > > > > + - const: core
> > > > >
> > > > > This is just maxItems: 1.
> > > >
> > > > Well the implicit rules of DT binding schemas are quite
> > > > weird...
> > >
> > > I don't think it is that strange, as the binding has
> > > reset-names:
> > > items:
> > > - const: core
> > > - const: axi
> > > - const: ahb
> >
> > Ah does the list constraint the order of items? If it constrains
> > the
>
> It does, yes.
> Alternatively, using an enum permits free ordering.
Ah in this case this should be converted to an enum, I think.
Should I send a patch for converting it?
Thanks,
Icenowy
>
> > order, it partly breaks the intention of having names; if it does
> > not
> > constrain the order, it needs to be clarified that the required 1
> > reset
> > is core instead of the other two.
>
> Given the discussion we're having on the clocks, I wonder if this is
> also an oversimplification and the IP has three resets inputs hooked
> up
> to one output of the reset controller (or 3 outputs controlled by one
> bit..).
^ permalink raw reply
* [PATCH v3 3/3] dmaengine: xilinx_dma: Optimize control register write and channel start logic for AXIDMA and MCDMA in corresponding start_transfer()
From: Suraj Gupta @ 2026-06-26 9:26 UTC (permalink / raw)
To: vkoul, Frank.Li, michal.simek, dev
Cc: dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626092656.1563871-1-suraj.gupta2@amd.com>
Optimize AXI DMA control register programming by consolidating
coalesce count and delay configuration into a single register write.
Previously, the coalesce count was written separately from the delay
configuration, resulting in two register writes. Combine these into
one write operation to reduce bus overhead.
Additionally, avoid redundant channel starts in xilinx_dma_start_transfer()
and xilinx_mcdma_start_transfer() by only calling xilinx_dma_start() when
the channel is actually idle.
Tested-by: Folker Schwesinger <dev@folker-schwesinger.de>
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
---
drivers/dma/xilinx/xilinx_dma.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 6e7b183cb499..829601d8a16f 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -1603,7 +1603,6 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
reg &= ~XILINX_DMA_CR_COALESCE_MAX;
reg |= chan->desc_pendingcount <<
XILINX_DMA_CR_COALESCE_SHIFT;
- dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
}
if (chan->has_sg && list_empty(&chan->active_list))
@@ -1614,7 +1613,8 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
reg |= XILINX_DMA_DMAXR_ALL_IRQ_MASK;
dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
- xilinx_dma_start(chan);
+ if (chan->idle)
+ xilinx_dma_start(chan);
if (chan->err)
return;
@@ -1703,7 +1703,8 @@ static void xilinx_mcdma_start_transfer(struct xilinx_dma_chan *chan)
reg |= XILINX_MCDMA_CR_RUNSTOP_MASK;
dma_ctrl_write(chan, XILINX_MCDMA_CHAN_CR_OFFSET(chan->tdest), reg);
- xilinx_dma_start(chan);
+ if (chan->idle)
+ xilinx_dma_start(chan);
if (chan->err)
return;
--
2.25.1
^ permalink raw reply related
* [PATCH v3 1/3] dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers
From: Suraj Gupta @ 2026-06-26 9:26 UTC (permalink / raw)
To: vkoul, Frank.Li, michal.simek, dev
Cc: dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626092656.1563871-1-suraj.gupta2@amd.com>
Fix a race condition in AXIDMA and MCDMA irq handlers where the channel
could be incorrectly marked as idle and attempt spurious transfers when
descriptors are still being processed.
The issue occurs when:
1. Multiple descriptors are queued and active.
2. An interrupt fires after completing some descriptors.
3. xilinx_dma_complete_descriptor() moves completed descriptors to
done_list.
4. Channel is marked idle and start_transfer() is called even though
active_list still contains unprocessed descriptors.
5. This leads to premature transfer attempts and potential descriptor
corruption or missed completions.
Only mark the channel as idle and start new transfers when the active list
is actually empty, ensuring proper channel state management and avoiding
spurious transfer attempts.
Fixes: c0bba3a99f07 ("dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine")
Tested-by: Folker Schwesinger <dev@folker-schwesinger.de>
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
---
drivers/dma/xilinx/xilinx_dma.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 404235c17353..ca396b709742 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -1893,8 +1893,10 @@ static irqreturn_t xilinx_mcdma_irq_handler(int irq, void *data)
if (status & XILINX_MCDMA_IRQ_IOC_MASK) {
spin_lock(&chan->lock);
xilinx_dma_complete_descriptor(chan);
- chan->idle = true;
- chan->start_transfer(chan);
+ if (list_empty(&chan->active_list)) {
+ chan->idle = true;
+ chan->start_transfer(chan);
+ }
spin_unlock(&chan->lock);
}
@@ -1950,8 +1952,10 @@ static irqreturn_t xilinx_dma_irq_handler(int irq, void *data)
XILINX_DMA_DMASR_DLY_CNT_IRQ)) {
spin_lock(&chan->lock);
xilinx_dma_complete_descriptor(chan);
- chan->idle = true;
- chan->start_transfer(chan);
+ if (list_empty(&chan->active_list)) {
+ chan->idle = true;
+ chan->start_transfer(chan);
+ }
spin_unlock(&chan->lock);
}
--
2.25.1
^ permalink raw reply related
* [PATCH v3 2/3] dmaengine: xilinx_dma: Enable transfer chaining for AXIDMA and MCDMA by removing idle restriction
From: Suraj Gupta @ 2026-06-26 9:26 UTC (permalink / raw)
To: vkoul, Frank.Li, michal.simek, dev
Cc: dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626092656.1563871-1-suraj.gupta2@amd.com>
Relax the idle check in xilinx_dma_start_transfer() and
xilinx_mcdma_start_transfer() that prevented new transfers from being
queued when the channel was busy, so scatter-gather transfers can be
chained onto an in-flight transfer.
In scatter-gather mode, only update the CURDESC register when the active
list is empty to avoid interfering with transfers already in progress.
When the active list contains transfers, the hardware tail pointer
extension mechanism handles chaining automatically via the descriptor
next pointer chain, which is set up at channel allocation and preserved
across descriptor recycling.
Direct (non-SG) mode has no descriptor queue: writing the BTT register
launches a transfer immediately, so a new transfer must not be programmed
while one is in flight. Keep those transfers serialized by retaining the
idle check on the non-SG path. MCDMA always operates in scatter-gather
mode, so it is unaffected.
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
---
drivers/dma/xilinx/xilinx_dma.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index ca396b709742..6e7b183cb499 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -1580,7 +1580,14 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
return;
}
- if (!chan->idle)
+ /*
+ * Direct (non-SG) mode has no descriptor queue: writing the BTT
+ * register launches a transfer immediately, so a new transfer must
+ * not be programmed while one is in flight. Keep such transfers
+ * serialized. SG mode supports chaining onto a running transfer via
+ * tail-pointer extension, so it is allowed to proceed when busy.
+ */
+ if (!chan->has_sg && !chan->idle)
return;
head_desc = list_first_entry(&chan->pending_list,
@@ -1599,7 +1606,7 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
}
- if (chan->has_sg)
+ if (chan->has_sg && list_empty(&chan->active_list))
xilinx_write(chan, XILINX_DMA_REG_CURDESC,
head_desc->async_tx.phys);
reg &= ~XILINX_DMA_CR_DELAY_MAX;
@@ -1660,9 +1667,6 @@ static void xilinx_mcdma_start_transfer(struct xilinx_dma_chan *chan)
if (chan->err)
return;
- if (!chan->idle)
- return;
-
if (list_empty(&chan->pending_list))
return;
@@ -1685,8 +1689,9 @@ static void xilinx_mcdma_start_transfer(struct xilinx_dma_chan *chan)
dma_ctrl_write(chan, XILINX_MCDMA_CHAN_CR_OFFSET(chan->tdest), reg);
/* Program current descriptor */
- xilinx_write(chan, XILINX_MCDMA_CHAN_CDESC_OFFSET(chan->tdest),
- head_desc->async_tx.phys);
+ if (chan->has_sg && list_empty(&chan->active_list))
+ xilinx_write(chan, XILINX_MCDMA_CHAN_CDESC_OFFSET(chan->tdest),
+ head_desc->async_tx.phys);
/* Program channel enable register */
reg = dma_ctrl_read(chan, XILINX_MCDMA_CHEN_OFFSET);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-26 9:26 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Conor Dooley, Joey Lu, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <c0731801729713d35f97bec40ebc21cef31b72b5.camel@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 3675 bytes --]
On Fri, Jun 26, 2026 at 05:00:35PM +0800, Icenowy Zheng wrote:
> 在 2026-06-26五的 08:19 +0100，Conor Dooley写道：
> > On Fri, Jun 26, 2026 at 01:27:21PM +0800, Icenowy Zheng wrote:
> > > 在 2026-06-25四的 17:33 +0100，Conor Dooley写道：
> > > > On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> > > > > +allOf:
> > > > > + - if:
> > > > > + properties:
> > > > > + compatible:
> > > > > + contains:
> > > > > + const: thead,th1520-dc8200
> > > > > + then:
> > > > > + properties:
> > > > > + clocks:
> > > > > + minItems: 5
> > > > > + maxItems: 5
> > > > > +
> > > > > + clock-names:
> > > > > + minItems: 5
> > > > > + maxItems: 5
> > > >
> > > > All the maxItems here repeat the maximum constraint and do
> > > > nothing.
> > > >
> > > > Since you didn't change the minimum constraint at the top level,
> > > > your
> > > > minItems also do nothing.
> > > >
> > > > > +
> > > > > + resets:
> > > > > + minItems: 3
> > > > > + maxItems: 3
> > > > > +
> > > > > + reset-names:
> > > > > + minItems: 3
> > > > > + maxItems: 3
> > > > > +
> > > > > + required:
> > > > > + - resets
> > > > > + - reset-names
> > > >
> > > > Both conditional sections have this, but the original binding
> > > > doesn't
> > > > require these for the thead device. This is a functional change
> > > > therefore and shouldn't be in a patch calling itself "generalise
> > > > for
> > > > single ended variants".
> > >
> > > Well yes they're required.
> > >
> > > Should I send a patch adding the `thead,th1520-dc8200` part of the
> > > schema?
> >
> > If you mean the code above, no. Adding a conditional section when
> > there's only that compatible doesn't make sense.
> >
> > What you could do is just add it at the top level though, which would
> > also benefit this patch since it'd not have to be conditionally added
> > for the new nuvoton device.
> > Just note in your commit message about what the ABI impact of the
> > change
> > to required properties is (effectively nothing because it's optional
> > in
> > the driver and the only user has the properties).
>
> Okay, I will craft such a patch and send it.
>
> >
> > > > > +
> > > > > + resets:
> > > > > + minItems: 1
> > > > > + maxItems: 1
> > > > > +
> > > > > + reset-names:
> > > > > + items:
> > > > > + - const: core
> > > >
> > > > This is just maxItems: 1.
> > >
> > > Well the implicit rules of DT binding schemas are quite weird...
> >
> > I don't think it is that strange, as the binding has
> > reset-names:
> > items:
> > - const: core
> > - const: axi
> > - const: ahb
>
> Ah does the list constraint the order of items? If it constrains the
It does, yes.
Alternatively, using an enum permits free ordering.
> order, it partly breaks the intention of having names; if it does not
> constrain the order, it needs to be clarified that the required 1 reset
> is core instead of the other two.
Given the discussion we're having on the clocks, I wonder if this is
also an oversimplification and the IP has three resets inputs hooked up
to one output of the reset controller (or 3 outputs controlled by one
bit..).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v3 0/3] dmaengine: xilinx_dma: Fixes and optimizations for AXIDMA and MCDMA channel management
From: Suraj Gupta @ 2026-06-26 9:26 UTC (permalink / raw)
To: vkoul, Frank.Li, michal.simek, dev
Cc: dmaengine, linux-arm-kernel, linux-kernel
This patch series addresses issues and optimizations in the Xilinx
AXI DMA and MCDMA drivers:
1. Fix channel idle state management in the interrupt handlers.
2. Enable transfer chaining by removing unnecessary idle restrictions.
3. Optimize control register writes and channel start logic.
Note: The patches in this series were part of following IRQ coalescing
series which is under discussion:
https://lore.kernel.org/all/20250710101229.804183-1-suraj.gupta2@amd.com/
Changes in V3:
- Patch 2: Restrict the idle-check removal to scatter-gather mode. Direct
(non-SG) mode has no descriptor queue, so writing the BTT register while
a transfer is in flight would corrupt the active transfer; keep those
transfers serialized by retaining the idle check on the non-SG path.
MCDMA always operates in scatter-gather mode and is unaffected. Update
the commit description accordingly.
Changes in V2:
- Apply similar fixes and optimizations to MCDMA as well.
- Expand the 1/3 commit description with when the described issue occurs.
Suraj Gupta (3):
dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and
MCDMA interrupt handlers
dmaengine: xilinx_dma: Enable transfer chaining for AXIDMA and MCDMA
by removing idle restriction
dmaengine: xilinx_dma: Optimize control register write and channel
start logic for AXIDMA and MCDMA in corresponding start_transfer()
drivers/dma/xilinx/xilinx_dma.c | 38 +++++++++++++++++++++------------
1 file changed, 24 insertions(+), 14 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH v6 7/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
From: Sebastian Ene @ 2026-06-26 9:24 UTC (permalink / raw)
To: Will Deacon
Cc: catalin.marinas, maz, oupton, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <aj5CMsyQ25xuxISV@willie-the-truck>
On Fri, Jun 26, 2026 at 10:11:14AM +0100, Will Deacon wrote:
> On Fri, Jun 26, 2026 at 07:45:45AM +0000, Sebastian Ene wrote:
> > Introduce a helper method ffa_check_unused_args_sbz to enforce strict
> > arguments checking when the hypervisor acts as a relayer between the
> > host and Trustzone.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 96 ++++++++++++++++++++++++++++++++++-
> > 1 file changed, 95 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 712811e89435..bd50ddc5b61c 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -74,6 +74,21 @@ static u32 hyp_ffa_version;
> > static bool has_version_negotiated;
> > static hyp_spinlock_t version_lock;
> >
> > +static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
> > +{
> > + DECLARE_REG(u32, func_id, ctxt, 0);
> > + int reg, end_reg = 7;
> > +
> > + if (FFA_MINOR_VERSION(hyp_ffa_version) >= 2)
> > + end_reg = ARM_SMCCC_IS_64(func_id) ? 17 : 7;
>
> This looks like an accident waiting to happen if we don't check the major
> number as well.
>
> I think you should just check:
>
> if (hyp_ffa_version >= FFA_VERSION_1_2)
>
> instead.
>
> You should also add a comment.
We restrict hyp_ffa_version major to 1.0 here
https://elixir.bootlin.com/linux/v7.1.1/source/arch/arm64/kvm/hyp/nvhe/ffa.c#L962
but since this is an easy fix I will include it.
>
> Will
Sebastian
^ permalink raw reply
* [PATCH v2 4/4] PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581
From: Christian Marangi @ 2026-06-26 9:20 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ryder Lee, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
In-Reply-To: <20260626092029.3525264-1-ansuelsmth@gmail.com>
The Airoha AN7581 SoC supports configuring the first PCIe0 line to 2-lanes
mode by bonding it with the second PCIe line. This is done by configuring
the PCIe MUX in the SCU register.
To correctly configure the line for 2-lanes mode, it's required to define
in DT an additional reg, 'sec-pcie-mac' for the secondary PCIe.
It's also needed to define the additional reset and the PERSTOUT reset.
Also 'airoha,scu' property is mandatory to correctly configure the SCU
register for the PCIe MUX.
Finally to toggle 2-lanes mode, it's needed to define in DT 'num-lanes' as
2.
In such configuration the EQ preset are configured to the same values.
To permit correct configuration of the PCIe line, additional logic is added
to assert and deassert the PERSTOUT resets.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/pci/controller/pcie-mediatek-gen3.c | 101 ++++++++++++++++----
1 file changed, 82 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index b0accd828589..14893cff135a 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -32,6 +32,11 @@
#include "../pci.h"
+/* AN7581 SCU register */
+#define SCU_PCIC 0x88
+#define SCU_PCIC_PCIE_CTRL GENMASK(7, 0)
+
+/* PCIe register */
#define PCIE_BASE_CFG_REG 0x14
#define PCIE_BASE_CFG_SPEED GENMASK(15, 8)
@@ -131,6 +136,7 @@
#define PCIE_ATR_TLP_TYPE_IO PCIE_ATR_TLP_TYPE(2)
#define MAX_NUM_PHY_RESETS 3
+#define MAX_NUM_PERSTOUT_RESETS 2
#define PCIE_MTK_RESET_TIME_US 10
@@ -203,9 +209,11 @@ struct mtk_msi_set {
struct mtk_gen3_pcie {
struct device *dev;
void __iomem *base;
+ void __iomem *sec_base;
phys_addr_t reg_base;
struct reset_control *mac_reset;
struct reset_control_bulk_data phy_resets[MAX_NUM_PHY_RESETS];
+ struct reset_control_bulk_data perstout_resets[MAX_NUM_PERSTOUT_RESETS];
struct phy *phy;
struct clk_bulk_data *clks;
int num_clks;
@@ -928,6 +936,14 @@ static int mtk_pcie_parse_port(struct mtk_gen3_pcie *pcie)
if (ret)
return dev_err_probe(dev, ret, "failed to get PHY bulk reset\n");
+ pcie->perstout_resets[0].id = "perstout";
+ pcie->perstout_resets[1].id = "sec-perstout";
+
+ ret = devm_reset_control_bulk_get_optional_exclusive(dev, MAX_NUM_PERSTOUT_RESETS,
+ pcie->perstout_resets);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get PERSTOUT bulk reset\n");
+
pcie->mac_reset = devm_reset_control_get_optional_exclusive(dev, "mac");
if (IS_ERR(pcie->mac_reset))
return dev_err_probe(dev, PTR_ERR(pcie->mac_reset), "failed to get MAC reset\n");
@@ -949,18 +965,38 @@ static int mtk_pcie_parse_port(struct mtk_gen3_pcie *pcie)
pcie->num_lanes = num_lanes;
}
+ /* Map secondary PCIe for 2-lanes mode for EN7581 */
+ if (num_lanes == 2 && device_is_compatible(dev, "airoha,en7581-pcie")) {
+ regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sec-pcie-mac");
+ if (!regs)
+ return -EINVAL;
+ pcie->sec_base = devm_ioremap_resource(dev, regs);
+ if (IS_ERR(pcie->sec_base))
+ return dev_err_probe(dev, PTR_ERR(pcie->sec_base), "failed to map secondary register base\n");
+ }
+
return 0;
}
static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
{
struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+ unsigned int num_lanes = max(1, pcie->num_lanes);
+ struct regmap *pbus_regmap, *scu;
struct device *dev = pcie->dev;
struct resource_entry *entry;
- struct regmap *pbus_regmap;
u32 val, args[2], size;
resource_size_t addr;
- int err;
+ int i, err;
+
+ if (num_lanes > 2)
+ return dev_err_probe(dev, -EINVAL, "unsupported num-lanes, maximum 2 lanes supported\n");
+
+ if (num_lanes == 2) {
+ scu = syscon_regmap_lookup_by_phandle(dev->of_node, "airoha,scu");
+ if (IS_ERR(scu))
+ return dev_err_probe(dev, PTR_ERR(scu), "failed to map SCU regmap\n");
+ }
/*
* The controller may have been left out of reset by the bootloader
@@ -992,6 +1028,19 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
size = lower_32_bits(resource_size(entry->res));
regmap_write(pbus_regmap, args[1], GENMASK(31, __fls(size)));
+ /* Assert PERSTOUT for all relevant lines */
+ err = reset_control_bulk_assert(MAX_NUM_PERSTOUT_RESETS,
+ pcie->perstout_resets);
+ if (err) {
+ dev_err(dev, "failed to assert PERSTOUTs\n");
+ return err;
+ }
+
+ /* Configure SCU MUX to disable PCIE1 for 2 lines mode */
+ if (num_lanes == 2)
+ regmap_update_bits(scu, SCU_PCIC, SCU_PCIC_PCIE_CTRL,
+ FIELD_PREP(SCU_PCIC_PCIE_CTRL, BIT(1)));
+
/*
* Unlike the other MediaTek Gen3 controllers, the Airoha EN7581
* requires PHY initialization and power-on before PHY reset deassert.
@@ -1024,33 +1073,47 @@ static int mtk_pcie_en7581_power_up(struct mtk_gen3_pcie *pcie)
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
- val = FIELD_PREP(PCIE_VAL_LN0_DOWNSTREAM, 0x47) |
- FIELD_PREP(PCIE_VAL_LN1_DOWNSTREAM, 0x47) |
- FIELD_PREP(PCIE_VAL_LN0_UPSTREAM, 0x41) |
- FIELD_PREP(PCIE_VAL_LN1_UPSTREAM, 0x41);
- writel_relaxed(val, pcie->base + PCIE_EQ_PRESET_01_REG);
-
- val = PCIE_K_PHYPARAM_QUERY | PCIE_K_QUERY_TIMEOUT |
- FIELD_PREP(PCIE_K_PRESET_TO_USE_16G, 0x80) |
- FIELD_PREP(PCIE_K_PRESET_TO_USE, 0x2) |
- FIELD_PREP(PCIE_K_FINETUNE_MAX, 0xf);
- writel_relaxed(val, pcie->base + PCIE_PIPE4_PIE8_REG);
-
err = clk_bulk_prepare_enable(pcie->num_clks, pcie->clks);
if (err) {
dev_err(dev, "failed to prepare clock\n");
goto err_clk_prepare_enable;
}
- /*
- * Airoha EN7581 performs PCIe reset via clk callbacks since it has a
- * hw issue with PCIE_PE_RSTB signal. Add wait for the time needed to
- * complete the PCIe reset.
- */
+ /* Wait for refclk to stabilize */
msleep(PCIE_T_PVPERL_MS);
+ /* Configure all the lines to the same EQ config */
+ for (i = 0; i < num_lanes; i++) {
+ void __iomem *base = pcie->base;
+
+ if (i == 1)
+ base = pcie->sec_base;
+
+ val = FIELD_PREP(PCIE_VAL_LN0_DOWNSTREAM, 0x47) |
+ FIELD_PREP(PCIE_VAL_LN1_DOWNSTREAM, 0x47) |
+ FIELD_PREP(PCIE_VAL_LN0_UPSTREAM, 0x41) |
+ FIELD_PREP(PCIE_VAL_LN1_UPSTREAM, 0x41);
+ writel_relaxed(val, base + PCIE_EQ_PRESET_01_REG);
+
+ val = PCIE_K_PHYPARAM_QUERY | PCIE_K_QUERY_TIMEOUT |
+ FIELD_PREP(PCIE_K_PRESET_TO_USE_16G, 0x80) |
+ FIELD_PREP(PCIE_K_PRESET_TO_USE, 0x2) |
+ FIELD_PREP(PCIE_K_FINETUNE_MAX, 0xf);
+ writel_relaxed(val, base + PCIE_PIPE4_PIE8_REG);
+ }
+
+ /* Deassert PERSTOUT for all relevant lines */
+ err = reset_control_bulk_deassert(MAX_NUM_PERSTOUT_RESETS,
+ pcie->perstout_resets);
+ if (err) {
+ dev_err(dev, "failed to deassert PERSTOUTs\n");
+ goto err_perstout_deassert;
+ }
+
return 0;
+err_perstout_deassert:
+ clk_bulk_disable_unprepare(pcie->num_clks, pcie->clks);
err_clk_prepare_enable:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/4] clk: en7523: add support for dedicated PCIe PERSTOUT reset
From: Christian Marangi @ 2026-06-26 9:20 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ryder Lee, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
In-Reply-To: <20260626092029.3525264-1-ansuelsmth@gmail.com>
Add support for resetting the PCIe lines with the PERSTOUT reset. These
special reset are controlled by the PCIC register and are specific to each
of the 3 PCIe lines.
Notice that reset logic is inverted for these bit where 0 is assert and 1
deassert. This is intenrally handled in the reset function.
PCI enable/disable are updated to drop PERSTOUT bits in favor dedicated
reset handling.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/clk/clk-en7523.c | 39 ++++++++++++++++++++++++++++-----------
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/clk-en7523.c b/drivers/clk/clk-en7523.c
index 1ab0e2eca5d3..c9b21d9bf2f3 100644
--- a/drivers/clk/clk-en7523.c
+++ b/drivers/clk/clk-en7523.c
@@ -338,6 +338,7 @@ static const struct en_clk_desc en7581_base_clks[] = {
static const u16 en7581_rst_ofs[] = {
REG_RST_CTRL2,
REG_RST_CTRL1,
+ REG_NP_SCU_PCIC,
};
static const u16 en751221_rst_ofs[] = {
@@ -450,6 +451,11 @@ static const u16 en7581_rst_map[] = {
[EN7581_CPU_TIMER_RST] = RST_NR_PER_BANK + 28,
[EN7581_PCIE_HB_RST] = RST_NR_PER_BANK + 29,
[EN7581_XPON_MAC_RST] = RST_NR_PER_BANK + 31,
+
+ /* RST_PCIC */
+ [EN7581_PCIC_PERSTOUT0_RST] = 2 * RST_NR_PER_BANK + 29,
+ [EN7581_PCIC_PERSTOUT1_RST] = 2 * RST_NR_PER_BANK + 26,
+ [EN7581_PCIC_PERSTOUT2_RST] = 2 * RST_NR_PER_BANK + 16,
};
static const u16 en751221_rst_map[] = {
@@ -635,9 +641,7 @@ static int en7581_pci_enable(struct clk_hw *hw)
void __iomem *np_base = cg->base;
u32 val, mask;
- mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
- REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
- REG_PCI_CONTROL_PERSTOUT;
+ mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1;
val = readl(np_base + REG_PCI_CONTROL);
writel(val | mask, np_base + REG_PCI_CONTROL);
@@ -650,9 +654,7 @@ static void en7581_pci_disable(struct clk_hw *hw)
void __iomem *np_base = cg->base;
u32 val, mask;
- mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
- REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
- REG_PCI_CONTROL_PERSTOUT;
+ mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1;
val = readl(np_base + REG_PCI_CONTROL);
writel(val & ~mask, np_base + REG_PCI_CONTROL);
usleep_range(1000, 2000);
@@ -754,14 +756,21 @@ static int en7523_reset_update(struct reset_controller_dev *rcdev,
unsigned long id, bool assert)
{
struct en_rst_data *rst_data = container_of(rcdev, struct en_rst_data, rcdev);
- void __iomem *addr = rst_data->base + rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ u32 offset = rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ void __iomem *addr = rst_data->base + offset;
+ bool inverted = false;
u32 val;
+ /* For PCIC reset logic is inverted, 0:assert 1:deassert*/
+ if (offset == REG_NP_SCU_PCIC)
+ inverted = true;
+
val = readl(addr);
+ val &= ~BIT(id % RST_NR_PER_BANK);
if (assert)
- val |= BIT(id % RST_NR_PER_BANK);
+ val |= inverted ? 0 : BIT(id % RST_NR_PER_BANK);
else
- val &= ~BIT(id % RST_NR_PER_BANK);
+ val |= inverted ? BIT(id % RST_NR_PER_BANK) : 0;
writel(val, addr);
return 0;
@@ -783,9 +792,17 @@ static int en7523_reset_status(struct reset_controller_dev *rcdev,
unsigned long id)
{
struct en_rst_data *rst_data = container_of(rcdev, struct en_rst_data, rcdev);
- void __iomem *addr = rst_data->base + rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ u32 offset = rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ void __iomem *addr = rst_data->base + offset;
+ bool inverted = false;
+ u32 val;
+
+ /* For PCIC reset logic is inverted, 0:assert 1:deassert*/
+ if (offset == REG_NP_SCU_PCIC)
+ inverted = true;
- return !!(readl(addr) & BIT(id % RST_NR_PER_BANK));
+ val = readl(addr) & BIT(id % RST_NR_PER_BANK);
+ return inverted ? !val : !!val;
}
static int en7523_reset_xlate(struct reset_controller_dev *rcdev,
--
2.53.0
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document 2-lanes
From: Christian Marangi @ 2026-06-26 9:20 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ryder Lee, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
In-Reply-To: <20260626092029.3525264-1-ansuelsmth@gmail.com>
To permit proper documentation of required property to support PCIe
configured for 2-lanes mode, split the Airoha schema part from the
mediatek-gen3 schema to a dedicated schema.
A PCIe configured for 2-lanes mode require an additional reg for the
secondary PCIe to be configured and the airoha,scu phandle to correctly
configure the PCIe MUX.
Rework the mediatek-gen3 schema to drop any redundant constraint previsouly
introduced for Airoha PCIe properties.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
.../bindings/pci/airoha,en7581-pcie.yaml | 251 ++++++++++++++++++
.../bindings/pci/mediatek-pcie-gen3.yaml | 77 +-----
2 files changed, 256 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
diff --git a/Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml b/Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
new file mode 100644
index 000000000000..c690ba7f207c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
@@ -0,0 +1,251 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/airoha,en7581-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gen3 PCIe controller on Airoha SoCs
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description: |+
+ PCIe Gen3 MAC controller for Airoha SoCs, it supports Gen3 speed
+ and compatible with Gen2, Gen1 speed.
+
+ This PCIe controller supports up to 256 MSI vectors, the MSI hardware
+ block diagram is as follows:
+
+ +-----+
+ | GIC |
+ +-----+
+ ^
+ |
+ port->irq
+ |
+ +-+-+-+-+-+-+-+-+
+ |0|1|2|3|4|5|6|7| (PCIe intc)
+ +-+-+-+-+-+-+-+-+
+ ^ ^ ^
+ | | ... |
+ +-------+ +------+ +-----------+
+ | | |
+ +-+-+---+--+--+ +-+-+---+--+--+ +-+-+---+--+--+
+ |0|1|...|30|31| |0|1|...|30|31| |0|1|...|30|31| (MSI sets)
+ +-+-+---+--+--+ +-+-+---+--+--+ +-+-+---+--+--+
+ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
+ | | | | | | | | | | | | (MSI vectors)
+ | | | | | | | | | | | |
+
+ (MSI SET0) (MSI SET1) ... (MSI SET7)
+
+ With 256 MSI vectors supported, the MSI vectors are composed of 8 sets,
+ each set has its own address for MSI message, and supports 32 MSI vectors
+ to generate interrupt.
+
+properties:
+ compatible:
+ const: airoha,en7581-pcie
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ maxItems: 1
+
+ ranges:
+ minItems: 1
+ maxItems: 8
+
+ iommu-map:
+ maxItems: 1
+
+ iommu-map-mask:
+ const: 0
+
+ resets:
+ minItems: 1
+ maxItems: 4
+
+ reset-names:
+ minItems: 1
+ maxItems: 4
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: sys-ck
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ items:
+ - const: pcie-phy
+
+ num-lanes:
+ enum: [1, 2]
+
+ mediatek,pbus-csr:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to pbus-csr syscon
+ - description: offset of pbus-csr base address register
+ - description: offset of pbus-csr base address mask register
+ description:
+ Phandle with two arguments to the syscon node used to detect if
+ a given address is accessible on PCIe controller.
+
+ airoha,scu:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to airoha SCU syscon
+ description:
+ Phandle to SCU syscon to configure PCIe MUX for 2 lines support.
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller:
+ description: Interrupt controller node for handling legacy PCI interrupts.
+ type: object
+ properties:
+ '#address-cells':
+ const: 0
+ '#interrupt-cells':
+ const: 1
+ interrupt-controller: true
+
+ required:
+ - '#address-cells'
+ - '#interrupt-cells'
+ - interrupt-controller
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - ranges
+ - clocks
+ - clock-names
+ - '#interrupt-cells'
+ - interrupt-controller
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - if:
+ properties:
+ num-lanes:
+ const: 2
+ then:
+ properties:
+ reg:
+ minItems: 2
+
+ reg-names:
+ items:
+ - const: pcie-mac
+ - const: sec-pcie-mac
+
+ resets:
+ minItems: 4
+
+ reset-names:
+ items:
+ - const: phy-lane0
+ - const: phy-lane1
+ - const: perstout
+ - const: sec-perstout
+
+ required:
+ - airoha,scu
+
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+ reg-names:
+ items:
+ - const: pcie-mac
+
+ resets:
+ minItems: 2
+ maxItems: 3
+
+ reset-names:
+ minItems: 2
+ items:
+ - enum: [ phy-lane0, phy-lane1, phy-lane2 ]
+ - enum: [ phy-lane1, perstout ]
+ - const: phy-lane2
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1fc00000 {
+ compatible = "airoha,en7581-pcie";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ reg = <0x0 0x1fc00000 0x0 0x1670>,
+ <0x0 0x1fc20000 0x0 0x1670>;
+ reg-names = "pcie-mac", "sec-pcie-mac";
+
+ clocks = <&scuclk 7>;
+ clock-names = "sys-ck";
+
+ phys = <&pciephy>;
+ phy-names = "pcie-phy";
+
+ ranges = <0x02000000 0 0x20000000 0x0 0x20000000 0 0x4000000>;
+
+ resets = <&scuclk 48>,
+ <&scuclk 49>,
+ <&scuclk 53>,
+ <&scuclk 54>;
+ reset-names = "phy-lane0", "phy-lane1",
+ "perstout", "sec-perstout";
+
+ num-lanes = <2>;
+
+ mediatek,pbus-csr = <&pbus_csr 0x0 0x4>;
+
+ airoha,scu = <&scuclk>;
+
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ bus-range = <0x00 0xff>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &pcie_intc 0>,
+ <0 0 0 2 &pcie_intc 1>,
+ <0 0 0 3 &pcie_intc 2>,
+ <0 0 0 4 &pcie_intc 3>;
+ pcie_intc: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
index 4db700fc36ba..510f1f2b1c5a 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
@@ -59,7 +59,6 @@ properties:
- const: mediatek,mt8196-pcie
- const: mediatek,mt8192-pcie
- const: mediatek,mt8196-pcie
- - const: airoha,en7581-pcie
reg:
maxItems: 1
@@ -83,20 +82,20 @@ properties:
resets:
minItems: 1
- maxItems: 3
+ maxItems: 2
reset-names:
minItems: 1
- maxItems: 3
+ maxItems: 2
items:
- enum: [ phy, mac, phy-lane0, phy-lane1, phy-lane2 ]
+ enum: [ phy, mac ]
clocks:
- minItems: 1
+ minItems: 4
maxItems: 6
clock-names:
- minItems: 1
+ minItems: 4
maxItems: 6
assigned-clocks:
@@ -115,17 +114,6 @@ properties:
power-domains:
maxItems: 1
- mediatek,pbus-csr:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- items:
- - items:
- - description: phandle to pbus-csr syscon
- - description: offset of pbus-csr base address register
- - description: offset of pbus-csr base address mask register
- description:
- Phandle with two arguments to the syscon node used to detect if
- a given address is accessible on PCIe controller.
-
'#interrupt-cells':
const: 1
@@ -177,16 +165,6 @@ allOf:
- const: peri_26m
- const: top_133m
- resets:
- minItems: 1
- maxItems: 2
-
- reset-names:
- minItems: 1
- maxItems: 2
-
- mediatek,pbus-csr: false
-
- if:
properties:
compatible:
@@ -208,16 +186,6 @@ allOf:
- const: peri_26m
- const: peri_mem
- resets:
- minItems: 1
- maxItems: 2
-
- reset-names:
- minItems: 1
- maxItems: 2
-
- mediatek,pbus-csr: false
-
- if:
properties:
compatible:
@@ -246,8 +214,6 @@ allOf:
- const: phy
- const: mac
- mediatek,pbus-csr: false
-
- if:
properties:
compatible:
@@ -257,7 +223,6 @@ allOf:
then:
properties:
clocks:
- minItems: 4
maxItems: 4
clock-names:
@@ -267,38 +232,6 @@ allOf:
- const: peri_26m
- const: top_133m
- resets:
- minItems: 1
- maxItems: 2
-
- reset-names:
- minItems: 1
- maxItems: 2
-
- mediatek,pbus-csr: false
-
- - if:
- properties:
- compatible:
- const: airoha,en7581-pcie
- then:
- properties:
- clocks:
- maxItems: 1
-
- clock-names:
- items:
- - const: sys-ck
-
- resets:
- minItems: 3
-
- reset-names:
- items:
- - const: phy-lane0
- - const: phy-lane1
- - const: phy-lane2
-
unevaluatedProperties: false
examples:
--
2.53.0
^ permalink raw reply related
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