allows my 3com cards to work again. It appears that this code was
once there, but I removed it when I added the alignment issues.
MFC After: 5 days
PR: 70639 (and likely others)
o Implement a shiny new algorithm to keep track of finger movement at
slow speeds. This dramatically reduces the level of questionable
language from users trying to resize windows.
o Properly catch the many extra buttons and dials which manufacturers
are known to screw onto Synaptics touchpad controllers. Currently,
up to seven buttons are known to work, more should work too.
o Add a number of sysctls allowing one to tune the driver to taste in
a simple way:
# Should the extra buttons act as axes or as middle button
hw.psm.synaptics.directional_scrolls
# These control the 'stickiness' at low speeds
hw.psm.synaptics.low_speed_threshold
hw.psm.synaptics.min_movement
hw.psm.synaptics.squelch_level
PR: kern/75725
Submitted by: Jason Kuri <jay@oneway.com>
MFC after: 1 month
fe1: <EAGLE Technology NE200 ETHERNET LAN MBH10302 04>
As reported by Sean Shapira. This appears to be working. Eagle used
Fujitsu's vendor number, with a product number of 4 (which is the same
as the vendor number, which is a little suspect). Since there's no
apparent conflict, go ahead and use it.
Submitted by: Sean Shapira
card, and works with that driver. However, Eagle is using Fujitsu's
vendor number and a product code of 4, which seems a little odd.
Still, there's no conflicts...
1/ doesn't matter on most of our architectures
2/ will never happen unless we start queueing multiple trasactions
to a single endpoint at one time (which we do not allow yet).
If anyone has a big_endian machine with EHCI they might check this
if they are having problems with EHCI but it's unlikely even there..
Submitted by: Hans Petter Selasky <hselasky@c2i.net>
MFC after: 3 days
turns out that LINE30_ROW was always defined, not LINE30. I confused
this for LINE30 and did the unifdef -DLINE30 using that mistaken
belief. This corrects that problem.
Submitted by: nyan-san
won't exist for EBus. Just fail the allocation by returning NULL.
Now drivers that are MI can try resources that the driver knows may
be used by the device.
structures in IPX/SPX -- primarily, sequence numbering, PCB lists,
and PCBs for IPX raw sockets, IPX datagram sockets, and IPX/SPX.
As such, remove remove NET_NEEDS_GIANT() for IPX, and remove the
assertion of Giant in the ipxintr() IPX input path.
Note that IPX/SPX is not fully MPSAFE, and that there are some
problems with IPX/SPX locking that will require some further work.
However, it is now safe enough to run in general without the Giant
lock.
MFC after: 4 weeks
portion of IPX/SPX:
- Protect IPX PCB lists with the IPX PCB list mutex, in particular
when calling PCB and PCB list manipulation routines in ipx_pcb.c.
- Protect both IPX PCB state and SPX PCB state using the IPX PCB
mutex.
- Generally annotate locking, as well as adding liberal use of lock
assertions to document locking requirements.
- Where possible, use unlocked reads when reading integer or smaller
sized socket options on SPX sockets.
- De-spl throughout.
Notes:
- spx_input() expects both the list mutex and PCB mutex to be held
on entry, but will release both on return. Because sonewconn() is
called from spx_input(), it may actually drop one PCB lock and
acquire another during generation of a new connection, meaning the
caller is not in a position to unlock the PCB mutex.
MFC after: 3 weeks
were derived from more complex TCP versions of the same:
- spx_close(), spx_disconnect(), spx_drop(), and spx_usrclosed() all
always free's the spxpcb invalidating the argument, so a return
value is not required to indicate if it has.
- Annotate that the cb arguments to each of these functions is
invalidated via a comment.
- When tearing down a pcb due to sonewconn() having failed, mark the
cb as NULL; later, when deciding whether to store trace information
due to SO_DEBUG, check that cb is not NULL before dereferencing or
a NULL pointer dereference may occur.
MFC after: 3 weeks
When processing socket options against IPX PCBs, generally protect
PCB fields using the IPX PCB mutex. Where possible, use unlocked
reads on integer values to avoid locking overhead.
MFC after: 3 weeks
protocol methods relating to IPX. Conditionally acquire the PCB list
lock in the send operation only if the socket requires binding in order
to use the requested address.
Remove spl's generally no longer required during these accesses.
MFC after: 3 weeks
the IPX-related PCB routines. In general, the list lock is required
to iterate the PCB list, either for read or write; the PCB lock is
required to access or modify a PCB. To change the binding of a PCB,
both locks must be held.
MFC after: 3 weeks
IPX PCB lists. Add macros to initialize, destroy, lock, unlock,
and assert the mutex. Initialize the mutex when IPX is started.
Add per-IPX PCB mutexes, ipxp_mtx in struct ipxpcb, to protect
per-PCB IPX/SPX state. Add macros to initialize, destroy, lock,
unlock, and assert the mutex. Initialize the mutex when a new
PCB is allocated; destroy it when the PCB is free'd.
MFC after: 2 weeks
copyright/license header and was only used by 30line.h. It appears
that the copyright/license in 30line.h covers the old contents
module.h anyway, so this simplifies things a little while cleaning up
one obscure potential license confusion...
Revired by: nyan-san
- Introduce another ng_ether(4) callback ng_ether_link_state_p, which
is called from if_link_state_change(), every time link is changed.
- In ng_ether_link_state() send netgraph control message notifying
of link state change to a node connected to "lower" hook.
Reviewed by: sam
MFC after: 2 weeks
place device objects in \ (in this case, PCI links.) Work around this by
starting our probe from \. To avoid attaching system scope objects,
explicitly skip them. (I think it's an ACPI-CA bug that \_SB and \_TZ have
device and thermal object types.) Thanks to pjd@ for testing.
MFC after: 2 weeks
before deciding to do more expensive locking to account for process
exit. This acceptable minor race avoids two mutex operations in
that highly common case of accounting not being enabled.
MFC after: 2 weeks
