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 0459C126C03
	for <linux-kernel@vger.kernel.org>; Mon,  9 Feb 2026 11:59:30 +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=1770638371; cv=none; b=drNXpO6ZZ5NHdrXU+DgfBfd6LCKOz4nHG1wQUwX2BvA2ekXsQBnR7JD9XajEQf+Q1D6NceD4p928gfz2ty34BzJmTpkz1TPr36jVmwmEvpvX6U0i9qaudMsyUcbJoUL73LLr5AA+Rx9c7TGPoDEOq6euagCZJUqGKMNkDATEwkI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770638371; c=relaxed/simple;
	bh=1B+M2CnYOVjKUUu2fIp+CwKLCDpzTm+gcVeS4Wuf8V0=;
	h=Date:From:To:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=r3v2558ufghP/+7B6+FC5+5zwOPZeTNGArjyrC6T2JkyuRMp5WrCL2L3eUUl/giYTnxofbRFwCBiLrPQo+8uvyJtEYMAEIrkeWQQjcHdU8xm99/MfCG7ZBBT2b6vHZ0QDVVzZBg4p6zYWrItZONalxEcC/PQ7AMJydQ3kVTyxEA=
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; 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
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 0E344339;
	Mon,  9 Feb 2026 03:59:24 -0800 (PST)
Received: from localhost (e132581.arm.com [10.1.196.87])
	by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB9D73F63F;
	Mon,  9 Feb 2026 03:59:29 -0800 (PST)
Date: Mon, 9 Feb 2026 11:59:27 +0000
From: Leo Yan <leo.yan@arm.com>
To: James Clark <james.clark@linaro.org>, coresight@lists.linaro.org,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	Mike Leach <mike.leach@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Mao Jinlong <quic_jinlmao@quicinc.com>
Subject: Re: [PATCH v3 8/8] coresight: Unify error handling in
 coresight_register()
Message-ID: <20260209115927.GM3529712@e132581.arm.com>
References: <20260202-arm_coresight_refactor_dev_register-v3-0-03292470c48c@arm.com>
 <20260202-arm_coresight_refactor_dev_register-v3-8-03292470c48c@arm.com>
 <e451547b-15a7-4296-a5da-379640c141c7@linaro.org>
 <20260209112819.GL3529712@e132581.arm.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260209112819.GL3529712@e132581.arm.com>

On Mon, Feb 09, 2026 at 11:28:19AM +0000, Coresight ML wrote:

[...]

> > Probably a better way to clean this up would be to pull out a function for
> > all the stuff that needs to be locked and use guard(). Then do the stuff
> > that doesn't need to be locked after that function. Either way it doesn't
> > look wrong.
> 
> If so, although locking is not a concern, the device_register() failures
> still need to release platform data particularly.  That means we still
> need extra flag (or returned error) to indicate if it is a
> device_register() failure.
> 
> I understand we don't want multiple places for mutex release.  It is
> not bad to keep the "registered" flag and drop this patch.

Think again, I found we still need the refactor for the failure
from etm_perf_add_symlink_sink().  This can be unified to call
coresight_unregister() for error handling.

I will send a new series for review.

Thanks,
Leo