From John Nielsen on freebsd-mobile.
Not tested, but almost certainly better than attaching as ugen.
FreeBSD has a UQ_ASSUME_CM_OVER_DATA quirk for this device; I can't
figure out what that means.
an unknown msg_type is received.
* Check the received packet size.
* Use strncpy() instead of strlcpy() so that we don't
send gibberish from the stack.
* No need to bind().
* htons()/htonl() use uint16_t/uint32_t not u_short/u_long.
* Sprinkle const.
* Use EXIT_FAILURE instead of 1.
* Use err(), errx().
* Use calloc() instead of malloc()+memset().
* timedc:
* Non-terminated hostnames or unknown tsp_type could
cause a crash due to out-of-bounds reads in msite().
* Check the received packet size.
* Merged duplicated code into functions.
* Moved variables into the relevant scopes.
* Use connect() so that only the receiver can reply,
send()/recv() can be used and rejected packets
are immediately noticed by recv() instead of causing
timeouts.
* Updated manpage.
Most Cardbus bridges supported by pccbb(4) fire a power-cycle
interrupt when the power state of a cardslot changes from 'off' to
'on'. TI bridges fire a power-cycle interrupt on both on->off and
off->on changes.
When pccbb_power() powered-down a cardslot, it did not wait around
for the power-cycle interrupt. When pccbb_power() powered-up a
cardslot, it did wait for the interrupt. If a pccbb_power(UP)
followed a pccbb_power(DOWN) very closely, pccbb_power() used to
interpret the power-cycle interrupt for the up->down transition as
"power-up complete," read the power-state bit and, finding that
power had NOT been activated, complain, "cbb0: power on failed?"
Then pccbb_power() exited before power-activation was complete,
falsely indicating that the power-activation *was* complete. After
that, a driver attach/enable routine would blithely configure a
card that was not fully powered-up. An operator who ran a command
such as 'ifconfig rtw0 down up' or 'ifconfig ath0 down up' would
read 'cbb0: power on failed?' in the system log, and their NIC
would misbehave.
This excerpt from a comment in the source should suffice to explain
how I fixed the bug,
/*
* Wait as long as 200ms for a power-cycle interrupt. If
* interrupts are enabled, but the socket has already
* changed to the desired status, keep waiting for the
* interrupt. "Consuming" the interrupt in this way keeps
* the interrupt from prematurely waking some subsequent
* pccbb_power call.
And this explains why this patch will work for Ricoh bridges that
do not fire an interrupt on the on->off transition:
* XXX Not every bridge interrupts on the ->OFF transition.
* XXX That's ok, we will time-out after 200ms.
*
* XXX The power cycle event will never happen when attaching
* XXX a 16-bit card. That's ok, we will time-out after
* XXX 200ms.
*/
M. Warner Losh and Charles M. Hannum provided valuable input on
this patch.
and also include files don't have mismatched .if/.endif
It has been suggested that make used to have this test, but I can't
remember removing any code that might have performed it.
- don't use SAVESTART in calls to relookup() from unionfs,
just vref() the desired vnode when we need to.
- fix locking and refcounting in the unionfs EEXIST error cases.
- release any vnode locks before calling VFS_ROOT(), vfs_busy() is enough.
this allows us to simplify union_root() and fix PR 3006.
- union_lock() doesn't handle shared lock requests correctly,
so convert them to exclusive instead. fixes PR 34775.
- in relookup(), avoid reusing "dp" for different purposes,
the error handling wasn't right. (actually just get rid of dp.)
also, change relookup() to ignore LOCKLEAF and always return the
vnode locked since the callers already expect this.
returned from nfs_namei() is not locked in this case. fixes PR 35542.
also, apply the same fix here as was made in rename_files() to handle
the case when dvp and vp are the same.
Enabled via per_user_tmp in /etc/rc.conf (default off).
See security(8) and rc.conf(5) for more details.
Lots of input from thorpej@ & christos@, thanks!
via Darrin B.Jewell.
XXX: maybe we should check this sc_rev on more place
- use RTK_TXCFG_HWREV (0x7cc00000) rather than 0x7c800000
to mask the hwrev value since bit 0x00400000 is used only by 8139D
which is not supported by this driver
- fix a tyop
njoly