RFC: prevent auto binding for some platform devices

RFC: prevent auto binding for some platform devices

[Uwe Kleine-König]

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.

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?

Best regards
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

RE: prevent auto binding for some platform devices

[Dasgupta, Romit]

Hi,
    I think with 2.6.18 or so onwards, there are two entries under /sys/bus/<bus_type>/
drivers_autoprobe, drivers_probe. (Here bus_type is platform, usb, pci, etc...)
By default drivers_autoprobe is 1. You need to disable autprobing of the driver by writing a 0 to that entry.
Once you do that you need to write the name of the device that you want the driver to bind to in the drivers_probe entry.

Hope this is useful.

Thanks,
-Romit



>-----Original Message-----
>From: linux-embedded-owner@vger.kernel.org [mailto:linux-embedded-
>owner@vger.kernel.org] On Behalf Of Uwe Kleine-König
>Sent: Monday, July 21, 2008 12:12 PM
>To: linux-embedded@vger.kernel.org
>Subject: RFC: prevent auto binding for some platform devices
>
>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.
>
>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?
>
>Best regards
>Uwe
>
>--
>Uwe Kleine-König, Software Engineer
>Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
>Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
>--
>To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: prevent auto binding for some platform devices

[Uwe Kleine-König]

Hello Romit,

Dasgupta, Romit wrote:
>     I think with 2.6.18 or so onwards, there are two entries under /sys/bus/<bus_type>/
> drivers_autoprobe, drivers_probe. (Here bus_type is platform, usb, pci, etc...)
> By default drivers_autoprobe is 1. You need to disable autprobing of the driver by writing a 0 to that entry.
I saw that, too, but this fails in two ways:  First if the drivers are
compiled in (as usual with an embedded machine) it's too late when
userspace is able to do that because then the drivers are already bound.
(The underlain kernel data is currently not available to platform code.)
And I don't want to stop the whole bus from binding, only the
conflicting devices.

Thanks
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

Re: RFC: prevent auto binding for some platform devices

[Alexey Zaytsev]

Re: RFC: prevent auto binding for some platform devices

[Alexey Zaytsev]

[Sorry, probably a gmail web-interface bug?]

On Mon, Jul 21, 2008 at 10:42 AM, Uwe Kleine-König
<Uwe.Kleine-Koenig@digi.com> 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.
>
> 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?

How about simply not registering the missing devices in your
board setup code?

>
> Best regards
> Uwe
>
> --
> Uwe Kleine-König, Software Engineer
> Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
> Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: RFC: prevent auto binding for some platform devices

[Uwe Kleine-König]

Hello Alexey,

Alexey Zaytsev wrote:
> [Sorry, probably a gmail web-interface bug?]
> 
> On Mon, Jul 21, 2008 at 10:42 AM, Uwe Kleine-König
> <Uwe.Kleine-Koenig@digi.com> 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.
> >
> > 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?
> 
> How about simply not registering the missing devices in your
> board setup code?
They are not missing.  In the a) case above they just conflict and I
want to provide a way to change the default from userspace.  E.g.

	echo "serialdevice.1" > /sys/bus/platform/drivers/serialdriver/unbind
	echo "spidevice.1" > /sys/bus/platform/drivers/spidriver/bind

and for b) I want to be able to enable the led if nothing else is
connected to the line.

Best regards
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

Re: RFC: prevent auto binding for some platform devices

[Ben Nizette]

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@vger.kernel.org/msg00370.html

[2]
http://groups.google.com/group/linux.kernel/browse_thread/thread/f57ac93bd37626eb/587d1302f0f497ad?lnk=raot