On 8/10/07, Javier Pello <[EMAIL PROTECTED]> wrote:
> On Thu 09 Aug 2007, Kay Sievers wrote:
>
> > On Thu, 2007-08-09 at 11:36 +0200, Javier Pello wrote:
> >
> > > Anyway, my point is that it is useless to have the kernel block for
> > > a minute at boot waiting for something that cannot happen, an
On Thu 09 Aug 2007, Kay Sievers wrote:
> On Thu, 2007-08-09 at 11:36 +0200, Javier Pello wrote:
>
> > Anyway, my point is that it is useless to have the kernel block for
> > a minute at boot waiting for something that cannot happen, and that
> > it should be avoided (even if my proposed solution
On Thu, 2007-08-09 at 11:36 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Cornelia Huck wrote:
>
> > So it is indeed that this driver wants to fail its probe if it
> > cannot get the firmware.
>
> That's right. The driver unbinds itself from the device if it doesn't
> get the firmware.
>
> >
On Tue, 07 Aug 2007, Cornelia Huck wrote:
> So it is indeed that this driver wants to fail its probe if it
> cannot get the firmware.
That's right. The driver unbinds itself from the device if it doesn't
get the firmware.
> A possibilty to achieve a similar effect would be to use
> request_firmw
On Thu, 09 Aug 2007 11:13:12 +0200,
Javier Pello <[EMAIL PROTECTED]> wrote:
> On Tue, 07 Aug 2007, Kay Sievers wrote:
> > Nope, you would just fulfill in a completely generic way all outstanding
> > requests when you are ready. All requests are all nicely grouped and
> > visible in sysfs. There wo
On Thu, 2007-08-09 at 11:13 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Kay Sievers wrote:
> > Nope, you would just fulfill in a completely generic way all outstanding
> > requests when you are ready. All requests are all nicely grouped and
> > visible in sysfs. There would be no need of codi
On Tue, 07 Aug 2007, Kay Sievers wrote:
> Nope, you would just fulfill in a completely generic way all outstanding
> requests when you are ready. All requests are all nicely grouped and
> visible in sysfs. There would be no need of coding your own device
> specific rebind. No timeout is needed or w
On Fri, 03 Aug 2007 21:07:35 +0200
Javier Pello <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have prepared a patch that makes request_firmware skip the usual
> grace period that it gives firmware images to show up, if it determines
> that userspace was not notified at all.
>
> When request_firmware is
On Tue, 07 Aug 2007 16:08:25 +0200,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> Nope, you would just fulfill in a completely generic way all outstanding
> requests when you are ready. All requests are all nicely grouped and
> visible in sysfs. There would be no need of coding your own device
> specif
On Tue, 07 Aug 2007 15:59:38 +0200,
Javier Pello <[EMAIL PROTECTED]> wrote:
> On Tue, 07 Aug 2007, Kay Sievers wrote:
>
> > If you don't have modules and the initial request fails, how do you
> > load the firmware later?
>
> I trigger a rebinding of the device to the driver in an init file:
> #
On Tue, 2007-08-07 at 15:59 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Kay Sievers wrote:
>
> > If you don't have modules and the initial request fails, how do you
> > load the firmware later?
>
> I trigger a rebinding of the device to the driver in an init file:
> # echo -n [device] >/sy
On Tue, 07 Aug 2007, Kay Sievers wrote:
> If you don't have modules and the initial request fails, how do you
> load the firmware later?
I trigger a rebinding of the device to the driver in an init file:
# echo -n [device] >/sys/.../bind
> The real fix would be to change the driver not to block
On Tue, 07 Aug 2007 14:57:52 +0200,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> The real fix would be to change the driver not to block in the firmware
> request and use async version of firmware loading.
I guess some drivers want to fail the probe if they can't get the
firmware. This sounds like th
On Tue, 2007-08-07 at 14:47 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Cornelia Huck wrote:
>
> > On Tue, 7 Aug 2007 13:46:55 +0200,
> > "Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > > How do you check if events have been "handled"? None of the recent
> > > distros uses /sbin/hotplug anymor
On Tue, 7 Aug 2007 14:31:34 +0200,
"Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > > How do you check if events have been "handled"? None of the recent
> > > distros uses /sbin/hotplug anymore. Netlink events are broadcasted,
> > > but no failure in delivery doesn't mean anything like "handled", or
>
On Tue, 07 Aug 2007, Cornelia Huck wrote:
> On Tue, 7 Aug 2007 13:46:55 +0200,
> "Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > How do you check if events have been "handled"? None of the recent
> > distros uses /sbin/hotplug anymore. Netlink events are broadcasted,
> > but no failure in delivery do
On 8/7/07, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Aug 2007 13:46:55 +0200,
> "Kay Sievers" <[EMAIL PROTECTED]> wrote:
>
> > > - Use an extra parameter in which successful delivery can be indicated.
> > > Make this
> > > int kobject_uevent_env_check(struct kobject *kobject,
> > >
On Tue, 7 Aug 2007 13:46:55 +0200,
"Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > - Use an extra parameter in which successful delivery can be indicated.
> > Make this
> > int kobject_uevent_env_check(struct kobject *kobject,
> > enum kobject_action action,
> >
On 8/7/07, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Mon, 06 Aug 2007 22:23:07 +0200,
> Javier Pello <[EMAIL PROTECTED]> wrote:
>
> > > > 2. The second part changes _request_firmware in
> > > > drivers/base/firmware_class.c to actually check the return value
> > > > of kobject_uevent and skip t
On Mon, 06 Aug 2007 22:23:07 +0200,
Javier Pello <[EMAIL PROTECTED]> wrote:
> > > 2. The second part changes _request_firmware in
> > > drivers/base/firmware_class.c to actually check the return value
> > > of kobject_uevent and skip the loading_timeout delay if the
> > > loading event was not del
On Mon, 06 Aug 2007, Cornelia Huck wrote:
> > 1. The first part changes kobject_uevent_env in lib/kobject_uevent.c
> > to report a failure if both netlink_broadcast (if applicable) and
> > call_usermodehelper fail to send the event to userspace. Nothing
> > in the kernel seems to care about the ret
On Fri, 03 Aug 2007 21:07:35 +0200,
Javier Pello <[EMAIL PROTECTED]> wrote:
> 1. The first part changes kobject_uevent_env in lib/kobject_uevent.c
> to report a failure if both netlink_broadcast (if applicable) and
> call_usermodehelper fail to send the event to userspace. Nothing in
> the kernel
On Sat, 4 Aug 2007, David Lang wrote:
> what I've been told is that with the drive built-in instead of
> modular you can create a filesystem that has only the firmware
> on it, nothing else, and have the kernel find and load it (no
> userspace software involved)
I'm afraid my understanding of the
On Sat, 4 Aug 2007, Javier Pello wrote:
I've been told that it's possible to have the kernel pull the firmware
off of an initrd (or was it initramfs, I keep confusing the two) without
having any userspace, just put the right file in the right place
(unfortunantly I've never gotten around to test
> I've been told that it's possible to have the kernel pull the firmware
> off of an initrd (or was it initramfs, I keep confusing the two) without
> having any userspace, just put the right file in the right place
> (unfortunantly I've never gotten around to testing this) will this patch
> break t
On Fri, 3 Aug 2007, Javier Pello wrote:
Hi,
I have prepared a patch that makes request_firmware skip the usual
grace period that it gives firmware images to show up, if it determines
that userspace was not notified at all.
When request_firmware is called, it sends an event to userspace to
ask
Hi,
I have prepared a patch that makes request_firmware skip the usual
grace period that it gives firmware images to show up, if it determines
that userspace was not notified at all.
When request_firmware is called, it sends an event to userspace to
ask for the firmware image that is needed, and
27 matches
Mail list logo
