On Mon, 2008-07-21 at 08:42 +0200, Uwe Kleine-König wrote: > Hello, > > I have an emedded machine here on my desk and want to stop some > driver/device pairs from binding. There are two types of reason for it: > > a) pin muxing doesn't allow attaching e.g. spi and serial at the same > time. In this case I want a defined "winner" that doesn't depend > on link (or module load) order. > > b) the devboard has attached an led on a line that is also available > on a header. So I don't want to bind the led driver by default > because there might be another device connected to the gpio line. > Still I want to provide the led device and driver such that > userspace can bind these two via sysfs and use it. > While most boards probably have these decisions make in platform code and compiled in, I certainly see value in being able to keep dev-board owners out of the kernel source. > I think a patch would be easy: > > - add a flag to struct device(?) settable by platform code that would > indicate that the device should not autoprobe. > > - change bus_attach_device to check that flag and only call > device_attach if it's not set. > > Would this be sensible? Would it help anyone else? This would be a good first step but it still requires a source change and recompile if you want to change any device in the boot branch. Anything not in the boot path can be probed later by sysfs interaction which I like. This would solve (most of?) the "deferred module init" problems which have come across this list [1] as well as things like the recent mmc-over-spi-over-gpio-fake-hotplug thing [2]. That said, I don't have any sensible comments on how to implement the below, but my $0.02 would be to go about things a bit differently. I reckon some arch-independent version of FDT kinda thing would be a good way to go. That is, some easy way for the user to specify the whole hardware layout and tell the kernel about it without that tedious mucking about inside kernel source. If not the whole hardware layout (which I guess is quite arch-dependant) then at least the list of devices to probe in a way which allows you to play with the boot devices too (and doesn't need an initramfs). So yes, I reckon it'd help others, certainly a worthy topic for discussion :-D > > Best regards > Uwe > Thanks, --Ben. [1] http://www.mail-archive.com/linux-embedded@xxxxxxxxxxxxxxx/msg00370.html [2] http://groups.google.com/group/linux.kernel/browse_thread/thread/f57ac93bd37626eb/587d1302f0f497ad?lnk=raot -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
