From: Rob Herring <robh@kernel.org>
To: Hector Martin 'marcan' <marcan@marcan.st>
Cc: Arnd Bergmann <arnd@kernel.org>,
devicetree@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
linux-kernel@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
soc@kernel.org, Olof Johansson <olof@lixom.net>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree
Date: Mon, 8 Feb 2021 13:14:47 -0600 [thread overview]
Message-ID: <20210208191447.GA1677483@robh.at.kernel.org> (raw)
In-Reply-To: <cd67b2ce-9676-31b4-85f7-de1ec9b2bf72@marcan.st>
On Mon, Feb 08, 2021 at 08:56:53PM +0900, Hector Martin 'marcan' wrote:
> On 08/02/2021 20.04, Krzysztof Kozlowski wrote:
> > apple
> >
> > Don't make things different for this one platform (comparing to all
> > other platforms). Apple is not that special. :)
>
> AAPL is the old vendor prefix used in the PowerPC era. I'm happy to use
> `apple`, as long as we're OK with having two different prefixes for the same
> vendor, one for PPC and one for ARM64. I've seen opinions go both ways on
> this one :)
>
> > > + * Copyright 2021 Hector Martin <marcan@marcan.st>
> >
> > A lot here might be difficult to reverse-egineer or figure out by
> > ourself, so usually people rely on vendor sources (the open source
> > compliance package). Didn't you receive such for the iOS (or whatever
> > was on your Mac)?
>
> Apple source drops are sparse (they don't even include things like the
> irqchip driver, only the very core OS code) and APSL licensed, which is a
> license incompatible with the GPL. Worse, they've moved to a partial-blob
> model with the M1; M1-compatible XNU source code drops now include a .a blob
> with startup and CPU-specific code, for which no source code is provided.
> (to be clear: Apple does not ship Linux for these machines)
>
> Honestly, beyond what's in this patchset and a few more details about CPU
> registers like performance monitoring stuff that exist in public XNU drops
> but I haven't looked into yet, Apple's source code drops are going to be
> practically useless to us from here on out. It's all binaries after this.
>
> Apple device trees are not open source at all; those are provided by iBoot
> and ship with device firmware, which is not openly licensed. Those device
> trees are OF-inspired, but otherwise in a different format and structure to
> Linux device trees.
>
> Since there is zero Apple-published code or data with a license compatible
> with the Linux kernel to be used here, there can be zero copyright lines
> claiming any submissions are copyright Apple from us, because that would
> imply a license violation has occurred. I am treating this as I would any
> other no-source reverse engineering project, that is, ensuring that I only
> look at Apple code (binaries, source, devicetrees, whatever) to understand
> how the hardware functions, build documentation for it (at least in my head,
> but I am also trying to document things on our wiki as I go), and then write
> original code to drive it from Linux, unrelated to whatever Apple was doing.
>
> We're also trying to avoid looking at any Apple stuff in general as much as
> possible, preferring black-box approaches where feasible, to minimize
> exposure. For example, I only looked at an (outdated, arm32 era) AIC
> register name list in XNU to write the AIC driver; there is no actual AIC
> driver code in the source, and instead of decompiling Apple's binary blob
> AIC driver module, I figured out how the hardware actually worked via
> probing and experimentation. The entire userspace GPU stack is being reverse
> engineered via a black-box approach, without any decompilation. I'm going to
> see what I can do about the kernel driver in the future, and prefer some
> kind of mmio tracing solution if I can get it all to work on macOS.
>
> As for this file specifically: while I am obviously looking at Apple's DTs
> to figure out things like register offsets and what hardware exists, those
> are facts, and facts are not copyrightable, and thus Apple does not hold any
> copyright interest over this code as I submitted it. Short of verbatim
> copying and pasting of entire nodes with bespoke property names (which would
> never fly here anyway because Apple does things very differently from Linux
> DTs when you get down into the details), it would be extremely hard to argue
> that translating hardware information from decompiled Apple DTs to Linux DTs
> would constitute a copyright violation, since the entire purpose of DTs is
> to describe hardware facts.
>
> You can read more about our reverse engineering and copyright policy at
> https://alx.sh/re - if you have any suggestions or spot anything
> problematic, please let me know.
>
> (I'm actually probably going to change that copyright line to "The Asahi
> Linux Contributors" for v2, if that's okay with the kernel folks, to be in
> line with our other projects; I defaulted to my name since so far I'm the
> only contributor to these files, but I expect other people to throw PRs at
> me in the future and the history to end up with more names here)
Does there need to be a legal entity behind 'The Asahi Linux
Contributors' to be valid?
From a more practical standpoint, if we want to relicense something in
say 5 years from now, who do we ask for an okay?
> > I guess Rob will comment on the dt-bindings more... but for me a generic
> > "arm-platform" is too generic. What's the point of it? I didn't see any
> > of such generic compatibles in other platforms.
>
> This is a hack for patches #11/#12 to use, and I expect it will go away once
> we figure out how to properly handle that problem (which needs further
> discussion). Sorry for the noise, this should not be there in the final
> version.
I was going to ask on this. If you have a user of it, I'm okay with it.
Generally though, 3 or 4 levels of compatible don't really have users.
> > > + bootargs = "earlycon";
> >
> > This should not be hard-coded in DTS. Pass it from bootloader.
>
> My apologies, this was garbage left over from before I had bootargs support
> in the bootloader. Will be gone for v2.
>
> > > + clk24: clk24 {
> >
> > Just "clock". Node names should be generic.
>
> Really? Almost every other device device tree uses unique clock node names.
It's a WIP to be more consistent around node names. For actual
clock controllers we have 'clock-controller(@.*)?'. There's not really
something established for 'fixed-clock'. We probably should define
something, but that goes in the schema first.
> > > + compatible = "fixed-clock";
> > > + #clock-cells = <0>;
> > > + clock-frequency = <24000000>;
> > > + clock-output-names = "clk24";
> >
> > What clock is it? Part of board or SoC? Isn't it a work-around for
> > missing clock drivers?
>
> The clock topology isn't entirely known yet; I'm submitting this as an
> initial bring-up patchset and indeed there should be a clockchip driver in
> the future. The UART driver wants a clock to be able to calculate baud
> rates. I figured we can get away with a fixed-clock for now while that part
> of the SoC gets figured out.
That is normal. It does break compatibility between an old kernel
and new DT. There's not really a good way to avoid that.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-02-08 19:16 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-04 20:39 [PATCH 00/18] Apple M1 SoC platform bring-up Hector Martin
2021-02-04 20:39 ` [PATCH 01/18] dt-bindings: vendor-prefixes: add AAPL prefix Hector Martin
2021-02-08 10:27 ` Krzysztof Kozlowski
2021-02-08 17:32 ` Rob Herring
2021-02-08 18:12 ` Krzysztof Kozlowski
2021-02-08 19:59 ` Arnd Bergmann
2021-02-08 23:17 ` Hector Martin
2021-02-04 20:39 ` [PATCH 02/18] dt-bindings: arm: cpus: Add AAPL, firestorm & icestorm compatibles Hector Martin
2021-02-04 20:39 ` [PATCH 03/18] dt-bindings: arm: AAPL: Add bindings for Apple ARM platforms Hector Martin
2021-02-04 20:39 ` [PATCH 04/18] arm64: Kconfig: Introduce CONFIG_ARCH_APPLE Hector Martin
2021-02-06 13:17 ` Marc Zyngier
2021-02-07 8:05 ` Hector Martin 'marcan'
2021-02-04 20:39 ` [PATCH 05/18] tty: serial: samsung_tty: add support for Apple UARTs Hector Martin
2021-02-04 23:55 ` kernel test robot
2021-02-05 9:44 ` Hector Martin 'marcan'
2021-02-05 2:19 ` kernel test robot
2021-02-06 13:15 ` Marc Zyngier
2021-02-07 9:12 ` Hector Martin 'marcan'
2021-02-07 9:26 ` Hector Martin 'marcan'
2021-02-08 9:36 ` Krzysztof Kozlowski
2021-02-08 16:14 ` Hector Martin
2021-02-08 10:34 ` Marc Zyngier
2021-02-08 16:18 ` Hector Martin
2021-02-08 16:46 ` Greg Kroah-Hartman
2021-02-08 23:22 ` Hector Martin
2021-02-08 10:54 ` Krzysztof Kozlowski
2021-02-08 16:10 ` Hector Martin
2021-02-08 18:37 ` Krzysztof Kozlowski
2021-02-08 23:23 ` Hector Martin
2021-02-04 20:39 ` [PATCH 06/18] dt-bindings: serial: samsung: Add AAPL, s5l-uart compatible Hector Martin
2021-02-04 20:39 ` [PATCH 07/18] tty: serial: samsung_tty: enable for ARCH_APPLE Hector Martin
2021-02-04 21:16 ` Arnd Bergmann
2021-02-04 21:27 ` Hector Martin 'marcan'
2021-02-04 20:39 ` [PATCH 08/18] arm64: cpufeature: Add a feature for FIQ support Hector Martin
2021-02-06 13:58 ` Marc Zyngier
2021-02-07 8:28 ` Hector Martin 'marcan'
2021-02-08 11:29 ` Marc Zyngier
2021-02-08 15:51 ` Hector Martin
2021-02-04 20:39 ` [PATCH 09/18] arm64: cputype: Add CPU types for the Apple M1 big/little cores Hector Martin
2021-02-04 20:39 ` [PATCH 10/18] arm64: Introduce FIQ support Hector Martin
2021-02-06 15:37 ` Marc Zyngier
2021-02-06 16:22 ` Arnd Bergmann
2021-02-07 8:36 ` Hector Martin 'marcan'
2021-02-07 12:25 ` Arnd Bergmann
2021-02-07 15:38 ` Hector Martin 'marcan'
2021-02-07 18:49 ` Arnd Bergmann
2021-02-08 23:34 ` Hector Martin
2021-02-07 8:47 ` Hector Martin 'marcan'
2021-02-08 11:30 ` Marc Zyngier
2021-02-04 20:39 ` [PATCH 11/18] arm64: Kconfig: Require FIQ support for ARCH_APPLE Hector Martin
2021-02-06 15:46 ` Marc Zyngier
2021-02-07 9:23 ` Hector Martin 'marcan'
2021-02-08 12:05 ` Marc Zyngier
2021-02-08 15:48 ` Hector Martin
2021-02-04 20:39 ` [PATCH 12/18] arm64: setup: Use nGnRnE IO mappings for fixmap on Apple platforms Hector Martin
2021-02-04 22:25 ` Arnd Bergmann
2021-02-04 20:39 ` [PATCH 13/18] arm64: ioremap: use nGnRnE mappings on platforms that require it Hector Martin
2021-02-04 22:21 ` Arnd Bergmann
2021-02-08 22:57 ` Arnd Bergmann
2021-02-08 23:20 ` Mark Kettenis
2021-02-09 0:25 ` Hector Martin
2021-02-09 9:15 ` Arnd Bergmann
2021-02-09 9:58 ` Mark Kettenis
2021-02-09 11:22 ` Hector Martin
2021-02-09 9:35 ` Arnd Bergmann
2021-02-10 12:24 ` Hector Martin
2021-02-10 13:40 ` Mark Kettenis
2021-02-04 20:39 ` [PATCH 14/18] dt-bindings: interrupt-controller: Add DT bindings for apple-aic Hector Martin
2021-02-09 23:07 ` Rob Herring
2021-02-04 20:39 ` [PATCH 15/18] irqchip/apple-aic: Add support for the Apple Interrupt Controller Hector Martin
2021-02-04 21:37 ` Arnd Bergmann
2021-02-04 22:04 ` Hector Martin 'marcan'
2021-02-04 23:04 ` Arnd Bergmann
2021-02-05 7:41 ` Hector Martin 'marcan'
2021-02-05 10:33 ` Arnd Bergmann
2021-02-05 2:27 ` kernel test robot
2021-02-05 9:45 ` Hector Martin 'marcan'
2021-02-08 9:25 ` Marc Zyngier
2021-02-08 10:29 ` Arnd Bergmann
2021-02-08 11:13 ` Hector Martin 'marcan'
2021-02-08 11:21 ` Arnd Bergmann
2021-02-08 11:36 ` Marc Zyngier
2021-02-08 12:17 ` Arnd Bergmann
2021-02-08 15:31 ` Hector Martin
2021-02-09 6:20 ` Hector Martin
2021-02-04 20:39 ` [PATCH 16/18] irqchip/apple-aic: Add SMP / IPI support Hector Martin
2021-02-04 20:39 ` [PATCH 17/18] dt-bindings: display: add AAPL,simple-framebuffer Hector Martin
2021-02-04 20:39 ` [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree Hector Martin
2021-02-04 21:29 ` Arnd Bergmann
2021-02-04 21:44 ` Hector Martin 'marcan'
2021-02-04 23:08 ` Arnd Bergmann
2021-02-05 7:11 ` Hector Martin 'marcan'
2021-02-05 12:43 ` Arnd Bergmann
2021-02-08 11:04 ` Krzysztof Kozlowski
2021-02-08 11:56 ` Hector Martin 'marcan'
2021-02-08 12:13 ` Krzysztof Kozlowski
2021-02-08 12:40 ` Arnd Bergmann
2021-02-08 14:12 ` Hector Martin
2021-02-08 17:58 ` Rob Herring
2021-02-09 0:32 ` Hector Martin
2021-02-08 19:14 ` Rob Herring [this message]
2021-02-09 0:49 ` Hector Martin
2021-02-09 2:05 ` Rob Herring
2021-02-10 10:19 ` Tony Lindgren
2021-02-10 11:07 ` Hector Martin
2021-02-10 11:34 ` Tony Lindgren
2021-02-10 11:43 ` Hector Martin
2021-02-10 12:24 ` Daniel Palmer
2021-02-10 12:54 ` Tony Lindgren
2021-02-10 12:56 ` Hector Martin
2021-02-10 12:55 ` Krzysztof Kozlowski
2021-02-10 13:19 ` Tony Lindgren
2021-02-10 13:25 ` Krzysztof Kozlowski
2021-02-08 12:27 ` Marc Zyngier
2021-02-08 14:53 ` Hector Martin
2021-02-08 15:36 ` Marc Zyngier
2021-02-04 22:43 ` [PATCH 00/18] Apple M1 SoC platform bring-up Arnd Bergmann
2021-02-05 11:35 ` Hector Martin 'marcan'
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=20210208191447.GA1677483@robh.at.kernel.org \
--to=robh@kernel.org \
--cc=arnd@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=maz@kernel.org \
--cc=olof@lixom.net \
--cc=soc@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;
as well as URLs for NNTP newsgroup(s).