[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1399047974.24523.16.camel@deadeye.wl.decadent.org.uk>
Date: Fri, 02 May 2014 17:26:14 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: Michael Chan <mchan@...adcom.com>
Cc: "Magnos A. Hammes" <magnos@...hos.com.br>, netdev@...r.kernel.org,
"desenvolvimento@...hos.com.br" <desenvolvimento@...hos.com.br>
Subject: Re: [PATCH] drivers/net/ethernet/broadcom/bnx2.c
On Thu, 2014-05-01 at 12:32 -0700, Michael Chan wrote:
> On Thu, 2014-05-01 at 15:49 -0300, Magnos A. Hammes wrote:
> > Yes, I have some udev rules that run at system boot, but the only
> > thing
> > I do is:
> >
> > /sbin/udevd --daemon
> > /sbin/udevadm trigger --type=subsystems --action=add
> > /sbin/udevadm trigger --type=devices --action=add
> > /sbin/udevadm settle
> >
> > Udev runs normally and returns no errors or warnings and dmesg shows
> > nothing weird.
> >
> > So, you think this may be a problem with my udev rules or a udev bug?
> >
> > I'm using udev version 182.
>
> udev is involved in locating and loading the firmware file.
It is usually not involved now. The kernel tries to load files directly
from /lib/firmware. Only if that fails and if
CONFIG_FW_LOADER_USER_HELPER is enabled, then it will issue a uevent
which udev may respond to (I think that may have been removed from udev
now).
Ben.
> On my
> system, I have /lib/udev/firmware.sh and a
> generic /lib/udev/rules.d/50-firmware.rules to make request_firmware()
> work. Your system may be different.
--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists