Messages in this thread |  | | From | Hector Martin 'marcan' <> | Subject | Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree | Date | Fri, 5 Feb 2021 16:11:53 +0900 |
| |
On 05/02/2021 08.08, Arnd Bergmann wrote: > On Thu, Feb 4, 2021 at 10:44 PM Hector Martin 'marcan' <marcan@marcan.st> wrote: >> On 05/02/2021 06.29, Arnd Bergmann wrote: >>> On Thu, Feb 4, 2021 at 9:39 PM Hector Martin <marcan@marcan.st> wrote: >>> >>> We tend to split the dts file into one file per SoC and one for the >>> specific board. I guess in this case the split can be slightly different, >>> but it does feel better to be prepared for sharing a lot of the contents >>> between the different products. >>> >>> In most cases, you'd want the 'aliases' and 'chosen' nodes to be >>> in the board specific file. >> >> I thought about that, but wasn't sure if splitting it up at this early >> stage made much sense since I'm not sure what the split should be, given >> all supported hardware is the same for all 3 released devices. >> >> I'm happy to throw the aliases/chosen nodes into board specific files if >> you think that's a good starting point. Perhaps /memory too? Those >> properties are filled in/patched by the bootloader anyway... > > Yes, I think that would help make it more consistent with other > platforms even if we don't care too much here.
Ack, I'll split it up for v2.
> We don't really have overlays in the kernel sources (yet), though it > is something that keeps coming up. For the moment, I'd just > assume you can have one .dts file for each thing you want to > support and keep the shared bits in .dtsi files.
No problem. We'll experiment with overlays in m1n1 and see how that goes.
One thing I wanted to ask: is there some kind of "experimental" policy for DT bindings? At early platform bring-up stages it seems like it could be valuable to allow for breaking DT changes while we flesh out the details (this is especially true of a reverse engineered platform like this, where we don't have knowledge of all the hardware details a priori). The dozen or so users we might have at this stage obviously won't complain too much :)
-- Hector Martin "marcan" (marcan@marcan.st) Public Key: https://mrcn.st/pub
|  |