yank it's description; likewise for the FIRMWARE_WAIT flag to firmware_put.
For the record, the last commit was to cleanup various mistakes and correct
the example of embedding to reflect the npe firmware now being distributed
with the system.
I've obtained a draft, <u:> is indeed equivalent to u (to my surprise),
and <th> sorts immediately after z.
The correct ordering is algorithmic (based on the EOR) and can not be
accurately represented as a table.
LOCALES list. Since no_NO was still in LOCALES, make tried to build the
corresponding .out files, but couldn't since the .src files were gone. I
did not notice this because I still had the old .out files in my .OBJDIR.
Thanks to kib@ for the heads-up.
makes sense to have them both link to no_NO.
In other cases (such as LC_TIME), they differ, and the correct solution
is to have no_NO link to nb_NO, rather than the other way around.o
MFC after: 2 weeks
and nn_NO, which are symlinked to no_NO.
The patch in the PR contained a number of errors apparently based on
(sometimes incorrect) pronunciation; for instance, v and w are
distinct letters and should be collated in that order, even if they
are pronounced the same, while <u:> should be collated with u, even
though it is often mispronounced as y. For lack of a solid reference,
I have taken sv_SE and simply changed the last three letters of the
alphabet.
PR: conf/51920
MFC after: 2 weeks
describes the minimum versions of each feature and each chipset type
supported by this driver. Basically, unless you have a very modern
version of firmware on a Prism card, you won't be able to use these
cards for much on modern networks that have any kind of protection
enabled, except for the few WEP-only stranglers that appear at some
conferences...
The segfaults when using SSP seem to be a gcc bug, a patch is available
in the gcc bugzilla, and will be imported once it's committed
into the official gcc tree.
MPSAFE patches on current@ and stable@. This driver also has a fundamental
issue in that it sleeps when sending commands to the card including in the
if_init/if_start routines (which can be called from interrupt context). As
such, the driver shouldn't be working reliably even on 4.x.
and stable@. It also is a driver for an older non-802.11 wireless PC card
that is quite slow in comparison to say, wi(4). I know Warner wants this
driver axed as well.
current@ and stable@ for the locking patches. The driver can always be
revived if someone tests it.
This driver also sleeps in its if_init routine, so it likely doesn't really
work at all anyway in modern releases.
