On 03/18, Andrii Nakryiko wrote:
>
> Andrii Nakryiko (3):
> uprobes: encapsulate preparation of uprobe args buffer
> uprobes: prepare uprobe args buffer lazily
> uprobes: add speculative lockless system-wide uprobe filter check
>
> kernel/trace/trace_uprobe.c | 103
On 19/03/2024 01:37, Tanmay Shah wrote:
> Hello,
>
> Thanks for reviews, please find my comments below.
>
> On 3/17/24 9:50 AM, Conor Dooley wrote:
>> On Fri, Mar 15, 2024 at 02:15:31PM -0700, Tanmay Shah wrote:
>>> AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
>>>
On 19/03/2024 01:51, Tanmay Shah wrote:
> Hello Krzysztof,
>
> Thanks for reviews. Please find my comments below.
>
> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>>> contains
On 11/03/2024 18:59, Tanmay Shah wrote:
> From: Radhey Shyam Pandey
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled
On 12/03/2024 13:13, Krzysztof Kozlowski wrote:
> On 11/03/2024 18:59, Tanmay Shah wrote:
>> From: Radhey Shyam Pandey
>>
>> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
>> UltraScale+ platform. It will help in defining TCM in device-tree
>> and make it's access platform
On 19/03/2024 02:06, Tanmay Shah wrote:
>
>
> On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
>>> remoteproc driver is mostly compatible with new platforms except few
>>>
On 3/19/24 02:59, Will Deacon wrote:
On Thu, Mar 14, 2024 at 05:49:23PM +1000, Gavin Shan wrote:
The issue is reported by Yihuang Yu who have 'netperf' test on
NVidia's grace-grace and grace-hopper machines. The 'netperf'
client is started in the VM hosted by grace-hopper machine,
while the
On Tue, 19 Mar 2024 13:20:57 +0900
Masami Hiramatsu (Google) wrote:
> Hi,
>
> On Mon, 18 Mar 2024 11:17:25 -0700
> Andrii Nakryiko wrote:
>
> > This patch set implements two speed ups for uprobe/uretprobe runtime
> > execution
> > path for some common scenarios: BPF-only uprobes (patches #1
Hi,
On Mon, 18 Mar 2024 11:17:25 -0700
Andrii Nakryiko wrote:
> This patch set implements two speed ups for uprobe/uretprobe runtime execution
> path for some common scenarios: BPF-only uprobes (patches #1 and #2) and
> system-wide (non-PID-specific) uprobes (patch #3). Please see individual
>
On Wed, 06 Mar 2024 00:18:03 +0100, Luca Weiss wrote:
> The sony-castor dts has been around for a while, clean up some things to
> prepare for further changes including the introduction of the
> shinano-based Sony Xperia Z3.
>
>
Applied, thanks!
[1/5] ARM: dts: qcom: msm8974pro-castor: Clean
On Thu, 08 Feb 2024 10:52:31 +0100, Luca Weiss wrote:
> This series adds all the necessary bits to enable USB-C role switching,
> charger and fuel gauge (all via pmic-glink) on Fairphone 5.
>
>
Applied, thanks!
[1/2] dt-bindings: soc: qcom: qcom,pmic-glink: document QCM6490 compatible
On Tue, 20 Feb 2024 13:01:22 +0100, Luca Weiss wrote:
> Add the definition for the USB-C connector found on this phone and hook
> up the relevant bits. This enables USB role switching.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sdm632-fairphone-fp3: enable USB-C port handling
commit:
On Mon, 19 Feb 2024 15:33:27 +0100, Luca Weiss wrote:
> The code in qcom_q6v5_init() requests the "wdog" IRQ as
> IRQF_TRIGGER_RISING. If dt defines the interrupt type as LEVEL_HIGH then
> the driver will have issues getting the IRQ again after probe deferral
> with an error like:
>
> irq:
On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
>> remoteproc driver is mostly compatible with new platforms except few
>> platform specific differences.
>>
>> Versal has same
Hello Krzysztof,
Thanks for reviews. Please find my comments below.
On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>> contains multiple clusters of cortex-R52 real-time processing
On 3/17/24 1:50 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
>> Processor Unit R5 cluster IP on Versal is same as of ZynqMP Platform.
>> Only difference is power-domains ID needed by power
Hello,
Thanks for reviews, please find my comments below.
On 3/17/24 9:50 AM, Conor Dooley wrote:
> On Fri, Mar 15, 2024 at 02:15:31PM -0700, Tanmay Shah wrote:
>> AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
>> Processor Unit R5 cluster IP on Versal is same as of ZynqMP
I'm working on V3. Thanks for Ying's feedback.
cc: sthanne...@micron.com
On Thu, Mar 14, 2024 at 12:54 AM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > On Tue, Mar 12, 2024 at 2:21 AM Huang, Ying wrote:
> >>
> >> "Ho-Ren (Jack) Chuang" writes:
> >>
> >> > The current
On Mon, 18 Mar 2024 22:27:45 +0900 Honggyu Kim wrote:
> Hi SeongJae,
>
> On Sun, 17 Mar 2024 08:31:44 -0700 SeongJae Park wrote:
> > Hi Honggyu,
> >
> > On Sun, 17 Mar 2024 17:36:29 +0900 Honggyu Kim wrote:
> >
> > > Hi SeongJae,
> > >
> > > Thanks for the confirmation. I have a few
It's very common with BPF-based uprobe/uretprobe use cases to have
a system-wide (not PID specific) probes used. In this case uprobe's
trace_uprobe_filter->nr_systemwide counter is bumped at registration
time, and actual filtering is short circuited at the time when
uprobe/uretprobe is triggered.
uprobe_cpu_buffer and corresponding logic to store uprobe args into it
are used for uprobes/uretprobes that are created through tracefs or
perf events.
BPF is yet another user of uprobe/uretprobe infrastructure, but doesn't
need uprobe_cpu_buffer and associated data. For BPF-only use cases this
Move the logic of fetching temporary per-CPU uprobe buffer and storing
uprobes args into it to a new helper function. Store data size as part
of this buffer, simplifying interfaces a bit, as now we only pass single
uprobe_cpu_buffer reference around, instead of pointer + dsize.
This logic was
This patch set implements two speed ups for uprobe/uretprobe runtime execution
path for some common scenarios: BPF-only uprobes (patches #1 and #2) and
system-wide (non-PID-specific) uprobes (patch #3). Please see individual
patches for details.
v1->v2:
- rebased onto trace/core branch of
Steven,
Tracing tooling updates for 6.9
Tracing:
- Update makefiles for latency-collector and RTLA,
using tools/build/ makefiles like perf does, inheriting
its benefits. For example, having a proper way to
handle dependencies.
- The timerlat tracer
On Thu, Mar 14, 2024 at 05:49:23PM +1000, Gavin Shan wrote:
> The issue is reported by Yihuang Yu who have 'netperf' test on
> NVidia's grace-grace and grace-hopper machines. The 'netperf'
> client is started in the VM hosted by grace-hopper machine,
> while the 'netperf' server is running on
On Mon, 18 Mar 2024 16:43:07 +0100
Luca Ceresoli wrote:
> Indeed I was on an older version, apologies.
>
> I upgraded both libtraceevent and trace-cmd to master and applied your
> patch, now the %c is formatted correctly.
>
> However the arrows are still reversed.
>
> Is this what you were
Hello Steven,
On Fri, 15 Mar 2024 14:58:52 -0400
Steven Rostedt wrote:
> On Fri, 15 Mar 2024 19:03:12 +0100
> Luca Ceresoli wrote:
>
> > > >
> > > > I've come across an unexpected behaviour in the kernel tracing
> > > > infrastructure that looks like a bug, or maybe two.
> > > >
> > > >
Hi Naresh,
On Mon, Mar 18, 2024 at 02:55:54PM +0530, Naresh Kamboju wrote:
> The following build warnings / errors noticed on x86 kselftests build with
> clang nightly / clang-17 on Linux next tag next-20240318.
>
> This build config is generated from kselftest merge configs [1].
&
Hi SeongJae,
On Sun, 17 Mar 2024 12:13:57 -0700 SeongJae Park wrote:
> On Sun, 17 Mar 2024 08:31:44 -0700 SeongJae Park wrote:
>
> > Hi Honggyu,
> >
> > On Sun, 17 Mar 2024 17:36:29 +0900 Honggyu Kim wrote:
> >
> > > Hi SeongJae,
> > >
> > > Thanks for the confirmation. I have a few
Hi SeongJae,
On Sun, 17 Mar 2024 08:31:44 -0700 SeongJae Park wrote:
> Hi Honggyu,
>
> On Sun, 17 Mar 2024 17:36:29 +0900 Honggyu Kim wrote:
>
> > Hi SeongJae,
> >
> > Thanks for the confirmation. I have a few comments on young filter so
> > please read the inline comments again.
> >
> >
With virtio-mem, primarily hibernation is problematic: as the machine shuts
down, the virtio-mem device loses its state. Powering the machine back up
is like losing a bunch of DIMMs. While there would be ways to add limited
support, suspend+resume is more commonly used for VMs and "easier" to
On Fri, Mar 15, 2024 at 05:04:22PM +0100, Luca Weiss wrote:
> Switch to using the new DRM_AUX_BRIDGE helper to create the transparent
> DRM bridge device instead of handcoding corresponding functionality.
>
> Signed-off-by: Luca Weiss
Reviewed-by: Heikki Krogerus
> ---
> Very similar to this
Explicitly cast the divisor to u32 to fix a Coccinelle/coccicheck warning
reported by do_div.cocci.
Signed-off-by: Thorsten Blum
---
kernel/trace/trace_benchmark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_benchmark.c b/kernel/trace/trace_benchmark.c
On 18.03.2024 10:24, Luca Weiss wrote:
> Add an empty /chosen node to the dtsi like is common on most other
> Qualcomm SoC files, so that various pieces of software expecting this
> node to exist don't complain.
>
> Signed-off-by: Luca Weiss
> ---
Kinda weird dtc doesn't add it automatically or
On 18.03.2024 10:24, Luca Weiss wrote:
> Add the @0 from reg to the node name, so that both dtc warning and dt
> validation failure get resolved.
>
> arch/arm/boot/dts/qcom/qcom-msm8974.dtsi:106.9-109.4: Warning
> (unit_address_vs_reg): /memory: node has a reg or ranges property, but no
>
Add the @0 from reg to the node name, so that both dtc warning and dt
validation failure get resolved.
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi:106.9-109.4: Warning
(unit_address_vs_reg): /memory: node has a reg or ranges property, but no unit
name
Add an empty /chosen node to the dtsi like is common on most other
Qualcomm SoC files, so that various pieces of software expecting this
node to exist don't complain.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git
insertions(+), 1 deletion(-)
---
base-commit: f6cef5f8c37f58a3bc95b3754c3ae98e086631ca
change-id: 20240318-msm8974-misc2-1fb92ae6bdf3
Best regards,
--
Luca Weiss
From: David Stevens
Treat stats requests as wakeup events to ensure that the driver responds
to device requests in a timely manner.
Signed-off-by: David Stevens
---
drivers/virtio/virtio_balloon.c | 75 -
1 file changed, 46 insertions(+), 29 deletions(-)
diff
From: David Stevens
Wakeup sources don't support nesting multiple events, so sharing a
single object between multiple drivers can result in one driver
overriding the wakeup event processing period specified by another
driver. Have the virtio balloon driver use the wakeup source of the
device it
From: David Stevens
The virtio_balloon driver uses wakeup sources to allow the guest to
enter system power management sleep states (e.g. s2idle) without running
the risk of becoming unresponsive to cooperative memory management
requests from the host. This series fixes an issue where wakeup
On Mon, Mar 18, 2024 at 09:41:45AM +1000, Gavin Shan wrote:
> On 3/18/24 02:50, Michael S. Tsirkin wrote:
> > On Fri, Mar 15, 2024 at 09:24:36PM +1000, Gavin Shan wrote:
> > >
> > > On 3/15/24 21:05, Michael S. Tsirkin wrote:
> > > > On Fri, Mar 15, 2024 at 08:45:10PM +1000, Gavin Shan wrote:
> >
> I think you snipped the fault injection that came before this. It looks
> like an allocation failure, so we don't get tsk->io_uring setup for the
> SQPOLL thread. Not a great way to handle this, but can you try the
> below? Would be nicer if we could just prune the task rather than wake
> it and
43 matches
Mail list logo
