| Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Tested with 8168G controllers.
|
|
when attached to re(4), as was done before rev 1.25 which was intended to
fix rgephy(4) with external PHY with MACs other than re(4). This is to
fix operation with some integrated PHY on re(4) where the PHY Specific
Status register does not work properly and the link cannot be established.
From FreeBSD and matches what the Linux driver does.
Tested on a number of newer re(4) with PHYs rev 2, 4 and 5 and
newer integrated PHY with the 8168G controllers.
|
|
exception being the BCM5714 family for now.
Tested on a variety of newer chipsets.
ok sthen@
|
|
Fixes audio problems on an Acer Aspire E1 572G
reported by Mark Rowland.
|
|
|
|
|
|
|
|
to match behavior before rev 1.52.
ok deraadt@
|
|
If the driver was doing some IO, we remove the timeouts, and force the
fdc state machine into IOTIMEDOUT state with the final timeout count
before a clean retry. In theory upon resume it should freak out quietly,
and try the operation again.
Noone has stepped forward to test this yet.
|
|
one of these is ever found in a suspend/hibernate system.
|
|
drivers) activate functions at DVACT_RESUME time do not need to do
so, since their PHYs are repaired by IFF_UP.
NOTE: if_msk is the one that previously relied on mii/eephy.c doing
a crazy dance.
|
|
drivers) activate functions at DVACT_RESUME time do not need to do
so, since their PHYs are repaired by IFF_UP.
|
|
configuration setting is done at resume time because all networks
drivers which were previously up, do an IFF_UP operation which
hits PHY_RESET.
This was in snapshots for about 2 weeks.
|
|
attach() and activate() time] into the eephy_reset() routine. This
means that a bit more work gets done at PHY_RESET time, but it means
also means it gets done in all scenarios. Why? For the next commit...
This was in snapshots for about 2 weeks.
|
|
Also allow random_init() to be called later, by moving a few
entropy control initializions into the lower-level _rs_seed() layer.
tested by jsing, phessler and a few others
|
|
mouse port, depending upon the system time, match what the prom is doing and
actually probe for a keyboard on both ports, and decide the first port with a
keyboard is the keyboard port.
If no keyboard is found, but a mouse is found, decide the keyboard port is the
empty one.
If no device is found, then we can try and pick the defaults, depending upon
the system we are running on, as this used to be the case (i.e. coping with
Fuel having keyboard on port 1 and mouse on port 0 when connecting devices
according to the chassis' markings).
This is necessary because different IO9 board revisions on Tezro come with
different wirings, and we can not tell these boards apart.
Discussed with "nullnilaki" (nullnilaki on gmail) who is the lucky owner of an
Onyx 350 with correct wiring and a Tezro with inverted wiring. Tested on Octane
and Fuel with all combinations of devices connected (mouse only, keyboard only,
keyboard and mouse) in both ports, glass and serial console.
XXX We probably want to allow for more pckbd attachment flexibility on non-x86
XXX platforms eventually (at least where the PS/2 slots are really independent,
XXX so that we can attach pckbd to any port and better cope with human error
XXX when connecting devices.
|
|
and don't need to disable SMI ownership of the ACPI hardware registers.
ok mlarkin@
|
|
|
|
|
|
GENERIC.MP.
|
|
on sparc64.
|
|
BCM57785.
Tested by Mark Rowland.
|
|
code as it allows us to use some of the rasops_xxx functions directly.
|
|
there and the AML might reference stuff that isn't there.
|
|
|
|
|
|
|
|
ok jsing@
|
|
|
|
ok stsp
|
|
need to do, since we do not use many hpet features.
ok kettenis millert
|
|
|
|
program could force a copyin/copyout from/to memory mapped through the GTT,
forcing a "locking against myself" panic. The intel-gpu-tools "package" has
a test for this. The problem can be circumvented by making the fault handler
fail if we already hold the (DRM) lock. This will make the copyin/copyout
return with EFAULT making the caller fall back on a "slow path".
This makes it obvious that using a shared (read) lock here doesn't make any
sense. So use an exclusive (write) lock like everywhere else in the inteldrm
code.
|
|
|
|
|
|
Still a work-in-progress, but functional enough to work with both
Google Compute Engine and RHEVM. Committing so additional testing and
cleanup can be handled in tree.
thx Jiri B for RHEVM testing
ok dlg, deraadt
|
|
spec. More might be required.
ok jordan matthew mlarkin
|
|
|
|
There will be slight burps on resume due to other drivers being slow with
wakeup.
ok kettenis ratchov
|
|
|
|
|
|
return values. Fixes at least one bug where userland would see a negative
errno value and hopefully doesn't introduce any new ones.
|
|
to do this fairly late in the resume to avoid hangs.
ok deraadt@, mlarkin@
|
|
unsupported frame buffer configuration is requested.
|
|
Report and patch from Rafael Neves, thanks!
|
|
Report and patch from Rafael Neves, thanks!
|
|
more cache coherency issues, hopefully reducing the number of artifacts
showing up the screen.
|
|
|
|
|