public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH V7 3/6] arm64/perf: Add branch stack support in struct arm_pmu
Date: Wed, 8 Feb 2023 19:26:59 +0000	[thread overview]
Message-ID: <Y+P3g8/85FIe/sUK@FVFF77S0Q05N.cambridge.arm.com> (raw)
In-Reply-To: <0351f0bc-d94b-957f-8e03-6525e47d63a4@arm.com>

On Fri, Jan 13, 2023 at 09:45:22AM +0530, Anshuman Khandual wrote:
> 
> On 1/12/23 19:24, Mark Rutland wrote:
> > On Thu, Jan 05, 2023 at 08:40:36AM +0530, Anshuman Khandual wrote:
> >>  struct arm_pmu {
> >>  	struct pmu	pmu;
> >>  	cpumask_t	supported_cpus;
> >>  	char		*name;
> >>  	int		pmuver;
> >> +	int		features;
> >>  	irqreturn_t	(*handle_irq)(struct arm_pmu *pmu);
> >>  	void		(*enable)(struct perf_event *event);
> >>  	void		(*disable)(struct perf_event *event);
> > 
> > Hmm, we already have the secure_access field separately. How about we fold that
> > in and go with:
> > 
> > 	unsigned int	secure_access    : 1,
> > 			has_branch_stack : 1;
> 
> Something like this would work, but should we use __u32 instead of unsigned int
> to ensure 32 bit width ?

I don't think that's necessary; the exact size doesn't really matter, and
unsigned int is 32-bits on all targets suppropted by Linux, not just arm and
arm64.

I do agree that if this were a userspace ABI detail, it might be preferable to
use __u32. However, I think using it here gives the misleading impression that
there is an ABI concern when there is not, and as above it's not necessary, so
I'd prefer unsigned int here.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-02-08 19:28 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05  3:10 [PATCH V7 0/6] arm64/perf: Enable branch stack sampling Anshuman Khandual
2023-01-05  3:10 ` [PATCH V7 1/6] drivers: perf: arm_pmu: Add new sched_task() callback Anshuman Khandual
2023-01-05  3:10 ` [PATCH V7 2/6] arm64/perf: Add BRBE registers and fields Anshuman Khandual
2023-01-12 13:24   ` Mark Rutland
2023-01-13  3:02     ` Anshuman Khandual
2023-02-08 19:22       ` Mark Rutland
2023-02-09  5:49         ` Anshuman Khandual
2023-02-09 10:08           ` Mark Rutland
2023-01-05  3:10 ` [PATCH V7 3/6] arm64/perf: Add branch stack support in struct arm_pmu Anshuman Khandual
2023-01-12 13:54   ` Mark Rutland
2023-01-13  4:15     ` Anshuman Khandual
2023-02-08 19:26       ` Mark Rutland [this message]
2023-02-09  3:40         ` Anshuman Khandual
2023-01-05  3:10 ` [PATCH V7 4/6] arm64/perf: Add branch stack support in struct pmu_hw_events Anshuman Khandual
2023-01-12 13:59   ` Mark Rutland
2023-01-05  3:10 ` [PATCH V7 5/6] arm64/perf: Add branch stack support in ARMV8 PMU Anshuman Khandual
2023-01-12 14:29   ` Mark Rutland
2023-01-13  5:11     ` Anshuman Khandual
2023-02-08 19:36       ` Mark Rutland
2023-02-13  8:23         ` Anshuman Khandual
2023-02-23 13:47           ` Mark Rutland
2023-03-06  7:59             ` Anshuman Khandual
2023-01-05  3:10 ` [PATCH V7 6/6] arm64/perf: Enable branch stack events via FEAT_BRBE Anshuman Khandual
2023-01-12 16:51   ` Mark Rutland
2023-01-19  2:48     ` Anshuman Khandual
2023-02-08 20:03       ` Mark Rutland
2023-02-20  8:38         ` Anshuman Khandual
2023-02-23 13:38           ` Mark Rutland
2023-01-06 10:23 ` [PATCH V7 0/6] arm64/perf: Enable branch stack sampling James Clark
2023-01-06 11:13   ` Anshuman Khandual
2023-01-11  5:05 ` Anshuman Khandual

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+P3g8/85FIe/sUK@FVFF77S0Q05N.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox