On Fri, Nov 2, 2012 at 4:07 PM, Jason Kridner <jkridner@xxxxxxxxxxxxxxx> wrote: >> Take a look at arch/x86/platform/mrst/mrst.c. It's a specific example of >> a platform which parses tables and attaches devices to the right physical >> bus in a manner they can be reliably probed even when the device has no >> sane autodetect. > > I know I *am* the slow person in the room, but doesn't this approach > require the code to be compiled into the kernel to support the devices > ahead of time? While I think it might be reasonable to have hardware > developers provide DT fragments in their EEPROMs, there's no way to > get them to submit code patches in order to get their hardware to > work. They need to ship hardware that works with pre-existing > software, since there will be hundreds of boards created by people > with little to no previous Linux experience (akin to Arduino). I seem > to be missing how that approach would get us there. If it is truly new hardware, then there really is no way around them either a) submitting new kernel drivers or b) driving them from userspace. If it is devices with existing drivers populated onto new custom cape boards, then the DT fragment approach should be sufficient for populating them into the Linux driver model. (assuming of course those drivers are already compiled into the kernel) g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
