On Mon, Feb 08, 2021 at 11:12:52PM +0900, Hector Martin wrote: > On 08/02/2021 21.40, Arnd Bergmann wrote: > > On Mon, Feb 8, 2021 at 1:13 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> 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: It's only AAPL,phandle and AAPL,unit-string (equivalent to unit-address) AFAICT which are really internal format details. So it's really 'apple' that could conflct, but I can't see that mattering. > Ack, I'll use 'apple' for v2. 3 votes for 'apple'. You all get to pick the color of this shed. > 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... I'll also highlight there's a DT only tree[1] available to import DT related parts to other projects. It's generated from the kernel tree. Probably an overkill to copying at this point though. Rob [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
