UDEV - DRIVER parameter

UDEV - DRIVER parameter

[Lee Jones]

Very quick one for you.

How do you raise the DRIVER parameter from the kernel?

When I register the device the following is produced:

KERNEL[946692859.898376] add      /devices/platform/**** (platform)
UDEV_LOG=3
ACTION­d
DEVPATH=/devices/platform/****
SUBSYSTEM=platform
MODALIAS=platform:****
SEQNUMs5

But I need the DRIVER parameter, i.e:
DRIVER=****

Kind regards,
Lee

Re: UDEV - DRIVER parameter

[Kay Sievers]

On Tue, Jul 6, 2010 at 12:29, Lee Jones <lee.jones@canonical.com> wrote:
> How do you raise the DRIVER parameter from the kernel?
>
> When I register the device the following is produced:
>
> KERNEL[946692859.898376] add      /devices/platform/**** (platform)
> UDEV_LOG=3
> ACTION­d
> DEVPATH=/devices/platform/****
> SUBSYSTEM=platform
> MODALIAS=platform:****
> SEQNUMs5
>
> But I need the DRIVER parameter, i.e:
> DRIVER=****

Only some devices have a driver bound. Only "bus" devices, "class"
devices never have a driver.

It's just the symlink "driver" in /sys in the device directory.

Your platform device may just be a plain registered device, and not
probed and bound by a driver in that sense. Usually only enumeratable
buses have drivers that create devices when they are discovered.

Kay

Re: UDEV - DRIVER parameter

[Lee Jones]

> Only some devices have a driver bound. Only "bus" devices, "class"
> devices never have a driver.
> 
> It's just the symlink "driver" in /sys in the device directory.
> 
> Your platform device may just be a plain registered device, and not
> probed and bound by a driver in that sense. Usually only enumeratable
> buses have drivers that create devices when they are discovered.

I guess I'd better tell you the full story then.

I am working on a driver (module) that provides a direct link "CPU <-> Video Codec", which I believe is non-discoverable. 

I figured that I'd be able to send the uevent by registering the device as a platform one in architecture specific code.

A uevent is sent, but it is missing the DRIVER parameter.

This is the generic parameter which is used in the udev rules.

/lib/udev/rules.d/80-drivers.rules, DRIVER!="?*", ENV{MODALIAS}="?*", RUN+="/sbin/modprobe -b $env{MODALIAS}"

I want to shy away from sending another rule upstream.

Are there any other sensible alternatives? 

Kind regards,
Lee

Re: UDEV - DRIVER parameter

[Kay Sievers]

On Tue, Jul 6, 2010 at 13:28, Lee Jones <lee.jones@canonical.com> wrote:
>> Only some devices have a driver bound. Only "bus" devices, "class"
>> devices never have a driver.
>>
>> It's just the symlink "driver" in /sys in the device directory.
>>
>> Your platform device may just be a plain registered device, and not
>> probed and bound by a driver in that sense. Usually only enumeratable
>> buses have drivers that create devices when they are discovered.
>
> I guess I'd better tell you the full story then.
>
> I am working on a driver (module) that provides a direct link "CPU <-> Video Codec", which I believe is non-discoverable.
>
> I figured that I'd be able to send the uevent by registering the device as a platform one in architecture specific code.
>
> A uevent is sent, but it is missing the DRIVER parameter.
>
> This is the generic parameter which is used in the udev rules.
>
> /lib/udev/rules.d/80-drivers.rules, DRIVER!="?*", ENV{MODALIAS}="?*", RUN+="/sbin/modprobe -b $env{MODALIAS}"

What do you mean? This rule is skipped only if DRIVER is set. This is
to prevent calling modprobe for devices which already have a driver
bound and looking-up and loading another module would not do anything
to this device. If you don't have a driver this rule will always run.
:)

Kay

Re: UDEV - DRIVER parameter

[Lee Jones]

> What do you mean? This rule is skipped only if DRIVER is set. This is
> to prevent calling modprobe for devices which already have a driver
> bound and looking-up and loading another module would not do anything
> to this device. If you don't have a driver this rule will always run.
> :)

It appears I've been led up the garden path, so to speak.

Let me do some more poking around.

Thanks for your help thus far Kay.