On Mon, Jul 21, 2014 at 05:46:02PM +0100, Olof Johansson wrote: > On Mon, Jul 21, 2014 at 9:38 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > > On 07/21/2014 09:54 AM, Catalin Marinas wrote: > >> We have a similar issue with arm64 vexpress (well, just on the model) > >> where vexpress_sysreg_init() is a core_initcall (should be fine as > >> arch_initcall) as it needs to be done before of_platform_populate(). > >> Pawel on cc should know more of the history here. > >> > >> I recall there were also some discussions about a SoC driver model which > >> hangs off the top compatible string in the DT (e.g. "arm,vexpress") and > >> allow (minimal) code to be run slightly earlier, though still not > >> earlier than arch_initcall. > > > > I guess that would work out OK; if we force the driver that binds to a > > top-level compatible value of "nvidia,tegraNNN" to probe first, and it > > then calls out to all the low-level init code in a sane order, that > > would solve the problem. I'm not sure that's any better than having a > > machine descriptor with an "init" function though; wrapping all this in > > a driver just seems like overhead, but it would work out OK. > > This is exactly the same as having a machine descriptor, but the > arch/arm64 maintainers don't have to look at it so they don't think it > is one. > > So now we need to find a place for machine descriptors somewhere under > drivers/* too. Sigh. Agreed, this is nothing but overhead and > overabstraction. You are missing the point. It's not the machine descriptor (or mach-* directories) I want to hide but rather the need for early SoC specific initialisation. Always providing a machine descriptor with hooks for early SoC initialisation does not provide any incentive for people to think properly about what's early hardware configuration (usually done by firmware), what's actually needed for CPU booting (SoC-independent with a secondary booting protocol selectable from a small set) and how the rest of the SoC fits with the Linux device model. It's also aimed at pushing back on hardware people who think they can mess up, for example, a GIC implementation because the rest is just software and you can always add #ifdefs. On 32-bit ARM this was not always possible (non-standard essential peripherals like IRQ controller, timers) but with arm64 we have the things needed to be able to boot an SoC to arch_initcall level without any early hooks. I agree that on occasion we may need some early SoC code just because of some (bad) hardware design or simply to work around firmware/hardware bugs (and Pawel's patch is a nice approach). But this should definitely not be the norm and I disagree with moving entire arch/arm/mach-* code to drivers/soc just because one can't decide where early SoC initialisation belongs to. Also the legacy firmware argument doesn't hold for ARMv8/arm64 since the CPU now starts at EL3 in AArch64 mode and you need code there before Linux is invoked (at EL2 or EL1). In the Tegra fuse case, it's not actually some hardware configuration that needs to be set up early but rather a driver dependency initialisation which is not (cannot be) handled by the DT. This is not that different from the vexpress sysregs mfd where we worked around using an initcall. It's not ideal, I would prefer something simpler like sibling DT node sorting during unflattening (or maybe addressing issues with deferred probing if there are any) rather than working around it using machine_desc. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
