On Sat, Sep 29, 2018 at 12:47 PM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > > On Thu, Sep 27, 2018 at 11:49:20AM -0300, Rodrigo Exterckötter Tjäder wrote: > > On Thu, Sep 27, 2018 at 5:17 AM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > > > > > > On Tue, Sep 25, 2018 at 02:47:59PM -0300, Rodrigo Exterckötter Tjäder wrote: > > > > On Tue, Sep 25, 2018 at 6:01 AM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > > > > > We can't really do that, unfortunately. If the device tree name was to > > > > > change for a given board, we'd break all the build systems, boot > > > > > scripts and distros out there. > > > > > > > > What if we keep the device tree for the version without WiFi and eMMC > > > > with the current name and create new device trees for the other two > > > > versions? > > > > > > Wifi and Bluetooth should be dealt with with overlays in this case, > > > and since the eMMC is already enabled, then there's nothing to do, I > > > guess. > > > > It's WiFi that is already enabled, not eMMC. Only one of the three > > variants has WiFi. > > Ah, right, sorry. In the board that doesn't have an emmc, are the pins > usable for something else? I don't have the variant without eMMC nor could I find pictures of it. The schematics do mention that the A64 pins could be used to control NAND flash, but you'd have to solder that yourself. > > We can't even remove a node from a device tree? Removing the WiFi node > > from the current tree would make it correspond to the variant with the > > least features. > > Not really. How pissed would you be if you were a user, had wifi > running on your board, you upgrade your kernel, and then it's just > gone? :) That would suck, but what about someone who has the board with no wifi and problems start happening because the wifi is enabled on the device tree? > > About device tree overlays, I read overlay-notes.txt, but I went > > looking for an example with "git grep /plugin/ arch" and it came > > empty. Is this approach not used for other boards? > > It is, it's simply not stored in the kernel, but through other third > party repos. So that would mean that it's up to every distro to support the boards instead of relying on mainline support? > > Does the overlay approach make the device available at boot time? That > > is important for a storage device such as eMMC. > > > > I went with the separate dts approach because that's what I saw was > > done for other similar cases, like Pine64 and Pine64+, OLinuXino-LIME2 > > and its variant with eMMC, among others. > > Yeah, but in all these cases, it was done from day one, not after the > facts. For the LIME2 the dts for the emmc variant was commited two years after the base LIME2 dts. What if instead of keeping the current dt for the least featureful model we keep it for the most featureful model and create new dts for the two less featureful models?
