On 07/24/2013 07:14 AM, Tomasz Figa wrote: > On Wednesday 24 of July 2013 16:51:06 Sachin Kamat wrote: ... >> This is contrary to the fact that we disable everything by default in >> the top level dt files and only enable them as required in the board >> dts files. > > No, we don't disable everything. We disable things that require board > specific setup or can't work without other support from board side. If there > is some hardware disabled in SoC level dtsi that can work without any > support from board side, then it is a BUG() and must be fixed. > >>> To illustrate the problem please consider that in the end, a dtb file >>> will be fused into board ROM (or at most flash memory) and passed to >>> the kernel by the bootloader. If you disable some hardware on DT level >>> even if it can be physically used on the board, there will be no way >>> to reenable it, if some user wanted to use it, because that would >>> require editing the fused dtb. >> >> I believe some h/w will be disabled in dt only if it should not be >> used for whatever reason. If there is no reason then ofcourse they >> would be enabled IMHO. > > Yes. This is what I meant. However the reason must be valid - e.g. > "hardware does not allow such configuration", not like "some very important > manager decided that this board should not use this". > >> Whatever be the case the choice of enabling or >> disabling should be done at the leaf node (at board level). No? > > It depends. For components that don't require any support from board side > it can be globally enabled on SoC level. If a SoC component requires > support from board side (like regulators, GPIOs, etc.) then it should be > disabled on SoC level and enabled on board level only if all the > dependencies are provided. I tend to agree with Tomasz. One note though: This is talking about the *.dts files, which may be different from the DTB that gets passed to the kernel. In other words, I don't think that the SoC or board .dtsi file (at least public versions that are hosted outside company-internal/downstream branches) have any business disabling HW based on policy or use-cases, rather than actual HW issues such as requiring other HW to support it that isn't present or doesn't work. However, I don't think anyone can influence what e.g.a bootloader does to the DTB before passing it to the kernel; it could add status="disabled" to some nodes based on policy, and nobody in the Linux kernel has any absolute right to influence it, although there's sure a right to complain about it and point out why it's a bad idea. Equally, if somebody is creating a "BSP" (ick!) for a specific product's production flash image, rather than contributing to upstream SW support for that HW board, we probably don't have too much say in what they do. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |