Age | Commit message (Collapse) | Author |
|
Pointed out by LLVM.
ok kettenis@
|
|
|
|
but the value passed forward throughout the ioctl handler otherwise is an
unsigned value.
Pointed out by LLVM.
bktr_core.c:1737:13: error: comparison of unsigned expression < 0 is always false
bktr_core.c:1779:13: error: comparison of unsigned expression < 0 is always false
bktr_core.c:2063:16: error: comparison of unsigned expression < 0 is always false
ok krw@
|
|
ok deraadt@
|
|
from linux 3.8.13
|
|
from linux 3.8.13
|
|
from linux 3.8.13
|
|
from linux 3.8.13
|
|
from linux 3.8.13
this does not currently do the ipi to run wbinvd() on all processors
|
|
from linux 3.8.13
|
|
from linux 3.8.13
|
|
from linux 3.8.13
|
|
tc_frequency is unsigned
ok kettenis@
|
|
noticed by Alexey Suslikov
|
|
|
|
There is no reason to use IPL_VM and it breaks with the recent
IPL_MPSAFE changes.
discussed with kettenis@
|
|
Disable that code and use the write-only rasops code instead on the affected
chips.
|
|
Pointed out by LLVM.
bktr_os.c:478:22: error: comparison of unsigned expression < 0 is always false
ok krw@ kettenis@
|
|
Pointed out by LLVM.
drm_irq.c:154:10: error: comparison of unsigned expression < 0 is always false
kettenis@ says it should be signed and this is what the equivalent Linux code does.
ok jsg@
|
|
properly updated by the newer hardware (seen in the TX completion case).
This leads to very poor transmit performance in the beginning of a TCP
connection. Linux and FreeBSD don't rely on BGE_STATFLAG_UPDATED bit
since they enable MSI and tagged status for 5717+. Doing the same does
indeed fix an issue.
Change was tested by David Imhoff on 5719, 5720 and 5721/5750, Hrvoje
Popovski on 5704 B0, sthen@ on 5723/5784, benno@ on 5704 A3, and
me on 5719, 5720 adn 5714/5715. No objections from kettenis@ and dlg@.
|
|
handled within sis_miibus_statchg() instead of calling
sis_init().
Based on the FreeBSD sis(4) driver.
ok mikeb@ sthen@
|
|
ifconfig done by a user won't alter our negotiated flow control settings.
Both problems were identified by David Imhoff <dimhoff_devel @ xs4all !nl>
Tested by David on 5719, 5720, 5721, Hrvoje Popovski on 5704 B0, sthen@ on
5723/5784, naddy@ and jmatthew@ on 5702/5703, benno@ on 5704 A3 and me on
5715 and 5719.
|
|
Pointed out by LLVM.
ok ratchov@
|
|
|
|
|
|
Reported by naddy@
|
|
structure rather than doing various M_WAITOK allocations during
the *attach() functions, we always rely on them anyway.
ok mikeb@, uebayasi@
|
|
"struct uvm_object" gets defined on macppc as well.
ok miod@, deraadt@
|
|
adds definitions needed to compile recent versions of libdrm
|
|
needed to compile recent versions of libdrm
|
|
|
|
|
|
ok mpi@ kettenis@
|
|
|
|
ok deraadt
|
|
This fixes things up to better match Linux 3.8.x, which we're currently
tracking. No functional change.
|
|
descriptors.
No binary change.
|
|
|
|
o OpenBSD'ify the vmx(4) receive filter handling code
o IFF_ALLMULTI is like hte OACTIVE flag in that its only ever set and
cleared by an interface driver. with that in mind, this reorders
the config to do that and take advantage of it to conditionally
configure the multicast filtering.
o It also makes the code check if any multicast ranges have been
configured, which every other driver interprets as "set ALLMULTI",
so we do too now.
o Add the usual ifdef INET guard to the ioctl code.
OK yasuoka@ dlg@
|
|
responsible for allocating and freeing them. This is what Linux has been
doing for a while now, and will be needed for radeondrm(4) in the near
future.
|
|
ok otto
|
|
- fixup the Random Backoff Register value masking;
- keep the GPIO settings when modifying the Misc Local Control
register value.
Tested by Rob Sessink on 5719, David Imhoff on 5719, 5720, 5721,
me on 5719 and 5715; ok dlg
|
|
ok yasuoka@
|
|
|
|
|
|
ok jsg
|
|
taken care of by pci_mapreg_map().
Ok yasuoka@ uebayasi@
|
|
DRM_I915_GEM_MMAP and DRM_I915_GEM_MMAP_GTT ioctls to be compatible with
Linux. This also is the first step that moves us away from accessing all
graphics memory through the GTT, which should make things faster.
ok tedu@ (for the uvm bits)
|
|
and match the same pci devices Linux does. Untested for lack of
hardware but should work. Note that 3D/OpenGL won't work until
we update to a newer version of Mesa, which can't happen until
the Radeon KMS work is ready.
ok deraadt@
|
|
|