mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu
To: David Woodhouse <dwmw2@infradead.org>
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, jonathan@jonmasters.org,
	Shaohua Li <shaohua.li@intel.com>,
	greg@kroah.com, Kay Sievers <kay.sievers@vrfy.org>,
	arjan@infradead.org
Subject: Re: Intel Microcode loader, tg3 driver, and the -rc8-mmotd New World Order firmware...
Date: Thu, 03 Jul 2008 09:48:56 -0400	[thread overview]
Message-ID: <76161.1215092936@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Thu, 03 Jul 2008 13:21:35 BST." <1215087695.10393.538.camel@pmac.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]

On Thu, 03 Jul 2008 13:21:35 BST, David Woodhouse said:
> On Thu, 2008-07-03 at 07:34 -0400, Valdis.Kletnieks@vt.edu wrote:
> > Actually, FIRMWARE_IN_KERNEL *did* make a difference - it busticated the tg
3
> > driver and while fighting with the 'firmware: requesting tigon/tg3_tso.bin'
> > errors I had just inflicted on myself, 
> 
> Just to confirm: that works either with CONFIG_FIRMWARE_IN_KERNEL=y or
> if you run 'make INSTALL_FW_PATH=/lib/firmware firmware_install', right?

The old config was FIRMWARE_IN_KERNEL=y, and that worked fine because the
microcode was compiled into tg3.o and All Was Good.

My current, *also* working config has FIRMWARE_IN_KERNEL=n, and CONFIG_TIGON3=m.
System comes up, initrd runs, the real root gets loaded, udev gets started,
and when the modprobe happens, /lib/firmware/tigon is there to handle the
request_firmware that gets launched when the module loads.

The *broken* config was FIRMWARE_IN_KERNEL=n, CONFIG_TIGON3=y.  System comes up,
the request_firmware pops *very* early (as in while we're still on the initrd),
and I couldn't figure out how to get Fedora/nash/etc to do the firmware load
from the initrd (nash seems to want it in /firmware/tigon3, but putting it
there didn't help any).  By the time udev gets launched, that request is DOA
and the interface doesn't come up.  But as I said, that *seems* to be just a
lack of clue on my part about what nash wants.

> I'm not entirely sure whether we should make 'make firmware_install'
> install to /lib/firmware by default, or to $(O)/usr/lib/firmware as it
> does at the moment.
> 
> The former is consistent with 'make modules_install', and the latter is
> consistent with 'make headers_install'. Both of which have good reasons
> for being the way they are.

Somebody else can decide that one.  Kay does make a point in another mail
that you *really* want it to end up in /lib/firmware for good reasons.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

  parent reply	other threads:[~2008-07-03 13:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-03  1:32 Valdis.Kletnieks
2008-07-03  1:43 ` Andrew Morton
2008-07-03  6:17 ` Tigran Aivazian
2008-07-03  6:35   ` Valdis.Kletnieks
2008-07-03  6:44     ` Tigran Aivazian
2008-07-03  9:23       ` David Woodhouse
2008-07-03 10:17         ` Valdis.Kletnieks
2008-07-03 10:30           ` David Woodhouse
2008-07-03 11:34             ` Valdis.Kletnieks
2008-07-03 12:21               ` David Woodhouse
2008-07-03 12:41                 ` Kay Sievers
2008-07-03 12:45                   ` David Woodhouse
2008-07-03 13:03                     ` Kay Sievers
2008-07-03 13:26                       ` David Woodhouse
2008-07-03 13:54                       ` Valdis.Kletnieks
2008-07-03 15:23                         ` David Woodhouse
2008-07-03 13:48                 ` Valdis.Kletnieks [this message]
2008-07-03 10:22         ` Kay Sievers
2008-07-03 10:42           ` David Woodhouse
2008-07-03 11:32             ` Kay Sievers
2008-07-03  9:24       ` Giacomo A. Catenazzi
2008-07-03 13:56         ` Arjan van de Ven
2008-07-03 15:54           ` David Woodhouse
2008-07-03 16:22             ` Giacomo A. Catenazzi

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=76161.1215092936@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=dwmw2@infradead.org \
    --cc=greg@kroah.com \
    --cc=jonathan@jonmasters.org \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    --cc=tigran@aivazian.fsnet.co.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®