From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B076C43331 for ; Sun, 10 Nov 2019 03:11:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1D93920679 for ; Sun, 10 Nov 2019 03:11:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573355506; bh=Y+QVWnNnofIfKEsSwHOQQRLh8sUpAcQANW9LqVyxVs4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=j3z1J1x5QMiZZJeRhfaxlctG6oWo6G/h1+B5hNGPIcRSfqfwwo1u6AqPojwoCisPK 1PQzNy0LCiNP9b7Y06yW2Wt+3UCn1gB4mm/s0aPhi2JgNn9JBx+3jw2dOOqncwFLNF iJDN/TtTb9zLdsUBNs8Jcd4xLUaL9NZIC2jA4H2g= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728375AbfKJDLl (ORCPT ); Sat, 9 Nov 2019 22:11:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:41966 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728366AbfKJCng (ORCPT ); Sat, 9 Nov 2019 21:43:36 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F3FC521882; Sun, 10 Nov 2019 02:43:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573353815; bh=Y+QVWnNnofIfKEsSwHOQQRLh8sUpAcQANW9LqVyxVs4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=t4dQq8XQ0KFTflGP7KI6XwFp873Oywzj9Dw5/eMk25C3mztQuyLcriFXo0UTUZqGR MrEglrv+0/fOEXGbDlGU4RgA5WrhwWdndmGEfiypqf6huoHvVTIVfUrhiQ6RebCHju 9Eo3YDYQ+CFYgg/Ep1mpiq2AXSJbUK3SOYPLP8fc= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Suzuki K Poulose , Mathieu Poirier , Greg Kroah-Hartman , Sasha Levin Subject: [PATCH AUTOSEL 4.19 111/191] coresight: Fix handling of sinks Date: Sat, 9 Nov 2019 21:38:53 -0500 Message-Id: <20191110024013.29782-111-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20191110024013.29782-1-sashal@kernel.org> References: <20191110024013.29782-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Suzuki K Poulose [ Upstream commit c71369de02b285d9da526a526d8f2affc7b17c59 ] The coresight components could be operated either in sysfs mode or in perf mode. For some of the components, the mode of operation doesn't matter as they simply relay the data to the next component in the trace path. But for sinks, they need to be able to provide the trace data back to the user. Thus we need to make sure that "mode" is handled appropriately. e.g, the sysfs mode could have multiple sources driving the trace data, while perf mode doesn't allow sharing the sink. The coresight_enable_sink() however doesn't really allow this check to trigger as it skips the "enable_sink" callback if the component is already enabled, irrespective of the mode. This could cause mixing of data from different modes or even same mode (in perf), if the sources are different. Also, if we fail to enable the sink while enabling a path (where sink is the first component enabled), we could end up in disabling the components in the "entire" path which were not enabled in this trial, causing disruptions in the existing trace paths. Cc: Mathieu Poirier Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/hwtracing/coresight/coresight.c | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c index 3e07fd335f8cf..c0dabbddc1e49 100644 --- a/drivers/hwtracing/coresight/coresight.c +++ b/drivers/hwtracing/coresight/coresight.c @@ -132,12 +132,14 @@ static int coresight_enable_sink(struct coresight_device *csdev, u32 mode) { int ret; - if (!csdev->enable) { - if (sink_ops(csdev)->enable) { - ret = sink_ops(csdev)->enable(csdev, mode); - if (ret) - return ret; - } + /* + * We need to make sure the "new" session is compatible with the + * existing "mode" of operation. + */ + if (sink_ops(csdev)->enable) { + ret = sink_ops(csdev)->enable(csdev, mode); + if (ret) + return ret; csdev->enable = true; } @@ -339,8 +341,14 @@ int coresight_enable_path(struct list_head *path, u32 mode) switch (type) { case CORESIGHT_DEV_TYPE_SINK: ret = coresight_enable_sink(csdev, mode); + /* + * Sink is the first component turned on. If we + * failed to enable the sink, there are no components + * that need disabling. Disabling the path here + * would mean we could disrupt an existing session. + */ if (ret) - goto err; + goto out; break; case CORESIGHT_DEV_TYPE_SOURCE: /* sources are enabled from either sysFS or Perf */ -- 2.20.1