From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C72D037B007 for ; Fri, 22 May 2026 19:55:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779479731; cv=none; b=DsacUb8W7X6YuxIZEx792zawWyMg4b118Bh213UBxd6CBI2AWPGVGiyOpPLLlUZ6a4qddBEmu8c/o0QT7XKXn+5hDIgXz6JkD/MbHOthYRn1F636IRCphsXjae9LikLztCi4UieMqvy8SuNe+K2OiUjEc9k4Nlp/aCQJOFpPbow= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779479731; c=relaxed/simple; bh=3Fs/ml5UcL3DeI8Udn3BJweQNyfu+QmtJOL6ZN0uPQk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XDqb6ZOXq+hSxHMWNqMzvFgt9RaYWC5zHeIPtyRbktyclR+MKQGfM+xkhfpZ1/IpmpWVG8wIyvZsgv0vfZ+V6KnQ8jY1j8RPwEbrm8U1Q6c/4gWi+51RD32Ht2M/ThZNEH45rc4SQjHMgresgdiYrcOeQnY3xB7p0qdAimgwEAM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=q1zsXI/d; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="q1zsXI/d" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-48e8132c6d0so49442375e9.1 for ; Fri, 22 May 2026 12:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779479727; x=1780084527; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=1vC76+wE+m69DnNHzueD5T2LV/NT7LEvFIu8/P6enzg=; b=q1zsXI/dHdFijni7US63jVxsw4/MHYPVgzMF5IR3iOUB5nef5hQqBRYUNxCi8983S3 3YzYotrgTZulO7w+s4dDqJpCggldRMBeWGhegrgIibkbjbSZsgSixCqhDu44Hmh8MBna PuYDjgU9SETD+tfUqxrShh40lIf2GkL/6ZNx8Tgs4km+4+oVHwZFWsXOW2aUnnQsq0cv 3OkQtPRjT3hTdvlb17uDv3Me9mDy6C3aW4QhrpReRqk6eBnyh+WKzVIo/tyr/LOQsZkh nXrMb+3MK0uyWO5DDtBPXgZRKvm1DeYSi/gUO8SV4OqPWIa9Vy971kKUaU2XoCnd0j7n fQyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779479727; x=1780084527; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1vC76+wE+m69DnNHzueD5T2LV/NT7LEvFIu8/P6enzg=; b=AMsXkIZPyPBtKVVHzh2F3bxz0e6jsV4qnbVmc02QGBH6303xYq6i64UR0VVxc6c1D7 0kNmP3GfZfHIKSOwW3ceJpNV2b2yG53DNw2X0IOxMRBDe4q2Kw9Kn5Il65kh4mpvwpWn Wh0IwOiM94RSzVgaanMp7oNRr9y0hYoUEdLyLwkQeG+lkxtQmUZwA7Pe09p8DHHlIYz9 V0qUZ/1+PnFB0eE20UHUDQVEAeVYQCq0dY5sHTa5+xB+PJNBrv8sqw5btTDIcrJtg90I rJJgP4Af3YfSesBWz+JWYJs8Bh5leTdt95exqz5icg2k3gu5kKwJIy5hrqtY2khsOFHT 2+gw== X-Forwarded-Encrypted: i=1; AFNElJ968NTB+mxdLMjYDUWsfzxF0ygNYB8X5Ka/Q6YVBU6nh54Dl1Aa//b9n5rveKsjnZKhpPRVrKfb25IQ2MU=@vger.kernel.org X-Gm-Message-State: AOJu0YwvRWJ55Z76pru14IgWAfcWRs5tt7+YHDXANx7zP8yEBrOBmvBR gpejxkzFZJvt0SHTj+7VV8yrnppRe0g4fk6MlKZWLyQrauzZmR/Arjcq X-Gm-Gg: Acq92OGEVdPZIrhM2SsQpByBoEbfTJxopJDzODtvGx1hEyNpyYmcdgfj7uwobpfpjv6 QM5K+t4SCj+cw24PbUn8h1fk2bk3E4+jGYRIzzXnt+ngmU6u6A4ciu9nrryyfgBJkizrwGswWe3 Rz+euLatFa2W7eZ1D9jmIOIs97FYd9pPQ7XA84w0RPffhK2u9ESTX0A6Q+CSQg1h+cTeOvmHBGU L1MhbQouGfjlSCVN9+1QPxL6wR4nw9AG+Q9XPw18HGxr2tNmQXy18EXTI7QNyZrlSSd/glOL9w1 8jITvFJmIVXX0sh6rcoPB5wkkD0ICEQZP14yvcyeYm5S/egiQW13w2FDmvGvlb3WbZiY17IZclG N0vojbE4pKHw4MOOaToOucXvAcWa50hTHYL87tA0oOhpamirbfNOperw1Ig8NpKVtu07bfuwiif FJs4GhCUzRBEt2cl1FLRhjzBTxnPU= X-Received: by 2002:a05:600c:8b41:b0:490:4a1b:d8d4 with SMTP id 5b1f17b1804b1-4904a1bd912mr27811225e9.27.1779479726825; Fri, 22 May 2026 12:55:26 -0700 (PDT) Received: from curiosity ([80.211.22.60]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490428d44f6sm32907425e9.8.2026.05.22.12.55.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 12:55:26 -0700 (PDT) Date: Fri, 22 May 2026 22:55:19 +0300 From: Sergey Matyukevich To: Anup Patel Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Palmer Dabbelt , Paul Walmsley , Greg KH , Alexander Shishkin , Ian Rogers , Alexandre Ghiti , Peter Zijlstra , Ingo Molnar , Namhyung Kim , Mark Rutland , Jiri Olsa , Adrian Hunter , Mayuresh Chitale , Anup Patel , Atish Patra , Andrew Jones , Sunil V L , linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Mayuresh Chitale Subject: Re: [PATCH v4 03/12] rvtrace: Add functions to create/destroy a trace component path Message-ID: References: <20260429125135.1983498-1-anup.patel@oss.qualcomm.com> <20260429125135.1983498-4-anup.patel@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260429125135.1983498-4-anup.patel@oss.qualcomm.com> > Trace needs to be configured on a chain of trace components which are > connected to each other. These chain of components is also referred > to as trace component path. Add functions to create/destroy a trace > component path which will be later used by RISC-V trace perf support. > > Co-developed-by: Mayuresh Chitale > Signed-off-by: Mayuresh Chitale > Signed-off-by: Anup Patel > --- > drivers/hwtracing/rvtrace/rvtrace-core.c | 223 +++++++++++++++++++++++ > include/linux/rvtrace.h | 43 ++++- > 2 files changed, 264 insertions(+), 2 deletions(-) ... I have been playing with a bit more complicated rvtrace graph with one source (encoder) and two sinks (ramsink and simple test atb bridge sink) with the following encoder output ports: : trace@c000000 { : compatible = "qemu,trace-component", "riscv,trace-component"; : reg = <0xc000000 0x1000>; : cpus = <&CPU0>; : : out-ports { : port@0 { : reg = <0>; : CPU0_ENCODER_RAMSINK_OUTPUT: endpoint { : remote-endpoint = <&CPU0_RAMSINK_INPUT>; : }; : }; : port@1 { : reg = <1>; : CPU0_ENCODER_TEST_OUTPUT: endpoint { : remote-endpoint = <&CPU0_TEST_INPUT>; : }; : }; : }; : }; In this case the first output port is enabled, but the second one is not. > +static int build_path_walk_fn(struct rvtrace_component *comp, bool *stop, > + struct rvtrace_connection *stop_conn, > + void *priv) > +{ > + struct build_path_walk_priv *ppriv = priv; > + struct rvtrace_path *path = ppriv->path; > + struct rvtrace_path_node *node; > + > + if ((!ppriv->sink && rvtrace_is_sink(comp->pdata)) || > + (ppriv->sink && ppriv->sink == comp)) > + *stop = true; > + IIUC the root cause is that rvtrace_create_path from rvtrace-perf.c, where the second argument is NULL, selects the first reachable sink. The function __rvtrace_walk_output_components() walks pdata->outconns[] in order and stops at the first component where rvtrace_is_sink() is true. In the example with two sinks we stop at ramsink. As a result, the second sink is not added to the list and never enabled later on. > + if (*stop) { > + node = kzalloc_obj(*node); > + if (!path) > + return -ENOMEM; > + INIT_LIST_HEAD(&node->head); > + rvtrace_get_component(comp); > + node->comp = comp; > + node->conn = stop_conn; > + list_add(&node->head, &path->comp_list); > + } > + > + return 0; > +} Regards, Sergey