From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D8F483D75C2 for ; Wed, 8 Apr 2026 17:39:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775669983; cv=none; b=VmmFzANFfB6BhS6wt+Ncy3CGXEGr4kkf7sTLN7lwpTz2BUszDTnJNexa+XqaoDMfpjQLP62417RaIuWpygReyl2X34UyNgh7DsZD6X3w+CrNx7PR4Q2Qb9vGmEZXtaSXNExhY5oowHFeskKwC5Ph3hFJWh6M9UyFp+CDzU6zy9c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775669983; c=relaxed/simple; bh=ALfN8sj+HH6bXZAeyqff24KoV6WqUskFI0gXhzKFigc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=usqKzo/NhM58fHE4Qsm8hW7FhliWKhOqLqodRq28vDEWffamwCLENsoIAzljN+c+RmhSLdNs/t1HN7U4iiKRx0FXH3fl7Vr3ZIyG7x+mBwPwsR4cITUD2mpmSR3qfUkjtl5Nv2Sq1KyJwT/2p8bFXeoB0IokjEI3wOih9DL+LSo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=LTe5SdYm; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="LTe5SdYm" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8A25C168F; Wed, 8 Apr 2026 10:39:35 -0700 (PDT) Received: from e129823.arm.com (e129823.arm.com [10.1.197.6]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F37303F641; Wed, 8 Apr 2026 10:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1775669981; bh=ALfN8sj+HH6bXZAeyqff24KoV6WqUskFI0gXhzKFigc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LTe5SdYmUB1zPKdPhmyrC8g7KTHZy6+6UGwMYrAXXxkv+J/8KKSQbf0Ld7LuF0C8A iuk+bz5jcLIY1baa2KLMjQLTOzsMYwwago16aCkvPSEMjLZofARg3DwrZmzAyVkoxc hZqzUBYGMAOBIbaNYctcEm8BPVwyCbwaInku7Rkk= Date: Wed, 8 Apr 2026 18:39:37 +0100 From: Yeoreum Yun To: Suzuki K Poulose Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mike.leach@linaro.org, james.clark@linaro.org, alexander.shishkin@linux.intel.com, leo.yan@arm.com Subject: Re: [PATCH 1/2] coresight: etm4x: fix inconsistencies with sysfs configration Message-ID: References: <20260317181705.2456271-1-yeoreum.yun@arm.com> <20260317181705.2456271-2-yeoreum.yun@arm.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: Hi Suzuki, [...] > > - config, which stores the settings configured via sysfs. > > While we are at it, should we stop using the drvdata->config for the > "capabilities" for the ETM (e.g., TRCSSCSRn in ss_status ?) Instead > we could save it in "drvdata->ss_status". This keeps everything > separated: Hmm, if we think the drvdata->ss_status as "capabilities", I think we doesn't need to save/restore ss_status in etm4_disable_hw()/etm4_enable_hw() since cpu idle doesn't use both and other bits (STATUS and PENDING) should be cleared when new session is started regardless of perf or sysfs mode. Am I missing something? -- Sincerely, Yeoreum Yun