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

[Arnd Bergmann]

On Mon, Feb 8, 2021 at 1:13 PM Krzysztof Kozlowski <krzk at kernel.org> wrote:
>
> 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 :)
>
> Thanks for explanation. I propose to choose just "apple". Sticking to
> old vendor name is not a requirement - we have few vendor prefixes which
> were marked as deprecated because we switched to a better one.

We've gone back and forth on this a few times already. My current
preference would also be to go with "apple", not because it's somehow
nicer or clearer but because it avoids the namespace conflict with
what the Apple firmware uses:

The point of the vendor prefix is to prevent two people from introducing
the same identifier with slightly different meanings. This used to be
the stock ticker symbol ("ibm", "SUNW", "AAPL", ...) back when the
only people making devices with firmware were large corporations.

In FDT, it's usually random contributors introducing the names to make
something work on Linux, with unique strings coming from code review.

The identifiers that Apple use are highly unlikely to cause clashes
with the ones we use in Linux, since you probably won't find much
software that has to deal with both formats, but the fact that Apple
still prefixes those strings with their stock ticker symbol tells me that
someone there still considers the namespace relevant, so it's more
polite to stay out of their lawn.

> Makes sense. In such case it's indeed your work. Since you introduce it,
> the DTSes are usually licensed with (GPL-2.0+ OR MIT).

Indeed, we do want other OSs to use our dts files, so the general
preference is to have a permissive license, unless you have a strong
reason yourself to require GPL-only.

       Arnd