[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <f98dc238-6742-455e-3f76-e86ae4c0c838@marcan.st>
Date: Mon, 8 Feb 2021 23:12:52 +0900
From: Hector Martin <marcan@...can.st>
To: Arnd Bergmann <arnd@...nel.org>,
Krzysztof Kozlowski <krzk@...nel.org>
Cc: SoC Team <soc@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Marc Zyngier <maz@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
DTML <devicetree@...r.kernel.org>,
Olof Johansson <olof@...om.net>
Subject: Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1)
devicetree
On 08/02/2021 21.40, Arnd Bergmann wrote:
> On Mon, Feb 8, 2021 at 1:13 PM Krzysztof Kozlowski <krzk@...nel.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:
Ack, I'll use 'apple' for v2.
Amusingly, Apple actually use 'apple,firestorm' and 'apple,icestorm' for
the CPUs in their devicetrees for these machines, so those will end up
identical :) (they don't use apple-related prefixes for any other
compatible strings at all, it's a mess). But we don't care about what
their ADTs (Apple DTs) do in Linux anyway, the bootloader abstracts all
that out and we'll be dealing with mantaining proper DTs ourselves.
>> 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.
Thanks for pointing this out; this was actually unintentional. I based
it off of an old dts I'd written ages ago and forgot to revisit the
license. I even have it marked GPL-2.0+ in the copy in our bootloader
repo, which is otherwise supposed to be MIT for original code...
--
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists