From: Hector Martin <marcan@marcan.st>
To: Rob Herring <robh@kernel.org>
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: Tue, 9 Feb 2021 09:49:29 +0900 [thread overview]
Message-ID: <d8454963-3242-699b-4c20-e85d26b19796@marcan.st> (raw)
In-Reply-To: <20210208191447.GA1677483@robh.at.kernel.org>
On 09/02/2021 04.14, Rob Herring wrote:
> Does there need to be a legal entity behind 'The Asahi Linux
> Contributors' to be valid?
I don't think so, this seems to be common practice in other open source
projects, and recommended these days.
Some recent discussion on the subject from the Linux Foundation:
https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/
> 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 thought that's what Git history was for; certainly we aren't keeping
file headers up to date every time someone touches a file (which for
anything other than trivial changes gives them a copyright interest in a
portion of the file).
Asahi Linux's policy for bespoke projects is to use "The Asahi Linux
Contributors" for this reason, acknowledging that the copyright headers
aren't up to date anyway (also the years...), and implicitly directing
people to the orignal project (which is where Git history is kept and
contains the true record of copyright owneship).
I'm not trying to shake up how we handle copyright lines in the kernel
here, of course; if you prefer some nominal copyright line from "whoever
first wrote the file or most of it" I can do that. But it certainly
won't be the only person you have to ask if you want to relicense, if
anyone else touched the file in a nontrivial way :)
There are a few examples of this style in the tree, mostly pulled from
other projects:
arch/arm/oprofile/common.c
drivers/gpu/drm/vgem/vgem_drv.[ch]
drivers/md/dm-verity-target.c
drivers/md/dm-verity.h
>>> 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.
The pattern here was board, soc, "arm-platform"; the first two seem to
be a common (and useful) pattern, and I hope I can get rid of the third
once we solve #11/#12 in a saner way.
> 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.
What do you suggest for this series?
>
>>>> + 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.
Ack. I hope we can basically acknowledge breaking DT changes without too
much fuss at this early stage of bring-up, until things calm down a bit
and we have real users who would complain :) (not that I won't try to
avoid it).
--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
_______________________________________________
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-09 0:50 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
2021-02-09 0:49 ` Hector Martin [this message]
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=d8454963-3242-699b-4c20-e85d26b19796@marcan.st \
--to=marcan@marcan.st \
--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=maz@kernel.org \
--cc=olof@lixom.net \
--cc=robh@kernel.org \
--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).