* Re: [PATCH] sched_ext: Print deprecation warnings only once
From: Andrea Righi @ 2026-06-23 15:53 UTC (permalink / raw)
To: Christian Loehle
Cc: Breno Leitao, Tejun Heo, David Vernet, Changwoo Min, Ingo Molnar,
Peter Zijlstra, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, sched-ext, linux-kernel, bpf, kernel-team
In-Reply-To: <43d5e4e0-eddb-4a7a-87df-180b9048a038@arm.com>
Hi Breno and Christian,
On Tue, Jun 23, 2026 at 04:45:55PM +0100, Christian Loehle wrote:
> On 6/23/26 15:38, Breno Leitao wrote:
> > The deprecation notices for direct p->scx.slice/dsq_vtime writes and for
> > ops->cpu_acquire/release() use plain pr_warn(), so they repeat on every
> > scheduler (re)load and flood the kernel log.
> > > The slice/dsq_vtime notice is emitted from the BPF verifier's
> > btf_struct_access callback, which runs once per write access and is
> > re-evaluated as the verifier explores paths, so loading a single
> > scheduler can print it several times. The cpu_acquire/release notice is
> > printed on every scheduler enable.
> >
> > Switch both to pr_warn_once() so each deprecation is reported a single
> > time, and add the missing newline to the slice/dsq_vtime message.
>
> I guess this should be warned for once per BPF scheduler like
> sch->warned_deprecated_rq
Yeah, I agree. The thing is that we can load multiple different BPF schedulers,
and we'd want to get these messages for each of them. So ideally we need
something like sch->warned_deprecated_rq.
Thanks,
-Andrea
>
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> > kernel/sched/ext/ext.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> > index 691d53fe0f648..708eb9024cb25 100644
> > --- a/kernel/sched/ext/ext.c
> > +++ b/kernel/sched/ext/ext.c
> > @@ -6988,7 +6988,7 @@ static int validate_ops(struct scx_sched *sch, const struct sched_ext_ops *ops)
> > * run past the BPF allocation. Skip for cid-form.
> > */
> > if (!sch->is_cid_type && (ops->cpu_acquire || ops->cpu_release))
> > - pr_warn("ops->cpu_acquire/release() are deprecated, use sched_switch TP instead\n");
> > + pr_warn_once("ops->cpu_acquire/release() are deprecated, use sched_switch TP instead\n");
> >
> > /*
> > * Sub-scheduler support is tied to the cid-form struct_ops. A sub-sched
> > @@ -7806,7 +7806,7 @@ static int bpf_scx_btf_struct_access(struct bpf_verifier_log *log,
> > off + size <= offsetofend(struct task_struct, scx.slice)) ||
> > (off >= offsetof(struct task_struct, scx.dsq_vtime) &&
> > off + size <= offsetofend(struct task_struct, scx.dsq_vtime))) {
> > - pr_warn("sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated, use scx_bpf_task_set_slice/dsq_vtime()");
> > + pr_warn_once("sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated, use scx_bpf_task_set_slice/dsq_vtime()\n");
> > return SCALAR_VALUE;
> > }
> >
> >
> > ---
> > base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
> > change-id: 20260623-scx_warning-0df49c442afb
> >
> > Best regards,
>
^ permalink raw reply
* [PATCH 0/1] Fix Thunderbolt enumeration
From: Nicholas Johnson @ 2026-06-23 15:53 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Nicholas Johnson, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
I have an Alienware 8950HK with the Thunderbolt 3 port (JHL6340) and OS Native
Enumeration. Unless the Thunderbolt device was attached at boot time, it was
failing to enumerate. I have not bisected the kernel to find out what commit
caused this, but I offer this fix, which I verify fixes the problem.
Here is the problem without the fix applied:
-[0000:00]-+-00.0 Intel Corporation 8th/9th Gen Core Processor Host Bridge / DRAM Registers
+-01.0-[01]--+-00.0 NVIDIA Corporation GP104M [GeForce GTX 1080 Mobile]
| \-00.1 NVIDIA Corporation GP104 High Definition Audio Controller
+-01.1-[02-09]--
+-01.2-[0a-42]----00.0-[0b-0e]--+-00.0-[0c]----00.0 Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016]
| +-01.0-[0d]----00.0-[0e]--
| \-02.0-[0e]----00.0 Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016]
And here we are with the fix applied:
-[0000:00]-+-00.0 Intel Corporation 8th/9th Gen Core Processor Host Bridge / DRAM Registers
+-01.0-[01]--+-00.0 NVIDIA Corporation GP104M [GeForce GTX 1080 Mobile]
| \-00.1 NVIDIA Corporation GP104 High Definition Audio Controller
+-01.1-[02-09]--
+-01.2-[0a-42]----00.0-[0b-42]--+-00.0-[0c]----00.0 Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016]
| +-01.0-[0d-41]----00.0-[0e-10]--+-00.0-[0f]----00.0 PreSonus Audio Electronics Inc. Quantum 2626
| | \-01.0-[10]--
| \-02.0-[42]----00.0 Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016]
I was hoping to get this into Linux v7.2 as a last minute bugfix, but if not, we
can aim for 7.3 hopefully.
Kind regards,
Nicholas Johnson (1):
PCI: Fix bus number allocation for switches with multiple downstream
ports
drivers/pci/probe.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--
2.53.0
^ permalink raw reply
* Re: [PATCH 1/1] platform/x86: hp-wmi: fix platform profile issues on generic HP laptops
From: Krishna Chomal @ 2026-06-23 15:52 UTC (permalink / raw)
To: Marco Scardovi
Cc: moravec, hansg, ilpo.jarvinen, eliadevito, emreleno, rafael,
linux-kernel, platform-driver-x86, regressions, regressions
In-Reply-To: <20260619220911.7542-2-scardracs@disroot.org>
On Sat, Jun 20, 2026 at 12:09:11AM +0200, Marco Scardovi wrote:
>On generic (non-Omen/non-Victus) HP laptops supported by the
>hp-wmi driver, the platform_profile sysfs operations could fail,
>leading to 'platform_profile: Failed to get profile for handler hp-wmi'
>errors and preventing userspace power profile management from working
>correctly.
>
>The driver was blindly registering all 4 profiles (quiet, cool,
>balanced, performance) without checking which ones were actually
>supported by the BIOS. Furthermore, when userspace switched profiles,
>hp_wmi_platform_profile_get() was called, which queried the BIOS
>using thermal_profile_get(). If the BIOS query returned an error or
>returned a value not in the recognized cases, the get call failed,
>throwing an error.
>
>Fix this by:
>1. Dynamically probing which thermal profiles are supported by the BIOS
> during driver registration by temporarily setting each profile and
> checking the return code, then restoring the original profile.
>2. Initializing and updating active_platform_profile to cache the
> last set/boot profile.
>3. Falling back to the cached active_platform_profile in
> hp_wmi_platform_profile_get() if the BIOS query fails or returns
> an invalid/unmapped value, rather than returning an error.
>
>Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220008
Is the patch tested by them?
>Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221569
>Closes: https://lore.kernel.org/platform-driver-x86/a3b137df-1b21-4460-b003-58c5ca2d59d4@ukf.sk/
>Fixes: 4296f679ca50 ("platform/x86: hp-wmi: add platform profile support")
>Assisted-by: Antigravity:gemini-3.5-flash
>Signed-off-by: Marco Scardovi <scardracs@disroot.org>
>---
> drivers/platform/x86/hp/hp-wmi.c | 53 +++++++++++++++++++++++++++++---
> 1 file changed, 48 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/platform/x86/hp/hp-wmi.c b/drivers/platform/x86/hp/hp-wmi.c
>index 8ba286ed8721..93df269445eb 100644
>--- a/drivers/platform/x86/hp/hp-wmi.c
>+++ b/drivers/platform/x86/hp/hp-wmi.c
>@@ -1662,8 +1662,11 @@ static int hp_wmi_platform_profile_get(struct device *dev,
> int tp;
>
> tp = thermal_profile_get();
>- if (tp < 0)
>- return tp;
>+ if (tp < 0) {
>+ guard(mutex)(&active_platform_profile_lock);
>+ *profile = active_platform_profile;
>+ return 0;
>+ }
This does silence the error but I don't think that's a wise decision
since it effectively makes userspace blind to any WMI failure. Ideally,
if thermal_profile_get() fails then the board isn't supposed to be using
HPWMI_THERMAL_PROFILE_QUERY.
>
> switch (tp) {
> case HP_THERMAL_PROFILE_PERFORMANCE:
>@@ -1679,7 +1682,9 @@ static int hp_wmi_platform_profile_get(struct device *dev,
> *profile = PLATFORM_PROFILE_QUIET;
> break;
> default:
>- return -EINVAL;
>+ guard(mutex)(&active_platform_profile_lock);
>+ *profile = active_platform_profile;
>+ break;
> }
>
> return 0;
>@@ -1707,10 +1712,14 @@ static int hp_wmi_platform_profile_set(struct device *dev,
> return -EOPNOTSUPP;
> }
>
>+ guard(mutex)(&active_platform_profile_lock);
>+
> err = thermal_profile_set(tp);
> if (err)
> return err;
>
>+ active_platform_profile = profile;
>+
> return 0;
> }
>
>@@ -2017,8 +2026,23 @@ static int hp_wmi_platform_profile_probe(void *drvdata, unsigned long *choices)
> /* Adding an equivalent to HP Omen software ECO mode: */
> set_bit(PLATFORM_PROFILE_LOW_POWER, choices);
> } else {
>- set_bit(PLATFORM_PROFILE_QUIET, choices);
>- set_bit(PLATFORM_PROFILE_COOL, choices);
>+ int current_tp = thermal_profile_get();
>+
>+ if (current_tp < 0)
>+ return current_tp;
>+
>+ if (thermal_profile_set(HP_THERMAL_PROFILE_QUIET) == 0)
>+ set_bit(PLATFORM_PROFILE_QUIET, choices);
>+ if (thermal_profile_set(HP_THERMAL_PROFILE_COOL) == 0)
>+ set_bit(PLATFORM_PROFILE_COOL, choices);
>+ if (thermal_profile_set(HP_THERMAL_PROFILE_DEFAULT) == 0)
>+ set_bit(PLATFORM_PROFILE_BALANCED, choices);
>+ if (thermal_profile_set(HP_THERMAL_PROFILE_PERFORMANCE) == 0)
>+ set_bit(PLATFORM_PROFILE_PERFORMANCE, choices);
Probing for HP_THERMAL_PROFILE_DEFAULT and HP_THERMAL_PROFILE_PERFORMANCE
seem redundant since those bits are unconditionally set in this function
after the if-else blocks.
>+
>+ /* Restore the original thermal profile */
>+ thermal_profile_set(current_tp);
>+ return 0;
> }
>
> set_bit(PLATFORM_PROFILE_BALANCED, choices);
>@@ -2263,6 +2287,25 @@ static int thermal_profile_setup(struct platform_device *device)
> if (err)
> return err;
>
>+ /* Initialize active_platform_profile */
>+ switch (tp) {
>+ case HP_THERMAL_PROFILE_PERFORMANCE:
>+ active_platform_profile = PLATFORM_PROFILE_PERFORMANCE;
>+ break;
>+ case HP_THERMAL_PROFILE_DEFAULT:
>+ active_platform_profile = PLATFORM_PROFILE_BALANCED;
>+ break;
>+ case HP_THERMAL_PROFILE_COOL:
>+ active_platform_profile = PLATFORM_PROFILE_COOL;
>+ break;
>+ case HP_THERMAL_PROFILE_QUIET:
>+ active_platform_profile = PLATFORM_PROFILE_QUIET;
>+ break;
>+ default:
>+ active_platform_profile = PLATFORM_PROFILE_BALANCED;
>+ break;
>+ }
>+
> ops = &hp_wmi_platform_profile_ops;
> }
>
>--
>2.54.0
>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add Lance as an rmap reviewer
From: Lance Yang @ 2026-06-23 15:52 UTC (permalink / raw)
To: ljs
Cc: akpm, lance.yang, david, riel, liam, vbabka, harry, jannh,
linux-mm, linux-kernel, sj, dev.jain, baohua
In-Reply-To: <20260622155913.280355-1-ljs@kernel.org>
On Mon, Jun 22, 2026 at 04:59:13PM +0100, Lorenzo Stoakes wrote:
>Lance has been doing excellent work reviewing rmap series and has proven
>himself to be a great member of the community in general, so add him as an
>rmap reviewer.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
Thanks a ton, Lorenzo, and thanks everyone for the kind words! Really
happy to jump into the rmap party!
Acked-by: Lance Yang <lance.yang@linux.dev>
^ permalink raw reply
* [PATCH] i3c: master: svc: bound IBI payload to the requested max_payload_len
From: Maoyi Xie @ 2026-06-23 15:51 UTC (permalink / raw)
To: Miquel Raynal, Frank Li
Cc: Alexandre Belloni, Kaixuan Li, linux-i3c, linux-kernel, stable
svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into
the IBI slot. The loop is bounded by the hardware FIFO size
(SVC_I3C_FIFO_SIZE), not by the slot size.
slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool()
sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only
rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can
request a smaller one. mctp-i3c requests 1. Each readsb() then copies the
controller RXCOUNT bytes (up to 31) with no check against the slot size.
A device that sends more bytes than the slot holds writes past
slot->data, an out-of-bounds write into the IBI pool.
Bound the loop by dev->ibi->max_payload_len and clamp each read to the
space left in the slot, the same way dw-i3c does.
Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver")
Cc: stable@vger.kernel.org
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
drivers/i3c/master/svc-i3c-master.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i3c-master.c
index e2d99a3ac07d..7420bfbdd259 100644
--- a/drivers/i3c/master/svc-i3c-master.c
+++ b/drivers/i3c/master/svc-i3c-master.c
@@ -465,9 +465,11 @@ static int svc_i3c_master_handle_ibi(struct svc_i3c_master *master,
buf = slot->data;
while (SVC_I3C_MSTATUS_RXPEND(readl(master->regs + SVC_I3C_MSTATUS)) &&
- slot->len < SVC_I3C_FIFO_SIZE) {
+ slot->len < dev->ibi->max_payload_len) {
mdatactrl = readl(master->regs + SVC_I3C_MDATACTRL);
count = SVC_I3C_MDATACTRL_RXCOUNT(mdatactrl);
+ count = min_t(unsigned int, count,
+ dev->ibi->max_payload_len - slot->len);
readsb(master->regs + SVC_I3C_MRDATAB, buf, count);
slot->len += count;
buf += count;
^ permalink raw reply related
* Re: [PATCH 1/8] clk: qcom: dispcc-sm8450: Fix mdss clocks
From: Konrad Dybcio @ 2026-06-23 15:50 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-1-37e2ee8df9da@proton.me>
On 6/23/26 2:54 AM, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> Both of these changes allow the framebuffer to show upon boot and let
> the mdss driver take over afterwards.
> Before, none of these actions were possible. Only mdss takeover was
> possible, but screen had to be turned off first.
>
> OLE configuration may have been a misinterpretation... that's not
> something that's done on the downstream driver.
>
> Changing disp_cc_mdss_mdp_clk_src from clk_rcg2_shared_ops to
> clk_rcg2_shared_no_init_park_ops fixes this warning as well:
[...]
> drivers/clk/qcom/dispcc-sm8450.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/qcom/dispcc-sm8450.c b/drivers/clk/qcom/dispcc-sm8450.c
> index 2e91332dd92a..b99d3eb5e195 100644
> --- a/drivers/clk/qcom/dispcc-sm8450.c
> +++ b/drivers/clk/qcom/dispcc-sm8450.c
> @@ -614,7 +614,7 @@ static struct clk_rcg2 disp_cc_mdss_mdp_clk_src = {
> .parent_data = disp_cc_parent_data_5,
> .num_parents = ARRAY_SIZE(disp_cc_parent_data_5),
> .flags = CLK_SET_RATE_PARENT,
> - .ops = &clk_rcg2_shared_ops,
> + .ops = &clk_rcg2_shared_no_init_park_ops,
> },
> };
>
> @@ -1824,8 +1824,8 @@ static int disp_cc_sm8450_probe(struct platform_device *pdev)
> disp_cc_pll1.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID_OLE];
> disp_cc_pll1.clkr.hw.init = &sm8475_disp_cc_pll1_init;
>
> - clk_lucid_ole_pll_configure(&disp_cc_pll0, regmap, &sm8475_disp_cc_pll0_config);
> - clk_lucid_ole_pll_configure(&disp_cc_pll1, regmap, &sm8475_disp_cc_pll1_config);
> + clk_lucid_evo_pll_configure(&disp_cc_pll0, regmap, &sm8475_disp_cc_pll0_config);
> + clk_lucid_evo_pll_configure(&disp_cc_pll1, regmap, &sm8475_disp_cc_pll1_config);
> } else {
> clk_lucid_evo_pll_configure(&disp_cc_pll0, regmap, &disp_cc_pll0_config);
> clk_lucid_evo_pll_configure(&disp_cc_pll1, regmap, &disp_cc_pll1_config);
This can also be fixed by migrating to use qcom_cc_driver_data,
which takes a list of alpha PLLs to be configured, and thenthere's
a switch-statement in clk-alpha-pll.c that always assigns the
correct function
Konrad
^ permalink raw reply
* Re: [PATCH v2] EDAC/amd64: Only translate Node ID if GPU nodes are present
From: Yazen Ghannam @ 2026-06-23 15:49 UTC (permalink / raw)
To: Borislav Petkov
Cc: Phineas Su, tony.luck, muralidhara.mk, linux-edac, linux-kernel
In-Reply-To: <20260623004959.GAajnYN-WCJ8GRWMHh@fat_crate.local>
On Mon, Jun 22, 2026 at 05:49:59PM -0700, Borislav Petkov wrote:
> On Mon, Jun 22, 2026 at 01:07:17PM -0400, Yazen Ghannam wrote:
> > I do agree, in principle, about hardening against possible new
> > configurations.
>
> Are those configurations going to happen?
Not that I'm aware.
>
> If so, we can harden when that happens. We don't do hypothetical coding yet.
>
Okay, no problem.
Thanks,
Yazen
^ permalink raw reply
* Re: [PATCH 1/2] bug: Provide WARN_ON.*DEFERRED() macros for console deferred output
From: Petr Mladek @ 2026-06-23 15:49 UTC (permalink / raw)
To: Andrew Morton
Cc: Sebastian Andrzej Siewior, linux-arch, linux-kernel, sched-ext,
netdev, David S . Miller, Andrea Righi, Arnd Bergmann, Ben Segall,
Breno Leitao, Changwoo Min, David Vernet, Dietmar Eggemann,
Eric Dumazet, Ingo Molnar, Jakub Kicinski, John Ogness,
Juri Lelli, K Prateek Nayak, Paolo Abeni, Peter Zijlstra,
Sergey Senozhatsky, Simon Horman, Steven Rostedt, Tejun Heo,
Vincent Guittot, Vlad Poenaru
In-Reply-To: <20260623081258.580e034fdb5b98f4f8dba44a@linux-foundation.org>
On Tue 2026-06-23 08:12:58, Andrew Morton wrote:
> On Tue, 23 Jun 2026 16:26:49 +0200 Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>
> > Provide a deferred version of the WARN_ON() macro. It will delay
> > flushing the console until a later context. It is needed in a context
> > where the caller holds locks which can lead to a deadlock content is
> > flushed to the console driver.
> > An example would from a warning from within the scheduler resulting in a
> > wake-up of a task.
> >
> > Deferring the output works by using printk_deferred_enter/ exit() around
> > the printing output. This must be used in a context where the task can't
> > migrate to another CPU. This should be the case usually, since the
> > scheduler would acquire the rq lock whith disabled interrupts, but to be
> > safe preemption is disabled to guarantee this.
> >
> > In order not to bloat the code on architectures which provide an
> > optimized __WARN_FLAGS() define BUGFLAG_DEFERRED which is handled by
> > __report_bug() and does not increase the code size.
> >
> > Provide the DEFERRED macros based on __WARN_FLAGS and __WARN_FLAGS
> > macros. Extend __report_bug() to handle the deferred case.
> >
> > ...
> >
> > --- a/include/asm-generic/bug.h
> > +++ b/include/asm-generic/bug.h
> > @@ -229,7 +230,10 @@ static enum bug_trap_type __report_bug(struct bug_entry *bug, unsigned long buga
> > */
> > bug->flags |= BUGFLAG_DONE;
> > }
> > -
> > + if (deferred) {
> > + preempt_disable_notrace();
> > + printk_deferred_enter();
> > + }
>
> For some reason the comment over printk_deferred_enter() says
> "Interrupts must be disabled for the deferred duration". Is that the
> case for all the printk_deferred_enter() calls which this patch adds?
Strictly speaking, "only" CPU migration must be disabled around
printk_deferred_enter()/exit() call because the state is stored
in a per-CPU variable.
It means that preempt_disable() would work.
I do not recall whether we mentioned interrupts by mistake or
on purpose. It is possible that we suggested to disable interrupts
because we did not want to deffer messages from unrelated (interrupt)
context.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v3 1/9] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE
From: Robin Murphy @ 2026-06-23 15:48 UTC (permalink / raw)
To: Matt Evans, Tian, Kevin, Pranjal Shrivastava
Cc: Alex Williamson, Leon Romanovsky, Jason Gunthorpe, Alex Mastro,
Christian König, Bjorn Helgaas, Logan Gunthorpe,
Mahmoud Adam, David Matlack, Björn Töpel, Sumit Semwal,
Ankit Agrawal, Alistair Popple, Kasireddy, Vivek,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
kvm@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <0dfadf98-a904-4e6a-b078-5caf27bc7922@ozlabs.org>
On 12/06/2026 3:31 pm, Matt Evans wrote:
> Hi Kevin, Pranjal, (+Robin, hi!)
Oh hey there! :)
> On 12/06/2026 04:39, Tian, Kevin wrote:
>>> From: Pranjal Shrivastava <praan@google.com>
>>> Sent: Friday, June 12, 2026 2:38 AM
>>>
>>> On Wed, Jun 10, 2026 at 04:43:15PM +0100, Matt Evans wrote:
>>>> --- a/drivers/pci/Kconfig
>>>> +++ b/drivers/pci/Kconfig
>>>> @@ -206,11 +206,7 @@ config PCIE_TPH
>>>> config PCI_P2PDMA
>>>> bool "PCI peer-to-peer transfer support"
>>>> depends on ZONE_DEVICE
>>>> - #
>>>> - # The need for the scatterlist DMA bus address flag means PCI
>>> P2PDMA
>>>> - # requires 64bit
>>>> - #
>>>> - depends on 64BIT
>>>> + select PCI_P2PDMA_CORE
>>>> select GENERIC_ALLOCATOR
>>>> select NEED_SG_DMA_FLAGS
>>>> help
>>>
>>> Nit: Did we drop depends on 64BIT intentionally here? I guess the full
>>> PCI_P2PDMA stack still selects NEED_SG_DMA_FLAGS? IIRC,
>>> NEED_SG_DMA_FLAGS doesn't select 64BIT?
>>
>> seems that comment is stale. According to the commit msg:
>>
>> " it would make vfio-pci only available if CONFIG_ZONE_DEVICE is
>> present (e.g. 64-bit systems), "
>>
>> so it sounds a redundant dependency hence is removed.
>
> This was intentional. In practice there is still a dependency on 64BIT
> for PCI_P2PDMA, but it is because of ZONE_DEVICE (and mem hotplug). The
> key need is PCI_P2PDMA_CORE is available on !64BIT for VFIO, but I
> didn't see a requirement from PCI_P2PDMA itself (as opposed to its
> dependencies). If I've missed one, I can put it back...
>
> But NEED_SG_DMA_FLAGS doesn't smell quite right; I see from comments in
>
> af2880ec44021 ("scatterlist: add dedicated config for DMA flags")
>
> that it assumes 64BIT, but it seems to be missing a "depends on 64BIT".
>
> Robin -- should that depend on 64BIT?
Indeed, looking at the history it seems like that was overlooked, but it
worked out at the time since the only selector of NEED_SG_DMA_FLAGS was
PCI_P2PDMA as you say. If we're now generalising then moving the
explicit 64BIT dependency to NEED_SG_DMA_FLAGS itself sounds like the
right thing to do.
Cheers,
Robin.
^ permalink raw reply
* Re: [PATCH 2/13] dt-bindings: sound: Add Qualcomm QAIF binding
From: Konrad Dybcio @ 2026-06-23 15:48 UTC (permalink / raw)
To: Harendra Gautam
Cc: Srinivas Kandagatla, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <CAC-tS8CuhED2dvne=cuTBUcrL93WXPjNB-nDUYHWNtFF9oVVjQ@mail.gmail.com>
On 6/23/26 2:26 PM, Harendra Gautam wrote:
> On Tue, Jun 9, 2026 at 3:27 PM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 6/5/26 12:37 PM, Harendra Gautam wrote:
>>> Add a Devicetree binding for the Qualcomm Audio Interface (QAIF) CPU DAI
>>> controller used on the Shikra audio platform.
>>>
>>> QAIF moves PCM data between system memory and external serial audio
>>> interfaces through the AIF path, and between memory and the internal Bolero
>>> digital codec through the CIF path. The controller needs a binding so
>>> platform Devicetree files can describe its MMIO region, DMA IOMMU stream,
>>> clocks, interrupt, DAI cells and per-interface AIF configuration.
>>>
>>> Describe the single register region, one EE interrupt, the required GCC
>>> LPASS and audio core clocks, the DMA IOMMU mapping, and 'aif-interface@N'
>>> child nodes used for static PCM, TDM or MI2S configuration.
>>>
>>> Signed-off-by: Harendra Gautam <harendra.gautam@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> + clock-names:
>>> + items:
>>> + - const: lpass_config_clk
>>> + - const: lpass_core_axim_clk
>>> + - const: aud_dma_clk
>>> + - const: aud_dma_mem_clk
>>> + - const: bus_clk
>>> + - const: aif_if0_ebit_clk
>>> + - const: aif_if0_ibit_clk
>>> + - const: aif_if1_ebit_clk
>>> + - const: aif_if1_ibit_clk
>>> + - const: aif_if2_ebit_clk
>>> + - const: aif_if2_ibit_clk
>>> + - const: aif_if3_ebit_clk
>>> + - const: aif_if3_ibit_clk
>>> + - const: ext_mclka_clk
>>> + - const: ext_mclkb_clk
>>
>> Drop the _clk suffix, we already know they are clocks, as they are
>> listed under the clocks property
> Okay, will correct.
>>
>> [...]
>>
>>> + qcom,qaif-aif-sync-mode:
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> + description:
>>> + Sync mode. Use QAIF_AIF_SYNC_MODE_SHORT (0) for short (pulse)
>>> + sync or QAIF_AIF_SYNC_MODE_LONG (1) for long (level) sync.
>>> + qcom,qaif-aif-sync-src:
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> + description:
>>> + Sync source. Use QAIF_AIF_SYNC_SRC_SLAVE (0) for slave mode
>>> + or QAIF_AIF_SYNC_SRC_MASTER (1) for master mode.
>>
>> Should these be boolean flags then?
> It should not be, the intention is to define explicitly, for better
> readability I can rename these flags as EXTERNAL/INTERNAL, Please
> suggest.
Are all 4 combinations of them being present/absent valid on shikra?
Konrad
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Fuad Tabba @ 2026-06-23 15:46 UTC (permalink / raw)
To: Bradley Morgan
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <54A2BB77-5E81-4730-82A1-DB457118784C@grrlz.net>
Hi Bradley,
On Tue, 23 Jun 2026 at 16:11, Bradley Morgan <include@grrlz.net> wrote:
>
> On June 23, 2026 4:03:30 PM GMT+01:00, Fuad Tabba <fuad.tabba@linux.dev>
> wrote:
> >On Tue, 23 Jun 2026 at 16:01, Bradley Morgan <include@grrlz.net> wrote:
> >>
> >> On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org>
> >wrote:
> >> >On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
> >> >> Protected guest faults charge long term pins to the VM's mm. Teardown
> >> >> can run later from file release, where current->mm may be unrelated.
> >> >>
> >> >> Drop the charge from kvm->mm instead.
> >> >>
> >> >>
> >> >
> >> >Applied to fixes, thanks!
> >> >
> >> >[1/1] KVM: arm64: account pKVM reclaim against the VM mm
> >> > commit: d098bb75d14fde2f12155f1a95ec0168160867ce
> >> >
> >> >Cheers,
> >> >
> >> > M.
> >> >
> >>
> >>
> >> Hey, which tree did you apply it to?
> >
> >https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=fixes
> >
> >/fuad
> >
> >>
> >>
> >> Thanks!
> >
>
> Thanks fuad.
>
> May I ask if this would be put onto ACK?
Yes, I'll pick it into ACK.
Cheers,
/fuad
>
> Since this affects pixel devices.
>
> (E.g, my pixel 7....)
>
> Thanks!
^ permalink raw reply
* Re: [PATCH] sched_ext: Print deprecation warnings only once
From: Christian Loehle @ 2026-06-23 15:45 UTC (permalink / raw)
To: Breno Leitao, Tejun Heo, David Vernet, Andrea Righi, Changwoo Min,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak
Cc: sched-ext, linux-kernel, bpf, kernel-team
In-Reply-To: <20260623-scx_warning-v1-1-14bf218f4bd9@debian.org>
On 6/23/26 15:38, Breno Leitao wrote:
> The deprecation notices for direct p->scx.slice/dsq_vtime writes and for
> ops->cpu_acquire/release() use plain pr_warn(), so they repeat on every
> scheduler (re)load and flood the kernel log.
> > The slice/dsq_vtime notice is emitted from the BPF verifier's
> btf_struct_access callback, which runs once per write access and is
> re-evaluated as the verifier explores paths, so loading a single
> scheduler can print it several times. The cpu_acquire/release notice is
> printed on every scheduler enable.
>
> Switch both to pr_warn_once() so each deprecation is reported a single
> time, and add the missing newline to the slice/dsq_vtime message.
I guess this should be warned for once per BPF scheduler like
sch->warned_deprecated_rq
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> kernel/sched/ext/ext.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 691d53fe0f648..708eb9024cb25 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
> @@ -6988,7 +6988,7 @@ static int validate_ops(struct scx_sched *sch, const struct sched_ext_ops *ops)
> * run past the BPF allocation. Skip for cid-form.
> */
> if (!sch->is_cid_type && (ops->cpu_acquire || ops->cpu_release))
> - pr_warn("ops->cpu_acquire/release() are deprecated, use sched_switch TP instead\n");
> + pr_warn_once("ops->cpu_acquire/release() are deprecated, use sched_switch TP instead\n");
>
> /*
> * Sub-scheduler support is tied to the cid-form struct_ops. A sub-sched
> @@ -7806,7 +7806,7 @@ static int bpf_scx_btf_struct_access(struct bpf_verifier_log *log,
> off + size <= offsetofend(struct task_struct, scx.slice)) ||
> (off >= offsetof(struct task_struct, scx.dsq_vtime) &&
> off + size <= offsetofend(struct task_struct, scx.dsq_vtime))) {
> - pr_warn("sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated, use scx_bpf_task_set_slice/dsq_vtime()");
> + pr_warn_once("sched_ext: Writing directly to p->scx.slice/dsq_vtime is deprecated, use scx_bpf_task_set_slice/dsq_vtime()\n");
> return SCALAR_VALUE;
> }
>
>
> ---
> base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
> change-id: 20260623-scx_warning-0df49c442afb
>
> Best regards,
^ permalink raw reply
* RE: [PATCH] MAINTAINERS: Add entries for Renesas Versaclock {3,7} clock drivers
From: Biju Das @ 2026-06-23 15:45 UTC (permalink / raw)
To: Brian Masney, Geert Uytterhoeven, biju.das.au
Cc: magnus.damm, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
In-Reply-To: <ajqWevofEJ3fv856@redhat.com>
Hi Brian Masney,
Thanks for the feedback.
> -----Original Message-----
> From: Brian Masney <bmasney@redhat.com>
> Sent: 23 June 2026 15:22
> Subject: Re: [PATCH] MAINTAINERS: Add entries for Renesas Versaclock {3,7} clock drivers
>
> Hi Geert and Biju,
>
> On Fri, Sep 05, 2025 at 03:34:38PM +0100, Biju wrote:
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > Add entries for Renesas versaclock 3 clock driver. While at it add
> > myself as maintainer for versaclock 7 clock driver as Alex's email
> > address bounces.
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > MAINTAINERS | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > b13848dade9e..7a7478305bf1 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -21704,10 +21704,12 @@ L: linux-renesas-soc@vger.kernel.org
> > S: Maintained
> > F: drivers/phy/renesas/phy-rcar-gen3-usb*.c
> >
> > -RENESAS VERSACLOCK 7 CLOCK DRIVER
> > -M: Alex Helms <alexander.helms.jy@renesas.com>
> > +RENESAS VERSACLOCK 3 and VERSACLOCK 7 CLOCK DRIVER
> > +M: Biju Das <biju.das.jz@bp.renesas.com>
> > S: Maintained
> > +F: Documentation/devicetree/bindings/clock/renesas,5p35023.yaml
> > F: Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml
> > +F: drivers/clk/clk-versaclock3.c
> > F: drivers/clk/clk-versaclock7.c
>
> It looks like this patch wasn't picked up last year. I got another bounce from Alex's email address.
>
> Geert: Can you pick up this patch?
>
> Biju: I see that
> Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml also needs to have it's maintainers
> updated.
OK, I will send a patch for updating binding as well.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v7 10/14] platform/x86/intel/pmt: Register enumeration functions with resctrl
From: Reinette Chatre @ 2026-06-23 15:45 UTC (permalink / raw)
To: Luck, Tony
Cc: Fenghua Yu, Maciej Wieczor-Retman, Peter Newman, James Morse,
Babu Moger, Drew Fustini, Dave Martin, Chen Yu, David E Box, x86,
Christoph Hellwig, linux-kernel, patches
In-Reply-To: <ajm-jVzj7TUeJkY-@agluck-desk3>
Hi Tony,
On 6/22/26 4:00 PM, Luck, Tony wrote:
> On Mon, Jun 22, 2026 at 08:46:31AM -0700, Reinette Chatre wrote:
>> On 6/18/26 2:15 PM, Luck, Tony wrote:
>>> On Mon, Jun 08, 2026 at 04:22:27PM -0700, Reinette Chatre wrote:
>>>> On 6/1/26 12:56 PM, Tony Luck wrote:
>>>>> INTEL_PMT_TELEMETRY is a loadable module, but resctrl is built-in and cannot
>>>>> call PMT functions directly. Register the telemetry enumeration function
>>>>> pointers at pmt_telemetry module init, and unregister them at module exit.
>>>>
>>>> To ensure intel_pmt_get_regions_by_feature() has access to complete data, could
>>>> it be more accurate to register at the end of PMT's .probe() and similarly
>>>> unregister during .remove()?
>>>
>>> I agreed with this. But on further reflection I'm going to dissent.
>>>
>>> There are multiple devices (at least one per socket). So .probe() is
>>> called for each. Registering with resctrl at the end of .probe() sets
>>
>> Thanks for highlighting this.
>>
>>> up for a race with a mount of the resctrl file system:
>>>
>>> modprobe mount
>>> .init()
>>> auxiliary_driver_register()
>>> .probe() for socket 0 device rdt_get_tree()
>>> intel_aet_register_enumeration() resctrl_arch_pre_mount()
>>> mutex_lock(aet_register_lock) intel_aet_pre_mount()
>>> get_feature = get; mutex_lock(aet_register_lock)
>>> ... ... blocks ...
>>> mutex_unlock(aet_register_lock)
>>> ... runs ...
>>> .probe() for socket 1 device Does enumeration with socket 0 complete
>>> but races with socket 1 .probe()
>>
>> Could you please elaborate the details being the "race with socket 1"? Wouldn't
>> moving registration to init() experience the same? That is, if registered during init() then
>> at the time of resctrl mount socket 0's probe could be complete but not socket 1's? The
>> move to .init() has additional scenario where resctrl mounts when neither socket's
>> probe has completed.
>
> See '*' paragraph below. At end of pmt_telemetry .init() all probes have run and completed.
>
>> Are you referring to how user needs to remount resctrl to obtain all of AET that
>> the doc patch refers to or is the race more serious?
>>
>>> I may keep the unregister call in the .remove() because as soon as the first
>>> device goes away, resctrl can't usefully run. So it seems a good idea to
>>> handle that right away.
>>
>> The "resctrl can't usefully run" is not clear to me since resctrl mount seems to be
>> ok to let mount succeed without all devices probed (per above). So it is ok to mount
>> resctrl with partial telemetry enumeration but once all is enumerated this will not
>> be supported?
>
> No. Mount shouldn't run unless all devices have been probed.
>
>>>
>>> I will provide details on the reason for the asymmetric .init() vs. .remove()
>>> in the commit comment (and in code).
>>>
>>> Ok?
>>
>> I seem to be missing a few details to understand this solution.
>
> For AET telemetry to be useful all aggregators must be enumerated.
> Running with some subset would only provide data for some subset of
> the cores on a system.
>
> So now I'm trending back to registering in module .init() after
> all probes have run, and unregistering in .exit() before doing
> anything else.
>
> Some experimentation has shown that the asynchronous part enumeration
> is just the intel_vsec driver kicking of auxilliary device probes.
>
> * Looking just at the pmt_telemetry .init() routine, the .probe()
> * calls for each device are run sequentially and synchronously. So
> * when .init() returns all of the AET enumeration is complete.
If I understand correctly this is because pmt_telemetry relies on
device_driver::probe_type initialized with the default (PROBE_DEFAULT_STRATEGY)
that can be overruled by a user space wanting to "boot faster".
Should pmt_telemetry's probe_type be set to PROBE_FORCE_SYNCHRONOUS to support
this new requirement from resctrl?
>
> Today I dug into the problem that mount initiated automatically
> by systemd from an entry in /etc/fstab occurs before pmt_telemetry
> is loaded. I asked AI (Gemini) if there was a way to let systemd
> know it must wait for enumeration to complete before invoking
> mount(2). There are MANY options to do this. After cycling through
> several that either didn't work, or seemed overly complex or fragile,
> I've settled on this one. I can add to the resctrl.rst documentation.
>
> It uses a systemd service to mount resctrl triggered by a udev rule on the
> load of the pmt_telemetry module.
>
> The udev rule:
> $ cat /etc/udev/rules.d/99-rmid-telemetry.rules
> SUBSYSTEM=="module", KERNEL=="intel_pmt", ACTION=="add", RUN+="/usr/bin/systemctl start mount-resctrl.service"
>
> The systemd service descriptor:
> $ cat /etc/systemd/system/mount-resctrl.service
> [Unit]
> Description=Mount resctrl pseudo-filesystem after Intel PMT loads
> After=local-fs.target
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/usr/bin/mount -t resctrl resctrl /sys/fs/resctrl
>
> [Install]
> WantedBy=multi-user.target
>
This looks very helpful. Thank you very much for investigating this.
Reinette
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: rtc: sun6i: Add Allwinner A733 support
From: Chen-Yu Tsai @ 2026-06-23 15:42 UTC (permalink / raw)
To: Jerome Brunet, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Jernej Skrabec, Samuel Holland,
Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, linux-clk, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-rtc, devicetree
In-Reply-To: <1j1pe7elxm.fsf@starbuckisacylon.baylibre.com>
On Tue, Jun 16, 2026 at 1:46 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On sam. 28 mars 2026 at 20:37, Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > On Wed, Jan 21, 2026 at 7:03 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
> >>
> >> The RTC module in the Allwinner A733 SoC is functionally compatible with
> >> the sun6i RTC, but its internal Clock Control Unit (CCU) has significant
> >> changes.
> >>
> >> The A733 supports selecting the oscillator between three frequencies:
> >> 19.2MHz, 24MHz, and 26MHz. The RTC CCU relies on hardware to detect
> >> which frequency is actually used on the board. By defining all three
> >> frequencies as fixed-clocks in the device tree, the driver can identify
> >> the hardware-detected frequency and expose it to the rest of the system.
> >
> > No. The board device tree shall have the exact and correct frequency
> > defined in the external crystal device node. The operating system can
> > use the hardware-detected frequency to "fix" the in-system representation
> > if it is off.
> >
> >> Additionally, the A733 RTC CCU provides several new DCXO gate clocks for
> >> specific modules, including SerDes, HDMI, and UFS.
> >>
> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> >> ---
> >> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 38 ++++++++++++++++++++--
> >> include/dt-bindings/clock/sun60i-a733-rtc.h | 16 +++++++++
> >> 2 files changed, 52 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >> index 9df5cdb6f63f..b18431955783 100644
> >> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >> @@ -26,6 +26,7 @@ properties:
> >> - allwinner,sun50i-h6-rtc
> >> - allwinner,sun50i-h616-rtc
> >> - allwinner,sun50i-r329-rtc
> >> + - allwinner,sun60i-a733-rtc
> >> - items:
> >> - const: allwinner,sun50i-a64-rtc
> >> - const: allwinner,sun8i-h3-rtc
> >> @@ -46,11 +47,11 @@ properties:
> >>
> >> clocks:
> >> minItems: 1
> >> - maxItems: 4
> >> + maxItems: 6
> >>
> >> clock-names:
> >> minItems: 1
> >> - maxItems: 4
> >> + maxItems: 6
> >>
> >> clock-output-names:
> >> minItems: 1
> >> @@ -156,6 +157,38 @@ allOf:
> >> - clocks
> >> - clock-names
> >>
> >> + - if:
> >> + properties:
> >> + compatible:
> >> + contains:
> >> + const: allwinner,sun60i-a733-rtc
> >> +
> >> + then:
> >> + properties:
> >> + clocks:
> >> + minItems: 5
> >> + items:
> >> + - description: Bus clock for register access
> >
> >> + - description: 19.2 MHz oscillator
> >> + - description: 24 MHz oscillator
> >> + - description: 26 MHz oscillator
> >
> > No. There is only one input. As in there is only one set of pins for the
> > DCXO. The inputs are the same as on R329 / A523. Just use that list.
> >
> >> + - description: AHB parent for internal SPI clock
> >> + - description: External 32768 Hz oscillator
> >> +
> >> + clock-names:
> >> + minItems: 5
> >> + items:
> >> + - const: bus
> >> + - const: osc19M
> >> + - const: osc24M
> >> + - const: osc26M
> >> + - const: ahb
> >> + - const: ext-osc32k
> >> +
> >> + required:
> >> + - clocks
> >> + - clock-names
> >> +
> >> - if:
> >> properties:
> >> compatible:
> >> @@ -164,6 +197,7 @@ allOf:
> >> - allwinner,sun8i-r40-rtc
> >> - allwinner,sun50i-h616-rtc
> >> - allwinner,sun50i-r329-rtc
> >> + - allwinner,sun60i-a733-rtc
> >>
> >> then:
> >> properties:
> >> diff --git a/include/dt-bindings/clock/sun60i-a733-rtc.h b/include/dt-bindings/clock/sun60i-a733-rtc.h
> >> new file mode 100644
> >> index 000000000000..8a2b5facad73
> >> --- /dev/null
> >> +++ b/include/dt-bindings/clock/sun60i-a733-rtc.h
> >> @@ -0,0 +1,16 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
> >> +
> >> +#ifndef _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
> >> +#define _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
> >> +
> >> +#define CLK_IOSC 0
> >> +#define CLK_OSC32K 1
> >> +#define CLK_HOSC 2
> >
> > The DCXO enable control has been present since at least the H6. We just
> > never added it, as we would never disable it anyway.
> >
> > If you compare the RTC clock trees of the A733 and A523, the only addition
> > besides the new gates seems to be the LOSC auto selection. But even that
> > is just an illusion, as the A523 has the same registers for that.
> >
> > One could say the A733 RTC is almost backward compatible to the A523, if
> > not for the two fastboot registers the A523 has at 0x120 and 0x124.
> >
> > So I ask that you try to integrate the differences into the existing
> > driver and bindings. You can tweak and export internal clks if you
> > need.
>
> I'd like to help with that. I think it is doable but I have a question
> regarding the binding of the existing driver, more precisely their usage
> here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c?h=v7.1#n370
>
> Clock indexes are supposed to be stable in DT (AFAIK) but with the code
> linked the external 32k is at:
>
> * "ext-32k" - so index 3 - if "clock-names" is present
> * index 0 if clock names is not present
>
> ... but index 0 is supposed to be the bus clock according the binding
> doc, whether "clock-names" is there or not :/
>
> So what are those old r329 bindings ? is there a documentation defining
> them somewhere ?
You can look at
8487614a8a8a dt-bindings: rtc: sun6i: Add H616, R329, and D1 support
In hindsight maybe the two bindings should be separate. The old SoCs
did not have all these clock inputs from the main clock controller.
The only input it could possibly take was the external 32k crystal.
> Cleaning that part would help with A733 addition in the existing driver
> I think
Yeah. Also, we can treat the bindings and drivers separately. We could
have two bindings but one common driver, or vice versa. As you pointed
out, the bindings are a bit messed up, so we could consider separating
them.
If we end up with separate binding header files, maybe we could use
a different prefix for the new ones so they don't collide? That way
the driver could maybe still be shared?
As for whether to share the headers, I think they should be treated
as part of the binding, so if the bindings are shared, then they can
be shared as well; if the bindings are separate, then they should be
completely separate files as well.
And sorry for the late reply.
Thanks
ChenYu
> >
> >> +#define CLK_RTC_32K 3
> >
> > AFAICT besides being an internal clock, this is also fed to GPIO for
> > debounce? We probably need to expose this on the A523 as well.
> >
> >
> > Thanks
> > ChenYu
> >
> >
> >> +#define CLK_OSC32K_FANOUT 4
> >> +#define CLK_HOSC_SERDES1 5
> >> +#define CLK_HOSC_SERDES0 6
> >> +#define CLK_HOSC_HDMI 7
> >> +#define CLK_HOSC_UFS 8
> >> +
> >> +#endif /* _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_ */
> >>
> >> --
> >> 2.52.0
> >>
> >>
>
> --
> Jerome
>
^ permalink raw reply
* Re: [PATCH v2] drm/panthor: Fix NPD issue on partial unmap of an evicted BO
From: Liviu Dudau @ 2026-06-23 15:40 UTC (permalink / raw)
To: Akash Goel
Cc: boris.brezillon, steven.price, dri-devel, linux-kernel,
maarten.lankhorst, mripard, tzimmermann, airlied, daniel, nd
In-Reply-To: <20260623130119.2737003-1-akash.goel@arm.com>
On Tue, Jun 23, 2026 at 02:01:19PM +0100, Akash Goel wrote:
> This commit fixes the NULL pointer dereference issue that would have
> happened on the split of GPU mapping due to partial unmap of an evicted
> BO. There is a logic to handle the partial unmap of huge pages when the
> GPU mapping is split. That logic was not being completely skipped for
> the VMA of an evicted BO and that resulted in a NPD possibility for the
> 'bo->backing.pages' pointer, which is set to NULL when pages of a
> BO are released on eviction.
>
> Following dump was seen when a partial unmap was exercised for an
> evicted BO.
> Unable to handle kernel paging request at virtual address 0000000000002000
> Mem abort info:
> ESR = 0x0000000096000004
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x04: level 0 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> user pgtable: 4k pages, 48-bit VAs, pgdp=00000008842e8000
> [0000000000002000] pgd=0000000000000000, p4d=0000000000000000
> Internal error: Oops: 0000000096000004 [#1] SMP
> <snip>
> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : iova_mapped_as_huge_page+0x20/0x68 [panthor]
> lr : panthor_gpuva_sm_step_remap+0x39c/0x498 [panthor]
> sp : ffff800086193920
> x29: ffff800086193920 x28: ffff800086193a18 x27: ffff800086193b80
> x26: 0000000000400000 x25: 0000000000810000 x24: 0000000000400000
> x23: ffff000808af1800 x22: 0000000000a00000 x21: ffff800086193a00
> x20: ffff000806fd3f00 x19: 0000000000410000 x18: 00000000ffffffff
> x17: 0000000000000000 x16: 0000000000000000 x15: ffff800083ce2d83
> x14: 0000000000000000 x13: 3120646574636976 x12: 6520303030303138
> x11: 2d30303030313420 x10: ffff8000836e6c80 x9 : ffff80007bfc889c
> x8 : 3fffffffffffefff x7 : ffff8000836e6c80 x6 : 0000000000000000
> x5 : ffff00097ef19088 x4 : 0000000000000000 x3 : 0000000000000000
> x2 : 0000000000010000 x1 : 0000000000000400 x0 : 0000000000000000
> Call trace:
> iova_mapped_as_huge_page+0x20/0x68 [panthor] (P)
> op_remap_cb.isra.0+0x70/0xb0
> __drm_gpuvm_sm_unmap+0xf8/0x1c0
> drm_gpuvm_sm_unmap+0x40/0x60
> panthor_vm_exec_op+0xa0/0x168 [panthor]
> panthor_vm_bind_exec_sync_op+0x8c/0xb8 [panthor]
> panthor_ioctl_vm_bind+0xbc/0x170 [panthor]
> drm_ioctl_kernel+0xc0/0x140
> drm_ioctl+0x20c/0x500
> __arm64_sys_ioctl+0xb4/0x118
> invoke_syscall+0x5c/0x120
> el0_svc_common.constprop.0+0x48/0xf8
> do_el0_svc+0x28/0x40
> el0_svc+0x38/0x128
> el0t_64_sync_handler+0xa0/0xe8
> el0t_64_sync+0x198/0x1a0
> Code: 8b030021 cb020021 f940b800 d34cfc21 (f8617801)
> ---[ end trace 0000000000000000 ]---
>
> v2: Fix indentation
>
> Fixes: 8e7460eac786 ("drm/panthor: Support partial unmaps of huge pages")
> Signed-off-by: Akash Goel <akash.goel@arm.com>
> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_mmu.c | 26 +++++++++++++-------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> index 31cc57029c12..7c99cd422add 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> @@ -2358,20 +2358,20 @@ static int panthor_gpuva_sm_step_remap(struct drm_gpuva_op *op,
> */
> panthor_fix_sparse_map_offset(op->remap.next, unmap_vma->flags);
>
> - /*
> - * ARM IOMMU page table management code disallows partial unmaps of huge pages,
> - * so when a partial unmap is requested, we must first unmap the entire huge
> - * page and then remap the difference between the huge page minus the requested
> - * unmap region. Calculating the right start address and range for the expanded
> - * unmap operation is the responsibility of the following function.
> - */
> - unmap_hugepage_align(&op->remap, &unmap_start, &unmap_range);
> -
> - /* If the range changed, we might have to lock a wider region to guarantee
> - * atomicity. panthor_vm_lock_region() bails out early if the new region
> - * is already part of the locked region, so no need to do this check here.
> - */
> if (!unmap_vma->evicted) {
> + /*
> + * ARM IOMMU page table management code disallows partial unmaps of huge pages,
> + * so when a partial unmap is requested, we must first unmap the entire huge
> + * page and then remap the difference between the huge page minus the requested
> + * unmap region. Calculating the right start address and range for the expanded
> + * unmap operation is the responsibility of the following function.
> + */
> + unmap_hugepage_align(&op->remap, &unmap_start, &unmap_range);
> +
> + /* If the range changed, we might have to lock a wider region to guarantee
> + * atomicity. panthor_vm_lock_region() bails out early if the new region
> + * is already part of the locked region, so no need to do this check here.
> + */
> panthor_vm_lock_region(vm, unmap_start, unmap_range);
> panthor_vm_unmap_pages(vm, unmap_start, unmap_range);
> }
> --
> 2.25.1
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [GIT PULL] platform-drivers-x86 for v7.2-1
From: pr-tracker-bot @ 2026-06-23 15:40 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Linus Torvalds, LKML, PDx86, Hans de Goede, Andy Shevchenko
In-Reply-To: <pdx86-pr-20260622211510-2801419545@linux.intel.com>
The pull request you sent on Mon, 22 Jun 2026 21:15:10 +0300:
> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git tags/platform-drivers-x86-v7.2-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f31c00c377ccf07c85442712f7c940a855cb3371
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] platform-drivers-x86 for v7.2-1
From: pr-tracker-bot @ 2026-06-23 15:40 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Linus Torvalds, LKML, PDx86, Hans de Goede, Andy Shevchenko
In-Reply-To: <pdx86-pr-20260622211510-2801419545@linux.intel.com>
The pull request you sent on Mon, 22 Jun 2026 21:15:10 +0300:
> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git tags/platform-drivers-x86-v7.2-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f31c00c377ccf07c85442712f7c940a855cb3371
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] Mailbox changes for v7.2
From: pr-tracker-bot @ 2026-06-23 15:40 UTC (permalink / raw)
To: Jassi Brar; +Cc: Linus Torvalds, Linux Kernel Mailing List, linux-arm-kernel
In-Reply-To: <CABb+yY3Tns7SmNU+_iSKcnrg+Muy5eOTNHn49nj+uv73VHNgTw@mail.gmail.com>
The pull request you sent on Mon, 22 Jun 2026 13:37:57 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox.git tags/mailbox-v7.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/515db262143e48f09b5dce07bc0db67b8b4d6a73
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] TPM DEVICE DRIVER: for-next-tpm-7.2-rc1-fixed
From: pr-tracker-bot @ 2026-06-23 15:40 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Linus Torvalds, Peter Huewe, Jason Gunthorpe, David Howells,
keyrings, linux-integrity, linux-kernel
In-Reply-To: <ajlVR8okpQirKw5-@kernel.org>
The pull request you sent on Mon, 22 Jun 2026 18:31:19 +0300:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/for-next-tpm-7.2-rc1-fixed
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/16b2087efdddd0bf042accdbdcc8eedc21bf9227
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] kselftest second update for Linux 7.2-rc1
From: pr-tracker-bot @ 2026-06-23 15:40 UTC (permalink / raw)
To: Shuah Khan
Cc: Linus Torvalds, Shuah Khan, shuah, linux-kernel, linux-kselftest
In-Reply-To: <e8e631e2-cbf3-418f-b07c-c13259d6c010@linuxfoundation.org>
The pull request you sent on Mon, 22 Jun 2026 09:30:32 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux_kselftest-next-7.2-rc1-second
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3eb20a97b315a9fd5fea33c207c51823f22c2b4d
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH V2] thunderbolt: fix bandwidth group reservation indexing
From: Mika Westerberg @ 2026-06-23 15:40 UTC (permalink / raw)
To: raoxu; +Cc: andreas.noever, westeri, YehezkelShB, linux-usb, linux-kernel
In-Reply-To: <E53B82E8FA767BC5+20260623133759.3019094-1-raoxu@uniontech.com>
Hi,
On Tue, Jun 23, 2026 at 09:37:59PM +0800, raoxu wrote:
> From: Xu Rao <raoxu@uniontech.com>
>
> Group ID 0 is reserved, while valid bandwidth groups use IDs 1 through
> 7. MAX_GROUPS is used both for tb_cm::groups, which stores allocatable
> bandwidth groups, and for group_reserved[], which is indexed directly
> by Group ID.
>
> tb_init_bandwidth_groups() assigns i + 1 to each entry in
> tb_cm::groups. Keeping seven entries therefore creates exactly the valid
> Group IDs 1 through 7.
>
> However, group_reserved[MAX_GROUPS] currently also has seven entries,
> providing indices 0 through 6. When a tunnel belongs to Group ID 7,
> tb_consumed_dp_bandwidth() reads and may write one element past the end
> of the array. The reservation for that group is consequently not
> included in the consumed bandwidth total either.
>
> Define MAX_GROUPS as 7 + 1 so arrays indexed directly by Group ID cover
> the complete 0 through 7 range, including the reserved ID 0. Size
> tb_cm::groups as MAX_GROUPS - 1 so only seven bandwidth group objects
> are initialized and tb_init_bandwidth_groups() continues to assign IDs
> 1 through 7. tb_consumed_dp_bandwidth() can then retain the direct
> Group ID indexing, with Group ID 7 selecting the final valid array
> element instead of accessing beyond it.
>
> Fixes: 52a4490e89d7 ("thunderbolt: Reserve released DisplayPort bandwidth for a group for 10 seconds")
> Signed-off-by: Xu Rao <raoxu@uniontech.com>
> ---
> Changes in v2:
> - Drop the zero-based Group ID conversion used in v1 and keep
> group->index as the direct group_reserved[] index.
> - Include the reserved Group ID 0 in MAX_GROUPS so direct-indexed arrays
> cover the complete Group ID range 0 through 7.
> - Size tb_cm::groups as MAX_GROUPS - 1 so
> tb_init_bandwidth_groups() continues to create only the seven valid
> groups with IDs 1 through 7.
>
> drivers/thunderbolt/tb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
> index 76323255439a..51f909db9383 100644
> --- a/drivers/thunderbolt/tb.c
> +++ b/drivers/thunderbolt/tb.c
> @@ -41,7 +41,7 @@
> */
> #define TB_ASYM_THRESHOLD 45000
>
> -#define MAX_GROUPS 7 /* max Group_ID is 7 */
> +#define MAX_GROUPS (7 + 1) /* Group ID 0 is reserved */
>
> static unsigned int asym_threshold = TB_ASYM_THRESHOLD;
> module_param_named(asym_threshold, asym_threshold, uint, 0444);
> @@ -66,7 +66,7 @@ struct tb_cm {
> struct list_head dp_resources;
> bool hotplug_active;
> struct delayed_work remove_work;
> - struct tb_bandwidth_group groups[MAX_GROUPS];
> + struct tb_bandwidth_group groups[MAX_GROUPS - 1];
Why this? We still need to be able to put there GroupIDs 1 to 7 (and keep
the 0 as is).
> };
>
> static inline struct tb *tcm_to_tb(struct tb_cm *tcm)
> --
> 2.50.1
^ permalink raw reply
* Re: [PATCH 1/8] clk: qcom: dispcc-sm8450: Fix mdss clocks
From: Krzysztof Kozlowski @ 2026-06-23 15:39 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-1-37e2ee8df9da@proton.me>
On 23/06/2026 02:54, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> Both of these changes allow the framebuffer to show upon boot and let
> the mdss driver take over afterwards.
> Before, none of these actions were possible. Only mdss takeover was
> possible, but screen had to be turned off first.
>
> OLE configuration may have been a misinterpretation... that's not
> something that's done on the downstream driver.
>
> Changing disp_cc_mdss_mdp_clk_src from clk_rcg2_shared_ops to
> clk_rcg2_shared_no_init_park_ops fixes this warning as well:
These should be two separate commits, if I understand correctly.
Please use also Fixes tag.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] powerpc/serial: Fix include guard comment
From: Thorsten Blum @ 2026-06-23 15:38 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP)
Cc: Thorsten Blum, linuxppc-dev, linux-kernel
Replace _PPC64_SERIAL_H with _ASM_POWERPC_SERIAL_H to match the actual
macro name. Remove an empty comment while at it.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/powerpc/include/asm/serial.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/serial.h b/arch/powerpc/include/asm/serial.h
index cd6c18d0e66e..c3eb4a64b3f5 100644
--- a/arch/powerpc/include/asm/serial.h
+++ b/arch/powerpc/include/asm/serial.h
@@ -1,6 +1,4 @@
/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- */
#ifndef _ASM_POWERPC_SERIAL_H
#define _ASM_POWERPC_SERIAL_H
@@ -18,4 +16,4 @@ extern void find_legacy_serial_ports(void);
#define find_legacy_serial_ports() do { } while (0)
#endif
-#endif /* _PPC64_SERIAL_H */
+#endif /* _ASM_POWERPC_SERIAL_H */
^ permalink raw reply related
* [PATCH net-next v3] vsock/virtio: rewrite MSG_ZEROCOPY flag handling
From: Arseniy Krasnov @ 2026-06-23 15:38 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Michael S. Tsirkin,
Jason Wang, Bobby Eshleman, Xuan Zhuo, Eugenio Pérez,
Simon Horman
Cc: kvm, virtualization, netdev, linux-kernel, oxffffaa, rulkc,
Arseniy Krasnov
Logically it was based on TCP implementation, so to make further support
easier, rewrite it in the TCP way (like in 'tcp_sendmsg_locked()'). This
patch only rewrites flag handling (e.g. it doesn't change logic).
Signed-off-by: Arseniy Krasnov <avkrasnov@rulkc.org>
---
Changelog v1->v2:
* Rebase on last 'net-next'. Don't need 'skb_zcopy_set()' now - it was
already added.
Changelog v2->v3:
* Update commit message.
* Remove one empty line.
net/vmw_vsock/virtio_transport_common.c | 47 ++++++++++++-------------
1 file changed, 22 insertions(+), 25 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 09475007165b..41c2a0b82a8e 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -328,38 +328,35 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
if (pkt_len == 0 && info->op == VIRTIO_VSOCK_OP_RW)
return pkt_len;
- if (info->msg) {
- /* If zerocopy is not enabled by 'setsockopt()', we behave as
- * there is no MSG_ZEROCOPY flag set.
+ if (info->msg && (info->msg->msg_flags & MSG_ZEROCOPY)) {
+ /* If 'info->msg' is not NULL, this is only VIRTIO_VSOCK_OP_RW.
+ * 'MSG_ZEROCOPY' flag handling here is based on the same flag
+ * handling from 'tcp_sendmsg_locked()'.
*/
- if (!sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY))
- info->msg->msg_flags &= ~MSG_ZEROCOPY;
+ if (info->msg->msg_ubuf) {
+ uarg = info->msg->msg_ubuf;
+ can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
+ } else if (sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY)) {
+ uarg = msg_zerocopy_realloc(sk_vsock(vsk), pkt_len,
+ NULL, false);
+ if (!uarg) {
+ virtio_transport_put_credit(vvs, pkt_len);
+ return -ENOMEM;
+ }
- if (info->msg->msg_flags & MSG_ZEROCOPY)
can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
+ if (!can_zcopy)
+ uarg_to_msgzc(uarg)->zerocopy = 0;
+ have_uref = true;
+ }
+
+ /* 'can_zcopy' means that this transmission will be
+ * in zerocopy way (e.g. using 'frags' array).
+ */
if (can_zcopy)
max_skb_len = min_t(u32, VIRTIO_VSOCK_MAX_PKT_BUF_SIZE,
(MAX_SKB_FRAGS * PAGE_SIZE));
-
- if (info->msg->msg_flags & MSG_ZEROCOPY &&
- info->op == VIRTIO_VSOCK_OP_RW) {
- uarg = info->msg->msg_ubuf;
-
- if (!uarg) {
- uarg = msg_zerocopy_realloc(sk_vsock(vsk),
- pkt_len, NULL, false);
- if (!uarg) {
- virtio_transport_put_credit(vvs, pkt_len);
- return -ENOMEM;
- }
-
- if (!can_zcopy)
- uarg_to_msgzc(uarg)->zerocopy = 0;
-
- have_uref = true;
- }
- }
}
rest_len = pkt_len;
--
2.25.1
^ 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