On 8 September 2016 at 15:38, Rob Herring <robh+dt@xxxxxxxxxx> wrote: > Yes, in theory a device can go from disabled to okay, but that's > generally never been supported. Linux takes the simple approach of > "disabled" means ignore it. I think we'll see that change with > overlays. No need for future tense there, overlays are being used on a daily basis on the BeagleBone and have already been for years. > I don't agree. Generally, disabled means the h/w is there, but don't > use it. There may be some cases where the hardware doesn't exist for > the convenience of having a single dts, but that's the exception. Yes and no. What matters is whether "don't use it" means "you can't put it to good use" or "don't even try to reach the peripheral, bad things will happen". Right now it's used for both cases. Ideally the latter case would be removed from the kernel's view entirely. On 8 September 2016 at 16:20, Nishanth Menon <nm@xxxxxx> wrote: > Minor point here It's not minor, it's quite crucial. > maintaining dts per paper spin is just too impossible to maintain Even if the per-spin dtsi just consists of including the common dtsi and then applying /delete-node/ per peripheral that is disabled in efuse? (or through firewalling, e.g. on HS devices) > the variations if maintained as seperate dts might infact end up being > larger in number than all the dts we have in arch/arm/boot/dts There are 813 dts files there. Even if there were a dra7xx and am57xx for every value of x (and there really isn't) you wouldn't get anywhere near there. But, fair enough, efuse bits are definitely an excellent way to get combinatorial explosion. Afaik those feature bits are readable through the control module on TI SoCs though. Assuming such a thing is the norm in SoC world maybe a "delete-if" property referencing some sort of test on register bits of a referenced syscon node might do the trick? On the cortex-A8 doing auto-detection would be a feasible alternative, by reusing the existing exception mechanism to trap synchronous aborts, but e.g. the Cortex-A15 seems to use async aborts for *every* bus error, which makes things just very awful. Matthijs -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
