Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751830Ab2KEBGG (ORCPT ); Sun, 4 Nov 2012 20:06:06 -0500 Received: from mail-pa0-f46.google.com ([209.85.220.46]:61410 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750954Ab2KEBGB (ORCPT ); Sun, 4 Nov 2012 20:06:01 -0500 MIME-Version: 1.0 In-Reply-To: References: <50924DA3.1060901@ti.com> <20121101110418.GF410@arwen.pp.htv.fi> <3AF5A6FC-61D9-40CA-85B3-81C2C788CB76@antoniou-consulting.com> <20121101124025.GA12489@arwen.pp.htv.fi> <20121101131609.GC12489@arwen.pp.htv.fi> <20121101135148.382aec00@pyramind.ukuu.org.uk> <9F25E89E-9194-4725-8A8C-053DCBADA1DB@antoniou-consulting.com> <20121101220518.GE14982@arwen.pp.htv.fi> <20121102112104.4657fb7b@pyramind.ukuu.org.uk> From: Grant Likely Date: Mon, 5 Nov 2012 01:05:39 +0000 X-Google-Sender-Auth: oTZJ0g0XrUM_qYiKId77_SGMy0A Message-ID: Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2 To: Jason Kridner Cc: Alan Cox , Russ Dill , balbi@ti.com, Pantelis Antoniou , "Cousson, Benoit" , Tony Lindgren , linux-kernel@vger.kernel.org, Koen Kooi , Matt Porter , linux-omap@vger.kernel.org, Kevin Hilman , Paul Walmsley Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1587 Lines: 31 On Fri, Nov 2, 2012 at 4:07 PM, Jason Kridner 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/