Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp430258ybh; Mon, 20 Jul 2020 21:45:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNxtNTxak8zy/JSrdoZxttZ+mUgUbZxjMXqdt5Jnntr91kwty69GeAyTHTccNlNlsgyHXd X-Received: by 2002:a17:906:d8db:: with SMTP id re27mr23483812ejb.554.1595306702981; Mon, 20 Jul 2020 21:45:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595306702; cv=none; d=google.com; s=arc-20160816; b=mVleTxQ/3ZT1zQTqEMnNOjMV6ETSFAE0cbkxx87styG1D9tJ5vgTqqztrVKb8tenqh WwhhZ4xFDi3JZg/FEvLj9DZIlEddZmTWonTMND3507FyCpNGwtlX+C3ggQ34sAOExU7F QMJZ8YD80PMm+FELZ9buYIOQYhZsCXUhcVkc8DfC8Uz3jdPewL6WEPjuFDSrP3snJG3s HdTciyUK88WQG4tgUwMEwl6YkimimmT1mlXGnB2xtzKZj6voBDMbjTshiH0CxTxpb/2n zbv/82dTRsTzZB4wBwSipDLu7tvBn9YMSyrwV2vaGapp4JXt0/9JMVmRnnVM7NRhbQ/h 0hfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=/5pmXlWsJseKxXD6BxsrJbesRRq6vXEEnjoC2olkcJo=; b=DKqnsefVat5lu3LX/BF9FRarwL4Amer3s5WUNNdxnRwb9lhmjVSixIuOgvR1EoooC5 ws+b/D9FKRJacZrmNJYNSb6UXSFj328Ep1Pi2Dl/MNx/G8LT8OMtAZvzhSAzCUnQtH6T /x84DtVxIdFwXS9rsg7jPooCavY4YYgHckt34CyAzaxVd/dOiNsU8emkklaFK6rfzHZf zAvkTwbFdFVSYA+AWporlryjYCgoxfWrvxylTsDKQQGqt/GMei7IP2rzJRuoMDaX2PL1 1hEFDm2HBaZ7gWSK6DR5WBchYggeG1dopsH0dqHkB5eWVq5PM/2GsVloMUIunOFPQvwD OyBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=itQNcKcS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g16si11478389edu.513.2020.07.20.21.44.39; Mon, 20 Jul 2020 21:45:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=itQNcKcS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726737AbgGUElt (ORCPT + 99 others); Tue, 21 Jul 2020 00:41:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726177AbgGUElt (ORCPT ); Tue, 21 Jul 2020 00:41:49 -0400 Received: from mail-oo1-xc41.google.com (mail-oo1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29058C061794 for ; Mon, 20 Jul 2020 21:41:49 -0700 (PDT) Received: by mail-oo1-xc41.google.com with SMTP id t12so3666868ooc.10 for ; Mon, 20 Jul 2020 21:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/5pmXlWsJseKxXD6BxsrJbesRRq6vXEEnjoC2olkcJo=; b=itQNcKcSj6tex9SlCrDZD4lhxnrGwDST2/8O+DVZaSQs564N9CMcNzyPpsTyA0jTkR afIFXIwqpZI5bjcg4sfVJBAwY2yAjfVKmRFgKCLAt34WyqneB1Hot7yMOMsBxV+rYw6T e9iFv+fiZGwd0/QhczASKtL2HyaZH78UZp3TjGV+STJBatTKCPwfbgNs2fhut8SeBqAF 7GSDw1noOaTnB1sdxtbYV7AJLlCvegEGMR5hCiuFBWUGTZb6rnFu+rhXaxsGmgpJtyqk +eoikz7+lpaWVYk52prZ6CBH9tSnNvCqW58bBsooGfMrv17155Drm5X5Ay3pXZd7NiEw nWug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/5pmXlWsJseKxXD6BxsrJbesRRq6vXEEnjoC2olkcJo=; b=olkJmYX1SkJrOsodTzho8eEnFsQ4hjd3y9wvlb23f3uZFh+mfjXkG4IRCyOf5ev9Xq pbahe04zhgyRdnc0xG/SCp7DCgmMJglzKGhKJT9AfHF6HTuGpTZZ6CaQPwcgyHi5UkVK OdoRAgiEwaPX99p2xiMQxS/GkmOlpAovZoBJh+YMmvNJvYKcdPt7wZ6iOpzIBZCQdeo/ YZpeSTE7+AdvTuCG0Wyl4V/7dTVGQjEqEWHhRdKl4gCRlugzhE5BfH10c+rrGsATqWt6 2vXcZTg0VptzG33MhSMj3lLejnHYZebjR7UEp2leNfANM2MVA3ttzxV5JIqyylN11zi5 /6NQ== X-Gm-Message-State: AOAM533IU0BGlSj7qK6ucCrncC0eN2ft405b+ayY7j7J5bEBg1YrEQEG P60vl6gDT1m1dtpW39RxJH9X+z38IlJ76QC17wM= X-Received: by 2002:a4a:ba8b:: with SMTP id d11mr22545884oop.80.1595306508490; Mon, 20 Jul 2020 21:41:48 -0700 (PDT) MIME-Version: 1.0 References: <20200717040958.70561-1-ravi.bangoria@linux.ibm.com> <20200717040958.70561-10-ravi.bangoria@linux.ibm.com> In-Reply-To: From: Jordan Niethe Date: Tue, 21 Jul 2020 14:41:37 +1000 Message-ID: Subject: Re: [PATCH v4 09/10] powerpc/watchpoint: Return available watchpoints dynamically To: Ravi Bangoria Cc: Michael Ellerman , mikey@neuling.org, Paul Mackerras , Nicholas Piggin , Christophe Leroy , naveen.n.rao@linux.vnet.ibm.com, peterz@infradead.org, jolsa@kernel.org, oleg@redhat.com, fweisbec@gmail.com, mingo@kernel.org, pedromfc@br.ibm.com, miltonm@us.ibm.com, linuxppc-dev , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 21, 2020 at 1:57 PM Ravi Bangoria wrote: > > > > On 7/20/20 9:12 AM, Jordan Niethe wrote: > > On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria > > wrote: > >> > >> So far Book3S Powerpc supported only one watchpoint. Power10 is > >> introducing 2nd DAWR. Enable 2nd DAWR support for Power10. > >> Availability of 2nd DAWR will depend on CPU_FTR_DAWR1. > >> > >> Signed-off-by: Ravi Bangoria > >> --- > >> arch/powerpc/include/asm/cputable.h | 4 +++- > >> arch/powerpc/include/asm/hw_breakpoint.h | 5 +++-- > >> 2 files changed, 6 insertions(+), 3 deletions(-) > >> > >> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h > >> index 3445c86e1f6f..36a0851a7a9b 100644 > >> --- a/arch/powerpc/include/asm/cputable.h > >> +++ b/arch/powerpc/include/asm/cputable.h > >> @@ -633,7 +633,9 @@ enum { > >> * Maximum number of hw breakpoint supported on powerpc. Number of > >> * breakpoints supported by actual hw might be less than this. > >> */ > >> -#define HBP_NUM_MAX 1 > >> +#define HBP_NUM_MAX 2 > >> +#define HBP_NUM_ONE 1 > >> +#define HBP_NUM_TWO 2 > > I wonder if these defines are necessary - has it any advantage over > > just using the literal? > > No, not really. Initially I had something like: > > #define HBP_NUM_MAX 2 > #define HBP_NUM_P8_P9 1 > #define HBP_NUM_P10 2 > > But then I thought it's also not right. So I made it _ONE and _TWO. > Now the function that decides nr watchpoints dynamically (nr_wp_slots) > is in different file, I thought to keep it like this so it would be > easier to figure out why _MAX is 2. > > >> > >> #endif /* !__ASSEMBLY__ */ > >> > >> diff --git a/arch/powerpc/include/asm/hw_breakpoint.h b/arch/powerpc/include/asm/hw_breakpoint.h > >> index cb424799da0d..d4eab1694bcd 100644 > >> --- a/arch/powerpc/include/asm/hw_breakpoint.h > >> +++ b/arch/powerpc/include/asm/hw_breakpoint.h > >> @@ -5,10 +5,11 @@ > >> * Copyright 2010, IBM Corporation. > >> * Author: K.Prasad > >> */ > >> - > > Was removing this line deliberate? > > Nah. Will remove that hunk. > > >> #ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H > >> #define _PPC_BOOK3S_64_HW_BREAKPOINT_H > >> > >> +#include > >> + > >> #ifdef __KERNEL__ > >> struct arch_hw_breakpoint { > >> unsigned long address; > >> @@ -46,7 +47,7 @@ struct arch_hw_breakpoint { > >> > >> static inline int nr_wp_slots(void) > >> { > >> - return HBP_NUM_MAX; > >> + return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_TWO : HBP_NUM_ONE; > > So it'd be something like: > > + return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_MAX : 1; > > But thinking that there might be more slots added in the future, it > > may be better to make the number of slots a variable that is set > > during the init and then have this function return that. > > Not sure I follow. What do you mean by setting number of slots a > variable that is set during the init? Sorry I was unclear there. I was just looking and saw arm also has a variable number of hw breakpoints. If we did something like how they handle it, it might look something like: static int num_wp_slots __ro_after_init; int nr_wp_slots(void) { return num_wp_slots; } static int __init arch_hw_breakpoint_init(void) { num_wp_slots = work out how many wp_slots } arch_initcall(arch_hw_breakpoint_init); Then we wouldn't have to calculate everytime nr_wp_slots() is called. In the future if more wp's are added nr_wp_slots() will get more complicated. But just an idea, feel free to ignore. > > Thanks, > Ravi