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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6156CC54798 for ; Mon, 26 Feb 2024 02:50:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5o6gyt+g1yhE7zbW8Nt1BAYkBFdtRgFdJaGBTL4qLLQ=; b=xtXox7sAtsQqNt RkFbFcHsxfny6620KI6zB6ZXV0fF4tdq0Uwtd8Ca1EQmrKhTeKFRCDIV8ut2QRcu8UL2XoHMXq2N5 V/rRY7jBkhAr+PMiWQNHmN0UKm5tN30lN4TtOJvnWEEKuv0ae9IFpzQUK7XDzO+6WyifzN+kF5HWj aQsVfatVDXe2GjLr3ROJ22gxksoh2mmreQ+4OBkg0cudGak/VOFw8zzDPQvfriX7RoP5icr8RIgB6 uJwqrwUHHfEPF4KmOR4kuxOF97qg96KYwarCiaLrZTCs8kDbSkcefmiZ15UInSCBwJ4mEIaVFhnNK eCiYt0q9Bhj6OkqFV4xg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1reR45-0000000GD1A-2sdi; Mon, 26 Feb 2024 02:50:01 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1reR3w-0000000GCxL-3Jbb for linux-arm-kernel@lists.infradead.org; Mon, 26 Feb 2024 02:49:54 +0000 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 638D61042; Sun, 25 Feb 2024 18:50:23 -0800 (PST) Received: from [10.162.40.19] (a077893.blr.arm.com [10.162.40.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 945723F6C4; Sun, 25 Feb 2024 18:49:42 -0800 (PST) Message-ID: <1901fadb-1d71-4374-be8c-00935bb27854@arm.com> Date: Mon, 26 Feb 2024 08:19:39 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros Content-Language: en-US To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, broonie@kernel.org, Mark Rutland , Catalin Marinas , linux-kernel@vger.kernel.org References: <20240223113102.4027779-1-anshuman.khandual@arm.com> <20240223125224.GC10641@willie-the-truck> From: Anshuman Khandual In-Reply-To: <20240223125224.GC10641@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240225_184952_913575_1E4EB85B X-CRM114-Status: GOOD ( 14.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/23/24 18:22, Will Deacon wrote: > On Fri, Feb 23, 2024 at 05:01:02PM +0530, Anshuman Khandual wrote: >> Both platform i.e ARM_BREAKPOINT_LEN_X and generic i.e HW_BREAKPOINT_LEN_X >> macros are used interchangeably to convert event->attr.bp_len and platform >> breakpoint control arch_hw_breakpoint_ctrl->len. Let's be consistent while >> deriving one from the other. This does not cause any functional changes. >> >> Cc: Will Deacon >> Cc: Mark Rutland >> Cc: Catalin Marinas >> Cc: linux-arm-kernel@lists.infradead.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual >> --- >> This applies on v6.8-rc5 >> >> arch/arm64/kernel/hw_breakpoint.c | 16 ++++++++-------- >> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c >> index 35225632d70a..1ab9fc865ddd 100644 >> --- a/arch/arm64/kernel/hw_breakpoint.c >> +++ b/arch/arm64/kernel/hw_breakpoint.c >> @@ -301,28 +301,28 @@ static int get_hbp_len(u8 hbp_len) >> >> switch (hbp_len) { >> case ARM_BREAKPOINT_LEN_1: >> - len_in_bytes = 1; >> + len_in_bytes = HW_BREAKPOINT_LEN_1; > > I don't think we should do this. The HW_BREAKPOINT_LEN_* definitions are > part of the user ABI and, although they correspond to the length in bytes, > that's not necessarily something we should rely on. Why should not we rely on the user ABI macros if these byte lengths were initially derived from them. But also there are similar conversions in arch_bp_generic_fields(). These hard coded raw byte length numbers seems cryptic, where as in reality these are just inter converted from generic HW breakpoints lengths. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel