From: Alyssa Rosenzweig <alyssa@rosenzweig.io>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>,
Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>,
Rob Herring <robh+dt@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Dougall <dougallj@gmail.com>,
kernel-team@android.com
Subject: Re: [PATCH v2 8/8] drivers/perf: Add Apple icestorm/firestorm CPU PMU driver
Date: Wed, 1 Dec 2021 12:56:26 -0500 [thread overview]
Message-ID: <Yae3Sqp528AB2XCl@sunset> (raw)
In-Reply-To: <YaepolizIKkzDQoV@FVFF77S0Q05N>
> > Add a new, weird and wonderful driver for the equally weird Apple
> > PMU HW. Although the PMU itself is functional, we don't know much
> > about the events yet, so this can be considered as yet another
> > random number generator...
>
> It's really frustrating that Apple built this rather than the architected PMU,
> because we've generally pushed back on IMPLEMENTATION DEFINED junk in this
> area, and supporting this makes it harder to push back on other vendors going
> the same route, which I'm not keen on. That, and the usual state of IMP-DEF
> stuff making this stupidly painful to reason about.
Rules can be a bit stricter for vendors than for ragtag
reverse-engineers. The kernel community can push back on vendor's
choices because vendors have the power to choose otherwise.
But reverse engineers' hands are sometimes forced by bad vendor
decisions; rejecting the driver means mainline can never support the
hardware. I believe there's precedent for distinguishing these cases,
at least in the graphics subsystem.
I don't know if this applies to this driver. I only wish to offer a
rebuttal to a future vendor trying to mainline something questionable
with the defence "Asahi Linux / Nouveau / ... did it, so we can too".
(This will be relevant to the Apple M1 display controller driver, which
would be a hard NAK if submitted by Apple...)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Alyssa Rosenzweig <alyssa@rosenzweig.io>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>,
Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>,
Rob Herring <robh+dt@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Dougall <dougallj@gmail.com>,
kernel-team@android.com
Subject: Re: [PATCH v2 8/8] drivers/perf: Add Apple icestorm/firestorm CPU PMU driver
Date: Wed, 1 Dec 2021 12:56:26 -0500 [thread overview]
Message-ID: <Yae3Sqp528AB2XCl@sunset> (raw)
In-Reply-To: <YaepolizIKkzDQoV@FVFF77S0Q05N>
> > Add a new, weird and wonderful driver for the equally weird Apple
> > PMU HW. Although the PMU itself is functional, we don't know much
> > about the events yet, so this can be considered as yet another
> > random number generator...
>
> It's really frustrating that Apple built this rather than the architected PMU,
> because we've generally pushed back on IMPLEMENTATION DEFINED junk in this
> area, and supporting this makes it harder to push back on other vendors going
> the same route, which I'm not keen on. That, and the usual state of IMP-DEF
> stuff making this stupidly painful to reason about.
Rules can be a bit stricter for vendors than for ragtag
reverse-engineers. The kernel community can push back on vendor's
choices because vendors have the power to choose otherwise.
But reverse engineers' hands are sometimes forced by bad vendor
decisions; rejecting the driver means mainline can never support the
hardware. I believe there's precedent for distinguishing these cases,
at least in the graphics subsystem.
I don't know if this applies to this driver. I only wish to offer a
rebuttal to a future vendor trying to mainline something questionable
with the defence "Asahi Linux / Nouveau / ... did it, so we can too".
(This will be relevant to the Apple M1 display controller driver, which
would be a hard NAK if submitted by Apple...)
next prev parent reply other threads:[~2021-12-01 17:58 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 13:49 [PATCH v2 0/8] drivers/perf: CPU PMU driver for Apple M1 Marc Zyngier
2021-12-01 13:49 ` Marc Zyngier
2021-12-01 13:49 ` [PATCH v2 1/8] dt-bindings: arm-pmu: Document Apple PMU compatible strings Marc Zyngier
2021-12-01 13:49 ` Marc Zyngier
2021-12-12 7:27 ` Hector Martin
2021-12-12 7:27 ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 2/8] dt-bindings: apple, aic: Add CPU PMU per-cpu pseudo-interrupts Marc Zyngier
2021-12-01 13:49 ` [PATCH v2 2/8] dt-bindings: apple,aic: " Marc Zyngier
2021-12-12 7:26 ` Hector Martin
2021-12-12 7:26 ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 3/8] irqchip/apple-aic: Add cpumasks for E and P cores Marc Zyngier
2021-12-01 13:49 ` Marc Zyngier
2021-12-01 16:08 ` Mark Rutland
2021-12-01 16:08 ` Mark Rutland
2021-12-03 16:32 ` Marc Zyngier
2021-12-03 16:32 ` Marc Zyngier
2021-12-12 7:22 ` Hector Martin
2021-12-12 7:22 ` Hector Martin
2021-12-12 7:30 ` Hector Martin
2021-12-12 7:30 ` Hector Martin
2021-12-13 14:43 ` Marc Zyngier
2021-12-13 14:43 ` Marc Zyngier
2021-12-01 13:49 ` [PATCH v2 4/8] irqchip/apple-aic: Wire PMU interrupts Marc Zyngier
2021-12-01 13:49 ` Marc Zyngier
2021-12-12 7:25 ` Hector Martin
2021-12-12 7:25 ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 5/8] irqchip/apple-aic: Move PMU-specific registers to their own include file Marc Zyngier
2021-12-01 13:49 ` Marc Zyngier
2021-12-12 7:23 ` Hector Martin
2021-12-12 7:23 ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 6/8] arm64: apple: t8301: Add PMU nodes Marc Zyngier
2021-12-01 13:49 ` Marc Zyngier
2021-12-12 7:26 ` Hector Martin
2021-12-12 7:26 ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 7/8] drivers/perf: arm_pmu: Handle 47 bit counters Marc Zyngier
2021-12-01 13:49 ` Marc Zyngier
2021-12-12 7:26 ` Hector Martin
2021-12-12 7:26 ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 8/8] drivers/perf: Add Apple icestorm/firestorm CPU PMU driver Marc Zyngier
2021-12-01 13:49 ` Marc Zyngier
2021-12-01 16:58 ` Mark Rutland
2021-12-01 16:58 ` Mark Rutland
2021-12-01 17:56 ` Alyssa Rosenzweig [this message]
2021-12-01 17:56 ` Alyssa Rosenzweig
2021-12-02 15:39 ` Marc Zyngier
2021-12-02 15:39 ` Marc Zyngier
2021-12-02 16:14 ` Mark Rutland
2021-12-02 16:14 ` Mark Rutland
2021-12-03 11:22 ` Marc Zyngier
2021-12-03 11:22 ` Marc Zyngier
2021-12-03 12:04 ` Mark Rutland
2021-12-03 12:04 ` Mark Rutland
2021-12-03 16:22 ` Marc Zyngier
2021-12-03 16:22 ` Marc Zyngier
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=Yae3Sqp528AB2XCl@sunset \
--to=alyssa@rosenzweig.io \
--cc=devicetree@vger.kernel.org \
--cc=dougallj@gmail.com \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sven@svenpeter.dev \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.