| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
into kernel, unless there is a verbose boot flag set. There is no real
need to have this information printed.
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
Split 4Gb and 8Gb into pieces that can be either multi_id
capable or not.
Reviewed by: scottl, ken
Approved by: re
|
|
|
|
|
|
|
|
|
|
| |
- Do not let individual KLD module unregister firmware image loaded by ispfw
or vice versa.
- Make 'kldunload ispfw' actually unregister all firmware images loaded by
ispfw, not just 'isp_1040'.
- Print which KLD module actually loaded the firmware image.
- Remove unused return value from do_load_fw() and do_unload_fw() and remove
duplicate sys/param.h while I am here.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loading for the QLogic cards.
Because isp(4) exists before the root is mounted, it's not really
possible for us to use the kernel's linker to load modules directly
from disk- that's really too bad.
However, the this is still a net win in in that the firmware has
been split up on a per chip (and in some cases, functionality)
basis, so the amount of stuff loaded *can* be substantially less
than the 1.5MB of firmware images that ispfw now manages. That is,
each specific f/w set is now also built as a module. For example,
QLogic 2322 f/w is built as isp_2322.ko and Initiator/Target 1080
firmware is built as isp_1080_it.ko.
For compatibility purposes (i.e., to perturb folks the least), we
also still build all of the firmware as one ispfw.ko module.
This allows us to let 'ispfw_LOAD' keep on working in existing
loader.conf files. If you now want to strip this down to just
the firmware for your h/w, you can then change loader.conf to
load the f/w you specifically want.
We also still allow for ispfw to be statically built (e.g., for
PAE and sparc64).
Future changes will look at f/w unloading and also role switching
that then uses the kernel linker to load different ips f/w sets.
MFC after: 2 months
|
| |
|
|
|
|
|
| |
update here before we switch to the new f/w loading
framework.
|
| |
|
|
|
|
|
|
| |
in alternate f/w versions that will be pursued at some points.
MFC after: 1 month
|
|
|
|
| |
MFC after: 2 days
|
| |
|
|
|
|
|
|
|
|
| |
for unknown events.
A number of modules return EINVAL in this instance, and I have left
those alone for now and instead taught MOD_QUIESCE to accept this
as "didn't do anything".
|
| |
|
|
|
|
| |
Reported by: Daniel O'Connor <doconnor@gsoft.com.au>
|
|
|
|
| |
less) latest from QLogic.
|
|
|
|
| |
Also some minor style cleanups.
|
| |
|
|
|
|
| |
MFC after: 0 days
|
|
|
|
|
|
| |
of buglets and quite a few bugs.
MFC after: 1 day
|
|
|
|
|
|
| |
2300 cards.
MFC after: 1 day
|
| |
|
| |
|
|
|
|
| |
MFC after: 1 day
|
|
|
|
|
|
| |
bugs.
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(obtained from phk@freebsd.org)
|
|
|
|
|
|
|
| |
non-disconnecting command. Interestingly enough, of the other flavors
of the 7.65 f/w (the dual-id and multi-id flavor)- the dual-id doesn't
hang (they're also supposed to be the same except for supporting dual
or multi-id capture!), but other things are questionable as well.
|
|
|
|
| |
mode enabled or not now (like the FC cards).
|
| |
|
| |
|
| |
|
|
loadable module.
|