Hi, On Wednesday, November 13, 2013 11:27:03 AM Sylwester Nawrocki wrote: > On 13/11/13 09:08, Tomasz Figa wrote: > >> As was discussed earlier too, status field of DT node is not supposed > >> > to be used for > >> > keeping an IP enabled or disabled. That should be done via the kernel > >> > config. The DT status > >> > is mostly to indicate the hardware status of the IP on the SoC/board. > >> > If the node fully defines the hardware, > >> > then it should be kept enabled by default unless such enabling causes > >> > some issues with other IPs due to > >> > pin sharing conflicts, etc. In the above case the node completely > >> > defines the hardware and hence there is no > >> > reason to keep it disabled. > > > > That's correct. (Unless I'm missing some board specific dependency of RTC. > > If so, please correct me.) > > I don't really like this argument. Why not allow the firmware to decide > which devices are relevant and should be handled by the kernel ? > And since we are aiming at single kernel config, if I understand things > correctly, I can't see anything else than dts that could hold the machine > *configuration*. > > So let's not make all stuff enabled by default, that's not something we > want on those mobile device SoCs. We should not be making fine system > tuning more difficult than necessary. > > I'm with Kukjin on this matter and would prefer patches like the $subject > patch not be merged. I generally agree with Sylwester and Kukjin that devices should not be enabled by default in dtsi files. However in a particular case of RTC support there should be an exception from the generic rule and RTC should be enabled for all EXYNOS boards (we have RTC driver config option already enabled in our exynos_defconfig and we are also already enabling RTC device explicitly in EXYNOS5250 dtsi file). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- 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
 |