From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jon Smirl <jonsmirl@gmail.com>
Date: Wed, 16 Mar 2005 15:52:06 +0000
Subject: Re: Firmware class breaks udev
Message-Id: <9e47339105031607523a121e13@mail.gmail.com>
List-Id: <linux-hotplug.vger.kernel.org>
References: <42369BE6.7020807@suse.de>
In-Reply-To: <42369BE6.7020807@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
To: linux-hotplug@vger.kernel.org

On Wed, 16 Mar 2005 08:27:38 +0100, Hannes Reinecke <hare@suse.de> wrote:
> Greg KH wrote:
> > On Tue, Mar 15, 2005 at 02:09:17PM +0100, Hannes Reinecke wrote:
> [ .. ]
> >>The main problem is that firmware downloading does not fit in well with
> >>the established functionalities:
> >>
> >>- modprobe returns after the device is fully initialised.
> >>  -> firmware has to be loaded during modprobe, ie events have to
> >>     be handled during modprobe
> >
> > That can be changed, modprobe can return before the device is
> > initialized.  I can change the driver to do this, if you wish.
> >
> Oh, that would be good.
> We should fix the firmware_class / any firmware-dependend device to
> return (ie finish their probing) when the firmware device has been
> registered in sysfs.
> Then we have a chance to handle the firmware event, and on succesful
> downloading the proper device will appear in sysfs. Something like
> - handling pci event
>   -> modprobe <corresponding module>
>      -> generates firmware event
>      -> returns
>   -> event handling done
> - handling firmware event
>   -> download firmware
>   -> device initialisation
>      -> device_register()
>         -> generate class device event
> - handling class device event

Wouldn't the cleanest way to handle this be to have a pre-probe call
to the device structure? In pre-probe you would trigger the
request_initialization_nowait(). Then when user space indicates that
it is done it pokes a sysfs attribute. poking the attrib then causes
the normal probe() function to be called. If pre-probe() is null then
skip all this and call probe().

I'd like to rename everthing request_initialization instead of
firmware. I'd also like to hang the firmware sysfs directory off from
each device node as it is requested instead of having a firmware
subsys. That gets rid of the name conflicts.

BenH definitely wants to kill synchronous request_firmware() because
of suspend/resume issues.

>=20
> >>- hotplug events are sent when the device registers itself with sysfs
> >>  -> devices with firmware will then not be fully initialised
> >>  -> the current hotplug subsystem does not distinguish between
> >>     states 'device detected' and 'device initialised',
> >>     so you can't model the firmware behaviour directly onto
> >>     the linux hotplug subsystem.
> >
> > Kay has a patch for that, which I will add to the tree in a few hours.
> >
> > So, with your udev patch, is there still an immediate problem that needs
> > to be fixed?
> >
> Well, in principle.
> I'd still prefer a proper solution as outlined above.
>=20
> Cheers,
>=20
> Hannes
> --
> Dr. Hannes Reinecke                     hare@suse.de
> SuSE Linux AG                           S390 & zSeries
> Maxfeldstra=DFe 5                         +49 911 74053 688
> 90409 N=FCrnberg                          http://www.suse.de
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&opclick
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
>=20


--=20
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel