[PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree

Rob Herring robh at kernel.org
Mon Feb 8 21:05:26 EST 2021


On Mon, Feb 8, 2021 at 6:49 PM Hector Martin <marcan at marcan.st> wrote:
>
> 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/

Okay, that's good to know. I'd primarily seen this for Chromium which
obviously has a company (and lawyers) behind it.

> >  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).

Yes, for sure. Especially since copyrights tend to be stale as the
blog talks about.

> 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 :)

No, it's fine as is.

> 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?

Fine as-is unless someone wants to define the pattern and add it to
the fixed-clock schema before this is merged.

Rob



More information about the linux-arm-kernel mailing list