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
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 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
>
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
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
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
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, 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
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 doesn't mean
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 in
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
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 return
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
> 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
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 this
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
am not subscribed to the list.
==
From: Javier Pello <[EMAIL PROTECTED]>
kobject_uevent: return an error if event was not delivered to userspace
Make kobject_uevent_env return an error to the caller if the event was
not delivered to userspace either via netlink or via uevent_
am not subscribed to the list.
==
From: Javier Pello [EMAIL PROTECTED]
kobject_uevent: return an error if event was not delivered to userspace
Make kobject_uevent_env return an error to the caller if the event was
not delivered to userspace either via netlink or via uevent_helper.
Signed
18 matches
Mail list logo
