* Re: [PATCH] drm/mediatek: mtk_dsi: enable hs clock during pre-enable
From: Gary Bisson @ 2026-06-22 11:22 UTC (permalink / raw)
To: Adam Thiede
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <42607fa4-485d-4142-b31c-7bfac71118d2@adamthiede.com>
Hi,
On Thu, Jun 18, 2026 at 04:06:28PM -0500, Adam Thiede wrote:
> On 1/20/26 05:36, Gary Bisson wrote:
> > Some bridges, such as the TI SN65DSI83, require the HS clock to be
> > running in order to lock its PLL during its own pre-enable function.
> >
> > Without this change, the bridge gives the following error:
> > sn65dsi83 14-002c: failed to lock PLL, ret=-110
> > sn65dsi83 14-002c: Unexpected link status 0x01
> > sn65dsi83 14-002c: reset the pipe
> >
> > Move the necessary functions from enable to pre-enable.
> >
> > Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
> > ---
> > Tested on Tungsten510 module with sn65dsi83 + tm070jdhg30 panel.
> >
> > Left mtk_dsi_set_mode() as part of the enable function to mimic what is
> > done in the Samsung DSIM driver which is known to be working the TI
> > bridge.
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 35 +++++++++++++++++------------------
> > 1 file changed, 17 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index 0e2bcd5f67b7..b560245d1be9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -672,6 +672,21 @@ static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> > }
> > }
> > +static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
> > +{
> > + if (!dsi->lanes_ready) {
> > + dsi->lanes_ready = true;
> > + mtk_dsi_rxtx_control(dsi);
> > + usleep_range(30, 100);
> > + mtk_dsi_reset_dphy(dsi);
> > + mtk_dsi_clk_ulp_mode_leave(dsi);
> > + mtk_dsi_lane0_ulp_mode_leave(dsi);
> > + mtk_dsi_clk_hs_mode(dsi, 0);
> > + usleep_range(1000, 3000);
> > + /* The reaction time after pulling up the mipi signal for dsi_rx */
> > + }
> > +}
> > +
> > static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > {
> > struct device *dev = dsi->host.dev;
> > @@ -724,6 +739,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > mtk_dsi_set_vm_cmd(dsi);
> > mtk_dsi_config_vdo_timing(dsi);
> > mtk_dsi_set_interrupt_enable(dsi);
> > + mtk_dsi_lane_ready(dsi);
> > + mtk_dsi_clk_hs_mode(dsi, 1);
> > return 0;
> > err_disable_engine_clk:
> > @@ -769,30 +786,12 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> > dsi->lanes_ready = false;
> > }
> > -static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
> > -{
> > - if (!dsi->lanes_ready) {
> > - dsi->lanes_ready = true;
> > - mtk_dsi_rxtx_control(dsi);
> > - usleep_range(30, 100);
> > - mtk_dsi_reset_dphy(dsi);
> > - mtk_dsi_clk_ulp_mode_leave(dsi);
> > - mtk_dsi_lane0_ulp_mode_leave(dsi);
> > - mtk_dsi_clk_hs_mode(dsi, 0);
> > - usleep_range(1000, 3000);
> > - /* The reaction time after pulling up the mipi signal for dsi_rx */
> > - }
> > -}
> > -
> > static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> > {
> > if (dsi->enabled)
> > return;
> > - mtk_dsi_lane_ready(dsi);
> > mtk_dsi_set_mode(dsi);
> > - mtk_dsi_clk_hs_mode(dsi, 1);
> > -
> > mtk_dsi_start(dsi);
> > dsi->enabled = true;
> >
> > ---
> > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> > change-id: 20260120-mtkdsi-29e4c84e7b38
> >
> > Best regards,
>
> Hello,
> This commit was part of 7.1 and caused a problem for me.
> I'm running postmarketOS (basically Alpine Linux) on a Lenovo C330
> chromebook with a Mediatek MT8173 processor.
> The problem: when the display on my laptop powers off (via suspend or idle,
> like xset dpms off) the picture does not come back when the display powers
> back on (from resume). The display backlight comes on and brightness is
> adjustable but there is no picture. The only fix is to reboot.
>
> Reverting this commit and applying it as a patch on top of 7.1 addresses the
> issue for me.
>
> You can view the config I'm using here:
> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8819
>
> Is there any sort of testing or other debugging info I can provide to help
> address this issue?
Thanks for reporting the issue, could you share some logs? Is the driver
saying anything during resume? Also, what type of panel is used on that
chromebook?
Thanks,
Gary
^ permalink raw reply
* Re: [PATCH v7 5/7] KVM: arm64: Validate the offset to the mem access descriptor
From: Sebastian Ene @ 2026-06-22 11:22 UTC (permalink / raw)
To: Vincent Donnefort
Cc: catalin.marinas, oupton, sudeep.holla, will, jens.wiklander,
joey.gouly, kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
maz, mrigendra.chaubey, op-tee, perlarsen, seiden, smostafa,
sumit.garg, suzuki.poulose, yuzenghui
In-Reply-To: <ajj_DkqiDwiF8imZ@google.com>
On Mon, Jun 22, 2026 at 09:23:26AM +0000, Sebastian Ene wrote:
> On Thu, Jun 18, 2026 at 05:56:24PM +0100, Vincent Donnefort wrote:
> > On Wed, Jun 17, 2026 at 02:51:28PM +0000, Sebastian Ene wrote:
> > > Prevent the pKVM hypervisor from making assumptions that the
> > > endpoint memory access descriptor (EMAD) comes right after the
> > > FF-A memory region header.
> > > Prior to FF-A version 1.1 the header of the memory region
> > > didn't contain an offset to the endpoint memory access descriptor.
> > > The layout of a memory transaction looks like this from 1.1 onward:
> > > Type | Field name | Offset
> > > [ Header | ffa_mem_region | 0
> > > EMAD 1 | ffa_mem_region_attributes) | ffa_mem_region.ep_mem_offset
> > > ]
> > > Verify that the offset to the first endpoint memory access descriptor
> > > is within the mailbox buffer bounds.
> > >
> > > Also, fix one hardcoded sizeof(struct ffa_mem_region_attributes) that
> > > should be replaced ffa_emad_size_get() for compatibility with FFA v1.0.
> > >
> > > Fixes: 42fb33dde42b ("KVM: arm64: Use FF-A 1.1 with pKVM")
> > > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/ffa.c | 29 +++++++++++++++++++++--------
> > > 1 file changed, 21 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > index 2d211661952e..1a2abd0154c6 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > @@ -476,11 +476,14 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> > > DECLARE_REG(u32, fraglen, ctxt, 2);
> > > DECLARE_REG(u64, addr_mbz, ctxt, 3);
> > > DECLARE_REG(u32, npages_mbz, ctxt, 4);
> > > + u32 offset, nr_ranges, checked_offset, em_mem_access_off;
> > > struct ffa_mem_region_attributes *ep_mem_access;
> > > struct ffa_composite_mem_region *reg;
> > > struct ffa_mem_region *buf;
> > > - u32 offset, nr_ranges, checked_offset;
> > > int ret = 0;
> > > + size_t mem_region_len = !FFA_MEM_REGION_HAS_EP_MEM_OFFSET(hyp_ffa_version) ?
> > > + offsetof(struct ffa_mem_region, ep_mem_offset) :
> > > + sizeof(struct ffa_mem_region);
While talking with Vincent about this change, we agreed that it would be
easier to introduce a helper that will get the size of the struct
ffa_mem_region which is different based on the ff-a version.
This would hopefully increase the readability of this. The description
of the struct ffa_mem_region can be found in (Table 5.19: Lend, donate or
share memory transaction descriptor) from DEN0077A.
I will spin a new version to address this and collect the review tags.
> > >
> > > if (addr_mbz || npages_mbz || fraglen > len ||
> > > fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
> > > @@ -488,8 +491,7 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> > > goto out;
> > > }
> > >
> > > - if (fraglen < sizeof(struct ffa_mem_region) +
> > > - sizeof(struct ffa_mem_region_attributes)) {
> > > + if (fraglen < mem_region_len + ffa_emad_size_get(hyp_ffa_version)) {
> >
> > Can't we replace mem_region_len with ffa_mem_desc_offset()? that pretty much
> > looks like the same thing.
> >
>
> We can't because `ffa_mem_desc_offset` dereferences struct
> ffa_mem_region to extract ep_mem_offset as per the latest updates.
>
> >
> > > ret = FFA_RET_INVALID_PARAMETERS;
> > > goto out;
> > > }
> > > @@ -508,8 +510,13 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> > > buf = hyp_buffers.tx;
> > > memcpy(buf, host_buffers.tx, fraglen);
> > >
> > > - ep_mem_access = (void *)buf +
> > > - ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
> > > + em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
> > > + if ((u64)em_mem_access_off + ffa_emad_size_get(hyp_ffa_version) > fraglen) {
> >
> > This check looks like ffa_mem_desc_offset() with count to 1.
> >
> >
> > > + ret = FFA_RET_INVALID_PARAMETERS;
> > > + goto out_unlock;
> > > + }
> > > +
> > > + ep_mem_access = (void *)buf + em_mem_access_off;
> > > offset = ep_mem_access->composite_off;
> > > if (!offset || buf->ep_count != 1 || buf->sender_id != HOST_FFA_ID) {
> > > ret = FFA_RET_INVALID_PARAMETERS;
> > > @@ -574,9 +581,9 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > > DECLARE_REG(u32, handle_lo, ctxt, 1);
> > > DECLARE_REG(u32, handle_hi, ctxt, 2);
> > > DECLARE_REG(u32, flags, ctxt, 3);
> > > + u32 offset, len, fraglen, fragoff, em_mem_access_off;
> > > struct ffa_mem_region_attributes *ep_mem_access;
> > > struct ffa_composite_mem_region *reg;
> > > - u32 offset, len, fraglen, fragoff;
> > > struct ffa_mem_region *buf;
> > > int ret = 0;
> > > u64 handle;
> > > @@ -599,8 +606,14 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > > len = res->a1;
> > > fraglen = res->a2;
> > >
> > > - ep_mem_access = (void *)buf +
> > > - ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
> > > + em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
> > > + if ((u64)em_mem_access_off + ffa_emad_size_get(hyp_ffa_version) > fraglen) {
> >
> > ditto. ffa_mem_desc_offset()
> >
> > > + ret = FFA_RET_INVALID_PARAMETERS;
> > > + ffa_rx_release(res);
> > > + goto out_unlock;
> > > + }
> > > +
> > > + ep_mem_access = (void *)buf + em_mem_access_off;
> > > offset = ep_mem_access->composite_off;
> > > /*
> > > * We can trust the SPMD to get this right, but let's at least
> > > --
> > > 2.54.0.1136.gdb2ca164c4-goog
> > >
>
> Thanks,
> Sebastian
^ permalink raw reply
* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-22 11:24 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <20260617-imx_mbox_rproc-v3-1-77948112defc@linutronix.de>
On Wed, Jun 17, 2026 at 08:55:26AM +0200, Sebastian Andrzej Siewior wrote:
>imx_mu_generic_tx() for the IMX_MU_TYPE_TXDB_V2 type polls on a register
>which may timeout and is recognized as an error. This error is siltently
>dropped and not dropped to the caller.
>
>Forward the error to the caller.
>
>Fixes: b5ef17917f3a7 ("mailbox: imx: fix TXDB_V2 channel race condition")
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> drivers/mailbox/imx-mailbox.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>index 246a9a9e39520..0028073be4a71 100644
>--- a/drivers/mailbox/imx-mailbox.c
>+++ b/drivers/mailbox/imx-mailbox.c
>@@ -227,6 +227,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> u32 val;
> int ret, count;
>
>+ ret = 0;
> switch (cp->type) {
> case IMX_MU_TYPE_TX:
> imx_mu_write(priv, *arg, priv->dcfg->xTR + cp->idx * 4);
>@@ -259,7 +260,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> return -EINVAL;
> }
>
>- return 0;
>+ return ret;
We may need to use atomic API for TXDB_V2. For the patchset itself, it
looks good to me.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
> }
>
> static int imx_mu_generic_rx(struct imx_mu_priv *priv,
>
>--
>2.53.0
>
^ permalink raw reply
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: David Hildenbrand (Arm) @ 2026-06-22 12:20 UTC (permalink / raw)
To: Cristian Marussi
Cc: Christian Brauner, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek, d-gole,
jic23, elif.topuz, lukasz.luba, philip.radford,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team
In-Reply-To: <ajU7UqwPZBlwRGkf@pluto>
>>>
>>> There is more stuff that indeed is configurable per the SCMI spec
>>> but these additional params are hidden into the SCMI Telemetry protocol
>>> layer (the initial patches in this series) and NOT made available to
>>> the driver/users of the protocol (like the SCMI FS driver that sits on
>>> top)
>>
>> Do you assume that there will get significantly more config options added in the
>> future for user space to configure?
>
> No, I dont think so...the only planned extensions were to support more
> performant read access mechanisms, i.e. direct mmap'ability of FW/Kernel
> SCMI Telemetry shared memory areas...BUT that will immediately dump all
> the bulk of the lower layer protocol work into the tools domain...and
Right. I guess you would hide that in library code, and provide a stable API
towards tools such that they won't have to worry about the implementation
details regarding how the values are obtained exactly.
[...]
>>>
>>> ...most of the other entries in the tree are simply RO properties of the DEs
>>> that have been discovered at enumeration time.
>>
>> Is this bulk-reading relevant for performance or just a "nice to have" ?
>>
>
> I suppose depends on your usage pattern: it is definitely relevant
> because the main collection mechanism are shared memory areas (SHMTIs)
> between the platform firmware and the Kernel: such areas being accessed
> from 2 differnt worlds concurrently come with a SCMI-specified
> synchro/consistency mechanism based simply on a pair of sequence numbers
> placed at the start and at the end of the SHMTI, so that the FW increases
> such magic numbers in a well-known way before and after updating the SHMTI
> values, so that the kernel can detect (without any interlocking mechanism)
> if a platform write happened in the middle of its reads...
Okay, so sequence counters to detect concurrent changes and retry.
>
> ...so if you read one single DE 64bit value, under the hood the kernel
> would have had to really perform at leats 3 reads from the SHMTI to check
> the consistecy of that single read...
>
> ... while if you do a bulk_read the overhead due to the consistecy
> checks gets 'spread' across a number of DEs because the kernel will snapshot
> the whole SHMTIs (potentially KBytes) between the 2 consistency reads
That makes sense.
I guess a user space library could implement some kind of caching (bulk-read,
then provide clean access to individual DEs) to hide the details from the tools?
>
> ...the good side effect of all of this is that I can leverage such
> sequence number to optimize reads..i.e. do NOT even try to read anything
> if the new sequnce number is unchanged from the last one I cached on the
> last successfull read of this value...
Right.
>
> So at the end I would say it is NOT simply a nice to have BUT it is
> certainly only the first step towards a more performant alternative access
> (like with mmaps)...it depends on the usage pattern...I am not sure what
> mechanism is used by our tools more...
Okay.
>>
>> Yes. How high-priority is the fs side? Or would a tool using a library to access
>> this information also work in the first step?
>>
>
> I have to sync with tools on this...because they are stiil probably
> using currently the FS, but it was already planned for the future to move to
> a more low level access (ioctl/mmap)...
>
> ...my aim would be, at this point, to favour this transition without sudden
> breaking their current world (and have to expatriate :P)
>
> ..from my personal point of view, I would certainly like to still have the
> FUSE layer for ease of testing and verification on my side...but it is just
> a nice to have...
Okay, what I thought. I assume the most important part is to be able to grab
telemetry data in an efficient way on a system to then share it with some
monitoring agent. Manually digging through the FS to inspect data (debugging,
..) is probably less relevant for the target use case.
>> Okay, so a single writer (admin) changing stuff could get picked up my possibly
>> many concurrent readers?
>
> Mmm...not sure what you mean here...
>
> If you configure your Telemetry as you desire and start collecting data via
> readers, BUT then some other process changes configs under your belt, that is
> allowed as said, and so your analisys could be impacted...(something turned off
> as an example, or update interval changed)...
I was rather wondering about "turning on more" concurrently. But yeah, makes sense.
(it's the same situation other system-wide settings. If one app enables KSM and
the another one disables KSM, inconsistency is unavoidable)
>>
>
> Thanks a lot, David !
Let's hope for some guidance regarding the FS side soon.
But yeah, avoiding the in-kernel FS sounds completely reasonable at this point.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Michal Simek @ 2026-06-22 12:25 UTC (permalink / raw)
To: Tanmay Shah, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc
In-Reply-To: <20260619163854.410392-1-tanmay.shah@amd.com>
On 6/19/26 18:38, Tanmay Shah wrote:
> Current _start and _stop ops are implemented using various APIs from the
> platform management firmware driver. Instead provide respective RPU
> start and stop API in the firmware driver and move the logic to interact
> with the PM firmware in the firmware driver. The remoteproc driver doesn't
> need to know actual logic, but only the final result i.e. RPU start/stop
> was success or not. This refactor keeps the remoteproc driver simple and
> moves firmware interaction logic to the firmware driver.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> drivers/firmware/xilinx/zynqmp.c | 93 +++++++++++++++++++++++++
> drivers/remoteproc/xlnx_r5_remoteproc.c | 68 ++----------------
> include/linux/firmware/xlnx-zynqmp.h | 12 ++++
> 3 files changed, 110 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index af838b2dc327..f9a3a95b0638 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -1513,6 +1513,99 @@ int zynqmp_pm_request_wake(const u32 node,
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
>
> +/**
> + * zynqmp_pm_start_rpu - Boot Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + * @bootaddr: Boot address of elf
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + enum rpu_boot_mem bootmem;
> + int ret;
> +
> + /*
> + * The exception vector pointers (EVP) refer to the base-address of
> + * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> + * starts at the base-address and subsequent vectors are on 4-byte
> + * boundaries.
> + *
> + * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> + * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
here
> + *
> + * Usually firmware will put Exception vectors at LOVEC.
> + *
> + * It is not recommend that you change the exception vector.
> + * Changing the EVP to HIVEC will result in increased interrupt latency
> + * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> + * is non-secured, then the Cortex-R5F processor cannot access the
> + * HIVEC exception vectors in the OCM.
> + */
> + bootmem = (bootaddr >= 0xFFFC0000) ?
and here you have different values without any explanation why.
The rest looks good to me. It is a step in a right direction.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
From: Simon Horman @ 2026-06-22 12:31 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260619-airoha-qos-fixes-v2-2-5c43485038f9@kernel.org>
On Fri, Jun 19, 2026 at 01:37:14PM +0200, Lorenzo Bianconi wrote:
> airoha_tc_htb_alloc_leaf_queue() assigns queue IDs based on the channel
> index (opt->qid = AIROHA_NUM_TX_RING + channel), but updates
> real_num_tx_queues with a simple increment (num_tx_queues + 1). When QoS
> channels are allocated sparsely (e.g., channels 0 and 3 without 1 and
> 2), the returned qid can exceed real_num_tx_queues, causing out-of-bounds
> accesses in the networking stack.
> For example, allocating channel 0 then channel 3 results in
> real_num_tx_queues = 34 but qid = 35, which is out of range [0, 34).
> Fix this by computing real_num_tx_queues based on the highest active
> channel index rather than using a simple counter, in both the allocation
> and deletion paths.
>
> Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Thanks for the update since v1.
Reviewed-by: Simon Horman <horms@kernel.org>
FTR, there is an AI-generated review of this patch on sashiko.dev.
I do not think that should impede the progress of this patch but
you may want to consider it in the context of follow-up.
^ permalink raw reply
* Re: [PATCH] net: ixp4xx_hss: fix duplicate HDLC netdev allocation
From: Linus Walleij @ 2026-06-22 12:36 UTC (permalink / raw)
To: Haoxiang Li
Cc: kaloz, andrew+netdev, davem, edumazet, kuba, pabeni,
huangguangbin2, lipeng321, linux-arm-kernel, netdev, linux-kernel,
stable
In-Reply-To: <20260622043015.643637-1-haoxiang_li2024@163.com>
On Mon, Jun 22, 2026 at 6:30 AM Haoxiang Li <haoxiang_li2024@163.com> wrote:
> ixp4xx_hss_probe() allocates two HDLC netdevs. The first one is stored
> in ndev, initialized, and registered with register_hdlc_device(). The
> second one is stored in port->netdev and later used by the remove path
> for unregister_hdlc_device() and free_netdev().
>
> This means that the registered netdev is not the same object that is
> unregistered and freed on remove. It also leaks the first allocation if
> the second alloc_hdlcdev() call fails, and the first allocation is not
> checked before ndev is used.
>
> Older code allocated the HDLC netdev only once and stored the same object
> in both the local variable and port->netdev. The buggy conversion split
> this into two alloc_hdlcdev() calls. A later rename changed the local
> variable name to ndev, but the underlying mismatch remained.
>
> Fix this by allocating the HDLC netdev only once and assigning the same
> object to port->netdev.
>
> Fixes: 99ebe65eb9c0 ("net: ixp4xx_hss: move out assignment in if condition")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Harry Yoo @ 2026-06-22 12:42 UTC (permalink / raw)
To: Catalin Marinas
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <ajVByfkLbetzA8bB@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 2477 bytes --]
Hi Catalin,
On 6/19/26 10:19 PM, Catalin Marinas wrote:
> On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
>> On 6/12/26 1:44 PM, Dev Jain wrote:
>>> Introduce a boot option to tag only at allocation time of the objects. This
>>> reduces KASAN MTE overhead, the tradeoff being reduced ability of
>>> catching bugs.
>>
>> I think most of overhead when enabling MTE comes from loading and
>> validing tags for every memory access (either in SYNC or ASYNC mode),
>> rather than from storing tags.
>
> I guess it depends on the workload. Lots of allocations for short-lived
> buffers (e.g. network traffic) may notice the additional tagging more
> than the actual tag checking.
Agreed. Likely depends on lifetime and size of objects.
> Of course, it would be nice to get some numbers from those who have
> access to MTE capable hardware.
Agreed! (I don't have one, unfortunately. It's pretty new hardware
feature)
>>> Now, when a memory object will be freed, it will retain the random tag it
>>> had at allocation time. This compromises on catching UAF bugs, till the
>>> time the object is not reallocated, at which point it will have a new
>>> random tag.
>>>
>>> Hence, not catching "use-after-free-before-reallocation" and not catching
>>> "double-free" will be the compromise for reduced KASAN overhead.
>>
>> I doubt users who care about security enough to enable HW_TAGS KASAN
>> are willing to compromise on security just to save a few instructions
>> to store tags in the free path.
>>
>> To me, it looks like too much of a compromise on security for little
>> performance gain.
>
> I don't think there's much compromise on security for use-after-free.
I think it depends... OH, WAIT! I see what you mean.
You mean use-after-free before reallocation does not lead to much
compromise on security because objects are initialized after allocation?
You're probably right.
Hmm, but stores to e.g.) free pointer, fields initialized by
constructor or accessed by SLAB_TYPESAFE_BY_RCU semantics after free
will be undiscovered if they happen before reallocation.
Not sure what are security implications of that,
but sounds worth discussing.
> The buffer will be re-tagged later so use-after-realloc should be
> caught, especially if we ensure that a different tag will be used (I
> don't think Dev's patches do this).
Agreed that it'll be nice to ensure that.
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: add Axiado AX3000 PWM
From: Krzysztof Kozlowski @ 2026-06-22 12:50 UTC (permalink / raw)
To: Petar Stepanovic, Akhila Kavi, Prasad Bolisetty,
Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-pwm, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-axiado-ax3000-pwm-v1-1-c9797a909414@axiado.com>
On 18/06/2026 14:26, Petar Stepanovic wrote:
> +
> +description:
> + The Axiado PWM controller found on AX3000 and AX3005 SoCs.
> +
> +allOf:
> + - $ref: pwm.yaml#
> +
> +properties:
> + compatible:
> + const: axiado,ax3000-pwm
Description mentions AX3005, but there is no ax3005 compatible here.
This is confusing.
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: pwm
Drop clock-names, not really useful if it has block's name.
> +
> + "#pwm-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +additionalProperties: false
> +
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: Avoid eager DVMSync reclaim batches with C1-Pro SME erratum
From: Joshua Liu @ 2026-06-22 12:52 UTC (permalink / raw)
To: catalin.marinas; +Cc: linux-arm-kernel, will, Joshua Liu
In-Reply-To: <20260610104829.1157497-1-catalin.marinas@arm.com>
On Wed, Jun 10, 2026 at 11:37 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> Introduce the sme_active_cpus mask tracking which CPUs run in user-space
> with SME enabled and use it for batch flushing instead of accumulating
> the mm_cpumask() of the unmapped pages.
> [...]
> The dsb() in arch_tlbbatch_add_pending() -> sme_dvmsync_add_pending()
> did introduce a performance regression for kswapd. This patch restores
> the original behaviour with the barrier only issued when the TLB batch
> is flushed. The trade-off is that the IPIs are now sent to all CPUs
> running with SME enabled at EL0 even if the reclaimed pages do not
> belong to SME tasks. This is acceptable for current SME deployments.
Profiling shows this solution has robust performance for common
workloads and is the best among a few approaches we tested with Catalin,
so we are happy to go with this solution.
Some sidenotes: for certain edge cases we still observe performance
regression, specifically when a workload pegs multiple cores with SME
status threads.
Tested-by: Joshua Liu <josliu@google.com>
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Harry Yoo @ 2026-06-22 12:56 UTC (permalink / raw)
To: Catalin Marinas
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <ajU-b32dmwS7XOg4@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1103 bytes --]
On 6/19/26 10:04 PM, Catalin Marinas wrote:
> On Thu, Jun 18, 2026 at 11:05:43PM +0900, Harry Yoo wrote:
>> On 6/18/26 10:35 PM, Harry Yoo wrote:
>>> On 6/12/26 1:44 PM, Dev Jain wrote:
>>>> Introduce a boot option to tag only at allocation time of the objects. This
>>>> reduces KASAN MTE overhead, the tradeoff being reduced ability of
>>>> catching bugs.
>>>
>>> I think most of overhead when enabling MTE comes from loading and
>>> validing tags for every memory access (either in SYNC or ASYNC mode),
>>> rather than from storing tags.
>>
>> Is there any reason not to use STGM instead of STG + DC GVA when
>> setting/clearing tags for large sizes when we know they are properly
>> aligned?
>
> STGM is intended for copying tags when paired with LDGM. Have you seen
> hardware where STGM is faster than STG or DC GVA?
No, I haven't. It was a question I had after learning that there are
multiple ways to store tags ;)
> For properly aligned
> buffers, I'd expect DC GVA to behave at least on par with STGM.
Thanks for answering!
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
From: Mark Brown @ 2026-06-22 13:04 UTC (permalink / raw)
To: phucduc.bui
Cc: Heiko Stuebner, Liam Girdwood, Nicolas Frattaroli,
Krzysztof Kozlowski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <20260622005613.21870-1-phucduc.bui@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]
On Mon, Jun 22, 2026 at 07:56:13AM +0700, phucduc.bui@gmail.com wrote:
> Although switching to devm_clk_get_enabled() in a previous patch was
> tested successfully, it introduces overlapping ownership of the clock
> lifecycle. Since the driver requires early register access to read the
> device version during probe(), enabling hclk at that point is mandatory.
> Clean up the design by:
> 1 Reverting back to devm_clk_get() to remove the implicit devres
> enable/disable behavior.
> 2 Manually enabling and disabling hclk explicitly only around the
> early register access before Runtime PM takes over.
> 3 Dropping the stray clk_disable_unprepare() at the end of probe()
> so Runtime PM solely owns hclk afterward.
Note that runtime PM can be disabled at build time so we might not have
runtime PM at all...
> Links:
> 1 This change is based on the discussion around manual hclk handing during probe(),
> as raised by Krysztof:
> https://lore.kernel.org/all/20e4754b-ea9a-404d-b529-ec44a7263cbf@kernel.org/#t
> 2 Background for the earlier devm_clk_get_enbabled() conversion:
> https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
> An alternative approach would be use devm_regmap_init_mmio_clk() and let regmap
> manage clock enablement around register accesses. If preferred, I can rework the
> driver accordingly.
> - sai->hclk = devm_clk_get_enabled(&pdev->dev, "hclk");
> + sai->hclk = devm_clk_get(&pdev->dev, "hclk");
> if (IS_ERR(sai->hclk))
> return dev_err_probe(&pdev->dev, PTR_ERR(sai->hclk),
> "Failed to get hclk\n");
>
> + ret = clk_prepare_enable(sai->hclk);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret, "Failed to enable hclk\n");
> +
> @@ -1482,8 +1492,6 @@ static int rockchip_sai_probe(struct platform_device *pdev)
> pm_runtime_use_autosuspend(&pdev->dev);
> pm_runtime_put(&pdev->dev);
>
> - clk_disable_unprepare(sai->hclk);
> -
> return 0;
Are you sure that the runtime PM state there is such that it knows a
reference is held? The driver used pm_runtime_get_noresume() so the
device didn't have RPM_ACTIVE set I think?
The runtime PM API really is a miserable collection of landmines :(
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v8 03/24] arm64: mm: Enable overlays for all EL1 indirect permissions
From: David Hildenbrand (Arm) @ 2026-06-22 13:06 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: Andrew Morton, Andy Lutomirski, Catalin Marinas, Dave Hansen,
Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Marc Zyngier, Mark Brown, Matthew Wilcox,
Maxwell Bland, Mike Rapoport (IBM), Peter Zijlstra,
Pierre Langlois, Quentin Perret, Rick Edgecombe, Ryan Roberts,
Vlastimil Babka, Will Deacon, Yang Shi, Yeoreum Yun,
linux-arm-kernel, linux-mm, x86, Lorenzo Stoakes, Thomas Gleixner
In-Reply-To: <20260526-kpkeys-v8-3-eaaacdacc67c@arm.com>
On 5/26/26 13:15, Kevin Brodsky wrote:
> In preparation of using POE inside the kernel, enable "Overlay
> applied" for kernel memory types in PIR_EL1. This ensures that the
> permissions set in POR_EL1 affect all kernel mappings.
>
> User memory types must be left untouched (overlays not applied)
> because any privileged access to user memory (e.g. futex atomic
> without FEAT_LSUI) would then be mistakenly checked against POR_EL1.
That makes sense. Still learning the architecture, but ... leaving the user bits
as is sounds good to me (and unrelated to using overlays for kernel memory).
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> ---
> arch/arm64/include/asm/pgtable-prot.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index 212ce1b02e15..d4d45ab86a5a 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -183,9 +183,9 @@ static inline bool __pure lpa2_is_enabled(void)
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_SHARED_EXEC), PIE_RW) | \
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_READONLY), PIE_R) | \
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_SHARED), PIE_RW) | \
> - PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_ROX), PIE_RX) | \
> - PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_EXEC), PIE_RWX) | \
> - PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_RO), PIE_R) | \
> - PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL), PIE_RW))
> + PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_ROX), PIE_RX_O) | \
> + PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_EXEC), PIE_RWX_O) | \
> + PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_RO), PIE_R_O) | \
> + PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL), PIE_RW_O))
>
> #endif /* __ASM_PGTABLE_PROT_H */
>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] mfd: db8500-prcmu: Fold dbx500 header into db8500
From: Guenter Roeck @ 2026-06-22 13:06 UTC (permalink / raw)
To: Linus Walleij, Russell King, Ulf Hansson, Michael Turquette,
Stephen Boyd, Brian Masney, Rafael J. Wysocki, Daniel Lezcano,
Christian Loehle, Lee Jones, Liam Girdwood, Mark Brown, Zhang Rui,
Lukasz Luba, Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai
Cc: 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>
On 6/19/26 13:27, 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 +-
For watchdog:
Acked-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Steven Rostedt @ 2026-06-22 13:08 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <dbb5915e-6587-4de9-87f3-76bea5024da8@kernel.org>
On Mon, 22 Jun 2026 10:05:13 +0200
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
> > There's been complaints about trace_printk() being defined in kernel.h as it
> > can increase the compilation time. As it is only used by some developers for
> > debugging purposes, it should not be in kernel.h causing lots of wasted CPU
> > cycles for those that do not ever care about it.
>
> Do we have a measurement of the increased compilation time ?
I believe Yury does.
-- Steve
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: soc: xilinx: Add MYIR MYS-7Z020-V2 board
From: Krzysztof Kozlowski @ 2026-06-22 12:25 UTC (permalink / raw)
To: Liu Yu
Cc: Michal Simek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <SY3PPF19552C607716AE1AA440C85D348B6C7E22@SY3PPF19552C607.AUSP300.PROD.OUTLOOK.COM>
On Fri, Jun 19, 2026 at 09:23:54PM +0800, Liu Yu wrote:
> Add compatible string for the MYIR MYS-7Z020-V2 board, based on
> the Xilinx Zynq-7000 XC7Z020 SoC.
>
> Signed-off-by: Liu Yu <f78fk@live.com>
You should not use outlook to send messages. That platform really sucks,
meaning:
1. You might not receive answer for me, because outlook/M$ treats kernel
maintainers as spam and does not care to change it,
2. outlook rewrites message ids making threading often broken.
Recommended is to use b4 relay in such case. You have been warned...
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
From: Lorenzo Bianconi @ 2026-06-22 13:11 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260622123136.GC827683@horms.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]
> On Fri, Jun 19, 2026 at 01:37:14PM +0200, Lorenzo Bianconi wrote:
> > airoha_tc_htb_alloc_leaf_queue() assigns queue IDs based on the channel
> > index (opt->qid = AIROHA_NUM_TX_RING + channel), but updates
> > real_num_tx_queues with a simple increment (num_tx_queues + 1). When QoS
> > channels are allocated sparsely (e.g., channels 0 and 3 without 1 and
> > 2), the returned qid can exceed real_num_tx_queues, causing out-of-bounds
> > accesses in the networking stack.
> > For example, allocating channel 0 then channel 3 results in
> > real_num_tx_queues = 34 but qid = 35, which is out of range [0, 34).
> > Fix this by computing real_num_tx_queues based on the highest active
> > channel index rather than using a simple counter, in both the allocation
> > and deletion paths.
> >
> > Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Thanks for the update since v1.
>
> Reviewed-by: Simon Horman <horms@kernel.org>
Hi Simon,
thx for the review.
>
> FTR, there is an AI-generated review of this patch on sashiko.dev.
> I do not think that should impede the progress of this patch but
> you may want to consider it in the context of follow-up.
Even if it is not introduced by this patch, I do not think what is reported
by Sashiko is a real issue since airoha_eth driver implements
ndo_select_queue() callback and the selected queue is always in the range
[0, AIROHA_NUM_TX_RING[. HTB queues (in the range
[AIROHA_NUM_TX_RING, AIROHA_NUM_TX_RING + AIROHA_NUM_QOS_CHANNELS[) are just
'offloaded' and never used in the TC sw path. Agree?
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Yury Norov @ 2026-06-22 13:11 UTC (permalink / raw)
To: Steven Rostedt
Cc: Christophe Leroy (CS GROUP), linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov,
linux-doc, linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <20260622090826.20efadb3@fedora>
On Mon, Jun 22, 2026 at 09:08:26AM -0400, Steven Rostedt wrote:
> On Mon, 22 Jun 2026 10:05:13 +0200
> "Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
>
> > > There's been complaints about trace_printk() being defined in kernel.h as it
> > > can increase the compilation time. As it is only used by some developers for
> > > debugging purposes, it should not be in kernel.h causing lots of wasted CPU
> > > cycles for those that do not ever care about it.
> >
> > Do we have a measurement of the increased compilation time ?
>
> I believe Yury does.
I re-run compilation is a more strict environment, and the difference
is negligible.
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Krzysztof Kozlowski @ 2026-06-22 13:12 UTC (permalink / raw)
To: Frieder Schrempf, Frieder Schrempf
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <085262ba-32e5-4011-8df3-5a677575b2db@kontron.de>
On 17/06/2026 13:36, Frieder Schrempf wrote:
> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
>> On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
>>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>
>>> Some SoCs like the i.MX9 family allow full access to the fuses only
>>> through the secure enclave firmware API. Add a property to reference
>>> the secure enclave node and let the driver use the API.
>>>
>>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>>> ---
>>> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>> index a8076d0e2737..14a6429f4a4c 100644
>>> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>> @@ -53,6 +53,10 @@ properties:
>>> reg:
>>> maxItems: 1
>>>
>>> + secure-enclave:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description: A phandle to the secure enclave node
>>
>> Two things here:
>> 1. Here you describe what for is that phandle, how it is used by the
>> hardware. Currently the description repeats the property name and type,
>> so not much useful.
>
> Ok, agree.
>
>>
>> 2. If you access OTP via firmware, then this is completely different
>> interface than MMIO, thus:
>> A. reg is not appropriate
>> B. Device is very different thus it has different compatible and I even
>> claim should be in different binding. Devices having completely
>> different SW interface should not be in the same binding, at least
>> usually.
>>
>> If any of above is not accurate, then your commit msg should answer why
>> and give some background.
>
> Thanks for the feedback!
>
> The driver currently uses the limited MMIO (FSB) interface to access the
> OTPs. The intention is to support the firmware interface alongside the
> MMIO interface so the driver can pick the interface that is available
> (firmware might not be loaded) and fallback to MMIO.
>
> Following your argument would mean a driver deciding by itself which
> interface to use at runtime is not something we want to have in general,
> right?
No, the property fits DT, but above information should be in commit msg.
If this SoC has indeed both interfaces - MMIO and firmware calls - then
everything is in general fine. I assumed that is not the case and MMIO
is not really working.
What was confusing is that it feels like you are changing existing
interface, but why wasn't all this documented in the beginning? There is
imx9 in this binding already, so was it working? Was it not working at
all? Commit msg must clarify that.
>
> In turn this would mean we need two drivers, or at least two
> compatibles/bindings for something that is effectively the same hardware.
Driver design is orthogonal choice here.
It can reside in separate binding, if MMIO is still valid, but till
everything is not yet too complex can be also this binding file.
If it stays in this binding, then you need to restrict properties per
variant, so add if:then: block which will disallow the phandle for other
variants.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] arm: dts: xilinx: Add support for MYIR MYS-7Z020-V2 board
From: Michal Simek @ 2026-06-22 13:15 UTC (permalink / raw)
To: Liu Yu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-arm-kernel
In-Reply-To: <SY3PPF19552C60735AFA1041A0183DCA07CC7E22@SY3PPF19552C607.AUSP300.PROD.OUTLOOK.COM>
On 6/19/26 15:23, Liu Yu wrote:
> Add device tree support for the MYIR MYS-7Z020-V2 board based on
> the Xilinx Zynq-7000 XC7Z020 SoC.
>
> The board supports:
> - UART serial console
> - MicroSD card interface
> - Gigabit Ethernet
> - QSPI NOR flash
> - GPIO-based user LEDs and push-button
>
> Link: https://www.myirtech.com/list.asp?id=708
this is pointing to Z-turn Board V2 and above you are using MYS-7Z020-V2
which is not available on this link.
Why should this be merged? What's so special about this board?
Zynq went to production in 2013. Why should we merge description for "unknown"
board using 13 years old chip?
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH RFC v8 04/24] arm64: Introduce por_elx_set_pkey_perms() helper
From: David Hildenbrand (Arm) @ 2026-06-22 13:16 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: Andrew Morton, Andy Lutomirski, Catalin Marinas, Dave Hansen,
Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Marc Zyngier, Mark Brown, Matthew Wilcox,
Maxwell Bland, Mike Rapoport (IBM), Peter Zijlstra,
Pierre Langlois, Quentin Perret, Rick Edgecombe, Ryan Roberts,
Vlastimil Babka, Will Deacon, Yang Shi, Yeoreum Yun,
linux-arm-kernel, linux-mm, x86, Lorenzo Stoakes, Thomas Gleixner
In-Reply-To: <20260526-kpkeys-v8-4-eaaacdacc67c@arm.com>
On 5/26/26 13:15, Kevin Brodsky wrote:
> Introduce a helper that sets the permissions of a given pkey
> (POIndex) in the POR_ELx format, and make use of it in
> arch_set_user_pkey_access().
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> ---
> arch/arm64/include/asm/por.h | 7 +++++++
> arch/arm64/mm/mmu.c | 26 ++++++++++----------------
> 2 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/include/asm/por.h b/arch/arm64/include/asm/por.h
> index d913d5b529e4..bffb4d2b1246 100644
> --- a/arch/arm64/include/asm/por.h
> +++ b/arch/arm64/include/asm/por.h
> @@ -31,4 +31,11 @@ static inline bool por_elx_allows_exec(u64 por, u8 pkey)
> return perm & POE_X;
> }
>
> +static inline u64 por_elx_set_pkey_perms(u64 por, u8 pkey, u64 perms)
> +{
> + u64 shift = POR_ELx_PERM_SHIFT(pkey);
> +
> + return (por & ~(POE_MASK << shift)) | (perms << shift);
> +}
> +
> #endif /* _ASM_ARM64_POR_H */
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index dd85e093ffdb..493310cf0486 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -2339,8 +2339,8 @@ void __cpu_replace_ttbr1(pgd_t *pgdp, bool cnp)
> #ifdef CONFIG_ARCH_HAS_PKEYS
> int arch_set_user_pkey_access(int pkey, unsigned long init_val)
> {
> - u64 new_por;
> - u64 old_por;
> + u64 new_perms;
You should spell out the renaming of the variable.
Given that perms is 4bit per key, should we use a u8 for it instead?
> + u64 por;
>
> if (!system_supports_poe())
> return -ENOSPC;
> @@ -2354,25 +2354,19 @@ int arch_set_user_pkey_access(int pkey, unsigned long init_val)
> return -EINVAL;
>
> /* Set the bits we need in POR: */
> - new_por = POE_RWX;
> + new_perms = POE_RWX;
> if (init_val & PKEY_DISABLE_WRITE)
> - new_por &= ~POE_W;
> + new_perms &= ~POE_W;
> if (init_val & PKEY_DISABLE_ACCESS)
> - new_por &= ~POE_RW;
> + new_perms &= ~POE_RW;
> if (init_val & PKEY_DISABLE_READ)
> - new_por &= ~POE_R;
> + new_perms &= ~POE_R;
> if (init_val & PKEY_DISABLE_EXECUTE)
> - new_por &= ~POE_X;
> + new_perms &= ~POE_X;
>
> - /* Shift the bits in to the correct place in POR for pkey: */
> - new_por = POR_ELx_PERM_PREP(pkey, new_por);
> -
> - /* Get old POR and mask off any old bits in place: */
> - old_por = read_sysreg_s(SYS_POR_EL0);
> - old_por &= ~(POE_MASK << POR_ELx_PERM_SHIFT(pkey));
> -
> - /* Write old part along with new part: */
> - write_sysreg_s(old_por | new_por, SYS_POR_EL0);
> + por = read_sysreg_s(SYS_POR_EL0);
> + por = por_elx_set_pkey_perms(por, pkey, new_perms);
> + write_sysreg_s(por, SYS_POR_EL0);
Was wondering whether to move reading+writing of the register into the same
helper, but you cannot reuse this exactly the same way for SYS_POR_EL1 as it seems.
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] drm/mediatek: mtk_dsi: enable hs clock during pre-enable
From: Adam Thiede @ 2026-06-22 13:23 UTC (permalink / raw)
To: Gary Bisson
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <ajka2220depklK1_@owl5>
On 6/22/26 06:22, Gary Bisson wrote:
> Hi,
>
> On Thu, Jun 18, 2026 at 04:06:28PM -0500, Adam Thiede wrote:
>> On 1/20/26 05:36, Gary Bisson wrote:
>>> Some bridges, such as the TI SN65DSI83, require the HS clock to be
>>> running in order to lock its PLL during its own pre-enable function.
>>>
>>> Without this change, the bridge gives the following error:
>>> sn65dsi83 14-002c: failed to lock PLL, ret=-110
>>> sn65dsi83 14-002c: Unexpected link status 0x01
>>> sn65dsi83 14-002c: reset the pipe
>>>
>>> Move the necessary functions from enable to pre-enable.
>>>
>>> Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
>>> ---
>>> Tested on Tungsten510 module with sn65dsi83 + tm070jdhg30 panel.
>>>
>>> Left mtk_dsi_set_mode() as part of the enable function to mimic what is
>>> done in the Samsung DSIM driver which is known to be working the TI
>>> bridge.
>>> ---
>>> drivers/gpu/drm/mediatek/mtk_dsi.c | 35 +++++++++++++++++------------------
>>> 1 file changed, 17 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> index 0e2bcd5f67b7..b560245d1be9 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> @@ -672,6 +672,21 @@ static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
>>> }
>>> }
>>> +static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
>>> +{
>>> + if (!dsi->lanes_ready) {
>>> + dsi->lanes_ready = true;
>>> + mtk_dsi_rxtx_control(dsi);
>>> + usleep_range(30, 100);
>>> + mtk_dsi_reset_dphy(dsi);
>>> + mtk_dsi_clk_ulp_mode_leave(dsi);
>>> + mtk_dsi_lane0_ulp_mode_leave(dsi);
>>> + mtk_dsi_clk_hs_mode(dsi, 0);
>>> + usleep_range(1000, 3000);
>>> + /* The reaction time after pulling up the mipi signal for dsi_rx */
>>> + }
>>> +}
>>> +
>>> static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>>> {
>>> struct device *dev = dsi->host.dev;
>>> @@ -724,6 +739,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>>> mtk_dsi_set_vm_cmd(dsi);
>>> mtk_dsi_config_vdo_timing(dsi);
>>> mtk_dsi_set_interrupt_enable(dsi);
>>> + mtk_dsi_lane_ready(dsi);
>>> + mtk_dsi_clk_hs_mode(dsi, 1);
>>> return 0;
>>> err_disable_engine_clk:
>>> @@ -769,30 +786,12 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>>> dsi->lanes_ready = false;
>>> }
>>> -static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
>>> -{
>>> - if (!dsi->lanes_ready) {
>>> - dsi->lanes_ready = true;
>>> - mtk_dsi_rxtx_control(dsi);
>>> - usleep_range(30, 100);
>>> - mtk_dsi_reset_dphy(dsi);
>>> - mtk_dsi_clk_ulp_mode_leave(dsi);
>>> - mtk_dsi_lane0_ulp_mode_leave(dsi);
>>> - mtk_dsi_clk_hs_mode(dsi, 0);
>>> - usleep_range(1000, 3000);
>>> - /* The reaction time after pulling up the mipi signal for dsi_rx */
>>> - }
>>> -}
>>> -
>>> static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>>> {
>>> if (dsi->enabled)
>>> return;
>>> - mtk_dsi_lane_ready(dsi);
>>> mtk_dsi_set_mode(dsi);
>>> - mtk_dsi_clk_hs_mode(dsi, 1);
>>> -
>>> mtk_dsi_start(dsi);
>>> dsi->enabled = true;
>>>
>>> ---
>>> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
>>> change-id: 20260120-mtkdsi-29e4c84e7b38
>>>
>>> Best regards,
>>
>> Hello,
>> This commit was part of 7.1 and caused a problem for me.
>> I'm running postmarketOS (basically Alpine Linux) on a Lenovo C330
>> chromebook with a Mediatek MT8173 processor.
>> The problem: when the display on my laptop powers off (via suspend or idle,
>> like xset dpms off) the picture does not come back when the display powers
>> back on (from resume). The display backlight comes on and brightness is
>> adjustable but there is no picture. The only fix is to reboot.
>>
>> Reverting this commit and applying it as a patch on top of 7.1 addresses the
>> issue for me.
>>
>> You can view the config I'm using here:
>> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8819
>>
>> Is there any sort of testing or other debugging info I can provide to help
>> address this issue?
>
> Thanks for reporting the issue, could you share some logs? Is the driver
> saying anything during resume? Also, what type of panel is used on that
> chromebook?
>
> Thanks,
> Gary
The curious thing is that there are no real logs in dmesg or
/var/log/messages about this. This picture just fails to come back. If
there are some kernel params I can set to get deeper logging, that would
help, but I'm not aware of any.
I think the panel is a "BOE NV116WHM-T00" - I used this command to get
info: cat /sys/class/drm/card0-eDP-1/edid | edid-decode
Output: https://termbin.com/8nbd
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: display: vop2: Add missing reset properties
From: Krzysztof Kozlowski @ 2026-06-22 13:25 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Sandy Huang, Heiko Stübner, Andy Yan, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
kernel, Andy Yan, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260617-dw-hdmi-qp-yuv-v1-1-a665cfd06d7d@collabora.com>
On Wed, Jun 17, 2026 at 09:51:54PM +0300, Cristian Ciocaltea wrote:
> Document the VOP2 resets corresponding to the AXI, AHB and DCLK_VP0..2
> clocks, which are common to all supported SoCs, plus DCLK_VP3 which is
> provided only on RK3588.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> .../bindings/display/rockchip/rockchip-vop2.yaml | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: spi: st,stm32-qspi: Add power-domains property
From: Krzysztof Kozlowski @ 2026-06-22 13:26 UTC (permalink / raw)
To: Patrice Chotard
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue, Christophe Kerello, linux-spi,
devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-add_power_domain_for_qpsi-v1-1-4d7e57bcfb9a@foss.st.com>
On Thu, Jun 18, 2026 at 08:46:35AM +0200, Patrice Chotard wrote:
> STM32 QSPI may be in a power domain. Allow a single 'power-domains'
> entry for STM32 QSPI.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
> ---
> Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC v8 05/24] arm64: Implement asm/kpkeys.h using POE
From: David Hildenbrand (Arm) @ 2026-06-22 13:35 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: Andrew Morton, Andy Lutomirski, Catalin Marinas, Dave Hansen,
Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Marc Zyngier, Mark Brown, Matthew Wilcox,
Maxwell Bland, Mike Rapoport (IBM), Peter Zijlstra,
Pierre Langlois, Quentin Perret, Rick Edgecombe, Ryan Roberts,
Vlastimil Babka, Will Deacon, Yang Shi, Yeoreum Yun,
linux-arm-kernel, linux-mm, x86, Lorenzo Stoakes, Thomas Gleixner
In-Reply-To: <20260526-kpkeys-v8-5-eaaacdacc67c@arm.com>
On 5/26/26 13:15, Kevin Brodsky wrote:
> Implement the kpkeys interface if CONFIG_ARM64_POE is enabled.
> The permissions for KPKEYS_PKEY_DEFAULT (pkey 0) are set to RWX as
> this pkey is also used for code mappings.
>
> To allow <asm/kpkeys.h> to be included from assembly, also add
> appropriate #ifdef's to <asm/por.h>.
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> ---
> arch/arm64/include/asm/kpkeys.h | 59 +++++++++++++++++++++++++++++++++++++++++
> arch/arm64/include/asm/por.h | 4 +++
> 2 files changed, 63 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kpkeys.h b/arch/arm64/include/asm/kpkeys.h
> new file mode 100644
> index 000000000000..4dbfeb3dfcfe
> --- /dev/null
> +++ b/arch/arm64/include/asm/kpkeys.h
> @@ -0,0 +1,59 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_KPKEYS_H
> +#define __ASM_KPKEYS_H
> +
> +#include <asm/barrier.h>
> +#include <asm/cpufeature.h>
> +#include <asm/por.h>
> +
> +#include <asm-generic/kpkeys.h>
> +
> +/*
> + * Equivalent to por_set_kpkeys_context(0, KPKEYS_CTX_DEFAULT), but can also be
> + * used in assembly.
> + */
> +#define POR_EL1_INIT POR_ELx_PERM_PREP(KPKEYS_PKEY_DEFAULT, POE_RWX)
Okay, this matches
#define POR_EL0_INIT POR_ELx_PERM_PREP(0, POE_RWX)
Is there a good reason we need KPKEYS_PKEY_DEFAULT at all (and not similarly
just hardcode it to 0)?
Just wondering, because apparently we didn't care about adding an indicator for
user space pkey 0.
> +
> +#ifndef __ASSEMBLY__
> +
> +static inline bool arch_supports_kpkeys(void)
> +{
> + return system_supports_poe();
> +}
> +
> +#ifdef CONFIG_ARM64_POE
> +
> +static inline u64 por_set_kpkeys_context(u64 por, int ctx)
> +{
> + por = por_elx_set_pkey_perms(por, KPKEYS_PKEY_DEFAULT, POE_RWX);
> +
> + return por;
Why not
return por_elx_set_pkey_perms(por, KPKEYS_PKEY_DEFAULT, POE_RWX);
?
In light of API discussions, it would be nicer if arch_kpkeys_set_context()
would just return the old context. But that would mean that restoring the
context would require another read_sysreg_s(SYS_POR_EL1);
So instead of returning magic register values, that should be wrapped in some
arch state struct as mentioned as reply to a previous patch.
> +}
> +
> +static __always_inline void __kpkeys_set_pkey_reg_nosync(u64 pkey_reg)
> +{
> + write_sysreg_s(pkey_reg, SYS_POR_EL1);
> +}
> +
> +static __always_inline u64 arch_kpkeys_set_context(int ctx)
> +{
> + u64 prev_por = read_sysreg_s(SYS_POR_EL1);
> + u64 new_por = por_set_kpkeys_context(prev_por, ctx);
Both can be const.
But maybe you just use a single "por" variable.
> +
> + __kpkeys_set_pkey_reg_nosync(new_por);
> + isb();
> +
> + return prev_por;
> +}
> +
> +static __always_inline void arch_kpkeys_restore_pkey_reg(u64 pkey_reg)
> +{
> + __kpkeys_set_pkey_reg_nosync(pkey_reg);
> + isb();
Why is that isb() for both callers outside of the function? Do you expect
another user that doesn't need the isb?
--
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