linux-kernel - Re: [PATCH 0/3] capebus moving omap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 5 Nov 2012 01:05:39 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Jason Kridner <jkridner@...gleboard.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Russ Dill <Russ.Dill@...com>,
	balbi@...com, Pantelis Antoniou <panto@...oniou-consulting.com>,
	"Cousson, Benoit" <b-cousson@...com>,
	Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, linux-omap@...r.kernel.org,
	Kevin Hilman <khilman@...com>, Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

On Fri, Nov 2, 2012 at 4:07 PM, Jason Kridner <jkridner@...gleboard.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/