Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

["Kay Sievers" <kay.sievers@vrfy.org>]

On 7/9/07, mikie <mikie.pl@gmail.com> wrote:
> 2007/7/9, Indan Zupancic <indan@nul.nu>:
> > On Mon, July 9, 2007 10:49, mikie wrote:
> > > 2007/7/6, Indan Zupancic <indan@nul.nu>:
> > >> On Fri, July 6, 2007 16:20, Duncan Sands wrote:
> > >> > On Friday 6 July 2007 14:54:18 mikie wrote:
> > >> >> Hi,
> > >> >>
> > >> >> I experience some problems with the speedtch.c module, especially in
> > >> >> regards to its firmware loader.
> > >> >> I am not quite sure if this module is going to load the firmware
> > >> >> itself or does it use some external software to do that ?
> > >> >
> > >> > It loads it itself, using some external software!
> > >>
> > >> For information, it generates a hotplug event and the kernel calls the
> > >> program written at /proc/sys/kernel/hotplug with certain information.
> > >> That used to be /sbin/hotplug, became later udev, but today in general
> > >> udev reads the uevents generated by the kernel.
> > >
> > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug.
> > > I copied your script to /sbin/hotplug and also added simple logging,
> > > so I can see whenever the script is being started. It turns out that
> > > the script is not started at all by the kernel...
> > >
> > > I am afraid that the kernel generates uevents only, could this be true?
> >
> > Not really, it would break backward compatibility, and if it were true,
> > they're remove the /proc/sys/kernel/hotplug setting too. As far as I know,
> > if it's set, that program will be executed, and if zero is written to it, only
> > uevents are generated.
> >
> > Make sure that the script is executable (chmod +x)
>
> Yes I have set it to be executable:
> root@srv:/sbin# ls -lah hotplug
> -rwxr-xr-x    1 root     root          934 Jul  9 09:13 hotplug
>
> > and has "#!/bin/sh"
> > at the top, or else it won't work. If that's already the case, I've no idea.
>
> root@srv:/sbin# head hotplug
> #!/bin/sh
> set -e
>
>
> Everything looks OK, but still it does not fire up the script...

It should run, if the kernel creates events. Can you run "udevmonitor
--env" while loading the driver? That way we can see if events are
generated by the kernel (if you don't have it, no need to install
udev, just download the udev tarball, type "make" and run
"./udevmonitor --env").

Kay