On Sun, Sep 16, 2012 at 11:09 AM, Sebastian Hesselbarth <sebastian.hesselbarth@xxxxxxxxx> wrote: > On 09/16/2012 09:46 AM, Andrew Lunn wrote: >> Here you are suggesting we have to put into the DT what chip we expect >> to be on. >> >> What is the advantage of this, over getting the information from the >> device itself? > > If there are no objections from the others, I agree to determine the > variant from the existing kirkwood_id(). I was just unsure if it is > ok to use platform-specific code with DT here. > > Any ideas how to get kirkwood_id() linked into pinctrl-kirkwood with > the get-rid-of-arch-includes policy? You found the weak spot between two consolidation tracks. Getting rid of a broadcast autodetect functions from say <mach/foo-id-probe.h> is nominally done by passing the data to the driver as platform data instead, and only using these functions in the mach-foo folder when populating platform data, and thus it can be made into a local header, say mach-foo/foo-id-probe.h So the machine/arch code reads these registers to populate the platform data and device drivers only look at the platform data, which has some enum or bool indicating what hardware it's running on, cool. But according to the other consolidation track, platform data should go into device tree bindings. So the conclusion is that the DT must contain the data about the platform, so it's not auto-probed by the kernel. (I.e. the kernel reads no registers to figure out what hardware this is, that stuff comes from the device tree.) DT purists will say that the boot loader should ask the chipset what it is with the same register writes and populate the DT accordingly, instead of loading a precompiled blob. Some may even ponder the crazy concept of amending the DT in the kernel at early boot. But in practice someone will give up, encode the stuff in the static device tree and autoprobing of the platform goes out the window. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
