All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: alexey kodanev <alexey.kodanev@oracle.com>
Cc: vasily isaenko <vasily.isaenko@oracle.com>,
	ltp-list@lists.sourceforge.net
Subject: Re: [LTP] [PATCH v2] fw_load: new test of device firmware loading
Date: Mon, 17 Jun 2013 04:50:29 -0400 (EDT)	[thread overview]
Message-ID: <610555826.3622499.1371459029864.JavaMail.root@redhat.com> (raw)
In-Reply-To: <51BECB27.2000104@oracle.com>





----- Original Message -----
> From: "alexey kodanev" <alexey.kodanev@oracle.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp-list@lists.sourceforge.net, "vasily isaenko" <vasily.isaenko@oracle.com>
> Sent: Monday, 17 June, 2013 10:39:03 AM
> Subject: Re: [LTP] [PATCH v2] fw_load: new test of device firmware loading
> 
> 
> On 06/14/2013 07:16 PM, Jan Stancek wrote:
> >
> >>> I ran this on older kernel, which worked fine - it skipped the build.
> >>> Then I tried RHEL7 alpha, which has more recent kernel: 3.10.0-0.rc4,
> >>> but it failed:
> >>>
> >>> # ./fw_load
> >>> cp: cannot stat ‘/lib/udev/rules.d/50-firmware.rules’: No such file or
> >>> directory
> >>> fw_load     1  TBROK  :  Failed to copy
> >>> '/lib/udev/rules.d/50-firmware.rules' to '/etc/udev/rules.d/' at
> >>> fw_load.c:164
> >>> fw_load     2  TBROK  :  Remaining cases broken
> >>> fw_load     0  TWARN  :  tst_rmdir: TESTDIR was NULL; no removal
> >>> attempted
> >>>
> >>> I'll see if I can find out what happened to 50-firmware.rules,
> >>> it could some side-effect of systemd.
> >>>
> >> Would it be better to change failed copy command to just TWARN, and
> >> continue testing? After that, test will completed with udev failed
> >> test-cases, or if udev has those rules in the other configuration files,
> >> everything will be fine.
> > I'd go with TCONF or skip udev testcases if we can't be sure that udev is
> > running
> > and properly configured.
> >
> > I'm also missing firmware.sh, in new udev (now merged with systemd tree),
> > 50-firmware.rules file depends on some compile switch. Even when enabled
> > the rule looks like this:
> > http://cgit.freedesktop.org/systemd/systemd/tree/rules/50-firmware.rules
> >
> > firmware.sh appears to be converted to .c now:
> > http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-firmware.
> I see now, I think it is better to skip udev in the test entirely,
> because there is a tendency
> in kernel community to disable user-mode helper firmware loading (udev).
> It is already guarded with
> CONFIG_FW_LOADER_USER_HELPER option in firmware code: firmware: Make
> user-mode helper optional
> <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b1269f778782d2f42994a74bf4014d0cbebbf9f>.
> There is only one use of it: loading firmware from non-standard path. It
> might also go away as soon as
> configuring paths support had been added to kernel.

I noticed that too, because my udev wasn't getting any events - 
kernel I'm using has that option turned off.

I also came across this article: http://lwn.net/Articles/518942/
which says: "No events for a specific device, they decided,
would be processed until the process of loading the driver module
for that device had completed", but this one could be fixed easily
in fw_load kernel module.

Regards,
Jan

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

      reply	other threads:[~2013-06-17  8:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-14 11:17 [LTP] [PATCH v2] fw_load: new test of device firmware loading Alexey Kodanev
2013-06-14 13:48 ` Jan Stancek
2013-06-14 14:44   ` alexey.kodanev
2013-06-14 15:16     ` Jan Stancek
2013-06-17  8:39       ` alexey.kodanev
2013-06-17  8:50         ` Jan Stancek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=610555826.3622499.1371459029864.JavaMail.root@redhat.com \
    --to=jstancek@redhat.com \
    --cc=alexey.kodanev@oracle.com \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=vasily.isaenko@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.