summaryrefslogtreecommitdiffstats
path: root/sys/kern/subr_firmware.c
Commit message (Collapse)AuthorAgeFilesLines
* Bump up the firmware_table from 30 to 50. bwn needs more than 30, itimp2010-03-071-1/+1
| | | | seems.
* Remove extraneous semicolons, no functional changes.mbr2010-01-071-1/+1
| | | | | Submitted by: Marc Balmer <marc@msys.ch> MFC after: 1 week
* Use NULL in preference to 0 for pointers.imp2009-02-031-1/+1
|
* Avoid scheduling firmware taskqs when cold.gallatin2008-11-111-3/+7
| | | | | | | | | | | This prevents a panic which occurs when a driver attempts to load firmware at boot via firmware_get() when the firmware module has not been preloaded. firmware_get() will enqueue a task using a struct taskqueue allocated on the stack, and the machine will crash much later in the firmware taskq thread when taskqs are started and the struct taskqueue is garbage. Not objected to by: sam
* dynamically allocate the task structure in firmware_mountroot: whensam2008-10-041-4/+10
| | | | | | | | | booting from an MFS root (e.g. from an install CD) firmware_mountroot can be called twice with the second call happening before the task callback occurs; this results in the task structure contents being corrupted because it was declared static. Submitted by: marius (original version)
* Do image loading in a context known to have a root directory:sam2008-04-091-23/+121
| | | | | | | | | | | | | | | o create a private task queue thread that sets up root and current directories (hooking mountroot event as needed); this is necessary because task queue threads are parented from proc0 and it does not have a reference to rootvnode (lost when / mounting moved to init) o bounce image load + unload requests through the private task q so we can load images even when the request is made from a thread that does not have sufficient context (e.g. task q thread) o add a check in the task q thread to fail requests before root is mounted (just in case) Reviewed by: jhb, mlaier, luigi (glance) MFC after: 1 month
* Cleanup and document the implementation of firmware(9) based onluigi2007-02-151-153/+272
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a version that i posted earlier on the -current mailing list, and subsequent feedback received. The core of the change is just in sys/firmware.h and kern/subr_firmware.c, while other files are just adaptation of the clients to the ABI change (const-ification of some parameters and hiding of internal info, so this is fully compatible at the binary level). In detail: - reduce the amount of information exported to clients in struct firmware, and constify the pointer; - internally, document and simplify the implementation of the various functions, and make sure error conditions are dealt with properly. The diffs are large, but the code is really straightforward now (i hope). Note also that there is a subtle issue with the implementation of firmware_register(): currently, as in the previous version, we just store a reference to the 'imagename' argument, but we should rather copy it because there is no guarantee that this is a static string. I realised this while testing this code, but i prefer to fix it in a later commit -- there is no regression with respect to the past. Note, too, that the version in RELENG_6 has various bugs including missing locks around the module release calls, mishandling of modules loaded by /boot/loader, and so on, so an MFC is absolutely necessary there. I was just postponing it until this cleanup to avoid doing things twice. MFC after: 1 week
* Add a small informative printf under bootverbose to firmware_register tomlaier2007-02-031-0/+5
| | | | track problems when loading firmware from loader.
* In case we are supplied with an imagename that matches a module, but not amlaier2007-01-271-0/+1
| | | | | | | | firmware in that module (eventhough this is a programming error) - drop the reference to the module again. Submitted by: Benjamin Close MFC after: 3 days
* Sweep kernel replacing suser(9) calls with priv(9) calls, assigningrwatson2006-11-061-1/+3
| | | | | | | | | | | | | specific privilege names to a broad range of privileges. These may require some future tweaking. Sponsored by: nCircle Network Security, Inc. Obtained from: TrustedBSD Project Discussed on: arch@ Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri, Alex Lyashkov <umka at sevcity dot net>, Skip Ford <skip dot ford at verizon dot net>, Antoine Brodin <antoine dot brodin at laposte dot net>
* If linker_release_module() fails then we still hold a reference oniedowse2006-06-251-2/+12
| | | | | the linker_file, so record this by restoring the linker_file pointer in fp->file.
* - Push Giant down into linker_reference_module().jhb2006-06-201-3/+1
| | | | | | | | - Add a new function linker_release_module() as a more intuitive complement to linker_reference_module() that wraps linker_file_unload(). linker_release_module() can either take the module name and version info passed to linker_reference_module() or it can accept the linker file object returned by linker_reference_module().
* A couple of minor style tweaks.jhb2006-06-131-2/+4
|
* Keep firmware images on the list until they have been unregisterediedowse2006-06-101-19/+35
| | | | | | | | | | | | | with firmware_unregister(). Previously when the last driver reference had been dropped we would clear the list entry under the assumption that the firmware module was about to be unloaded, but this was not true if the firmware image had been loaded manually with kldload. This makes it possible to manually kldload firmware images as a workaround for drivers such as ipw that attempt to load firmware while resuming after a suspend. Reviewed by: mlaier (an earlier version of the patch)
* firmware(9) is a subsystem to load binary data into the kernel via amlaier2006-01-291-0/+270
specially crafted module. There are several handrolled sollutions to this problem in the tree already which will be replaced with this. They include iwi(4), ipw(4), ispfw(4) and digi(4). No objection from: arch MFC after: 2 weeks X-MFC after: some drivers have been converted
OpenPOWER on IntegriCloud