I have commited a different version than in the PR, it lacks a license
but if it warrants one we can stick the TNF standard on it. It's just
a main() routine that calls revoke(2).
artificial limitations which really only make it good for use with serial
flash devices. One of the more annoying limitations is a restriction that
it can only transfer 8 bytes at a time. (4 command/address, plus 4 data.)
The driver includes design to work around those limitations, but these
changes are only appropriate for serial flash devices.
This driver is designed to run in interrupt driven mode, but due to lack
of adequate documentation, we run it in polled mode.
A subsequent commit will introduce the MI M25P flash driver, which has been
tested and is known to function somewhat reasonably..
on an Ultra 2 and works fine, apart from formatting which is known
to be broken. It failed to work on an ebus machine. The ebus
support compiles fine, but I don't have hardware for testing. This
code is based on the sparc driver with hints from OpenBSD on how
to do the sbus and ebus attachments, along with help from martin@
and mrg@.
Initial commit approved by martin@
TODO:
- fix ebus support
- fix XXX issues
- check resource deallocation
- fix formatting
- merge remaining differences from sparc driver
- split out back end chip support
- have sparc driver use new common back end chip support
- adapt to newlock when branch is ready
- adapt to "disk-info" property dictionary
always using "function" instead of "macro".
Changed "undefined result" into "undefined behavior" for argument values
outside the valid range. Since the character table is allocated via
malloc(), it _may_ happen that it starts at a page boundary, so that
negative values for the argument result in a segmentation fault. In that
case, there is no result at all.
with spl used to protect other allocations and frees, or datastructure
element insertion and removal, in adjacent code.
It is almost unquestionably the case that some of the spl()/splx() calls
added here are superfluous, but it really seems wrong to see:
s=splfoo();
/* frob data structure */
splx(s);
pool_put(x);
and if we think we need to protect the first operation, then it is hard
to see why we should not think we need to protect the next. "Better
safe than sorry".
It is also almost unquestionably the case that I missed some pool
gets/puts from interrupt context with my strategy for finding these
calls; use of PR_NOWAIT is a strong hint that a pool may be used from
interrupt context but many callers in the kernel pass a "can wait/can't
wait" flag down such that my searches might not have found them. One
notable area that needs to be looked at is pf.
See also:
http://mail-index.netbsd.org/tech-kern/2006/07/19/0003.htmlhttp://mail-index.netbsd.org/tech-kern/2006/07/19/0009.html
