| Age | Commit message (Collapse) | Author |
|---|
|
entry. if i ever implement timeouts ill use high bits in the int
or the phase bit to indicate non chip related errors. a successful
chip status conveniently maps to 0. how handy.
this lets me move the completion handling for the controller
identification commands back into the caller. at the moment im just
printing out controller and firmware details like we do on
mfi/mpii/mfii.
|
|
steps, but unfortunately the next step after "talk to the chips
registers" was "get command queues working" which ended up being a
huge amount of plumbing.
anyway, this lets me successfully run an identify controller command
against the chip and should be cut up the right way to be usable
for io command submissions. will need to think about how to avoid
overflowing rings though.
|
|
instead of using the default, per-driver, one. This is a step to move
away from the 1 report ID <-> 1 driver design which is no longer true
since the addition of upd(4).
ok andre@
|
|
|
|
post-attach mailbox operations work reliably.
|
|
|
|
to sleep, instead of just the acpi thread going to sleep.
|
|
Fix some parameters and wording too.
|
|
time also. Let's commit this idea since it is sound, and keep an eye
for reports.
discussed months ago with kettenis and mlarkin
|
|
|
|
From Rob Clark
8af4707afcb6d191b9cc75dfd73b9550e8276253 in ubuntu 3.8
9ef7506f7eff3fc42724269f62e30164c141661f in mainline linux
|
|
From Alex Deucher
20b03e738e7ded3ab66dd7dd3c3ac198c8531381 in ubuntu 3.8
d03874c881a049a50e12f285077ab1f9fc2686e1 in mainline linux
|
|
From Lauri Kasanen
7e88b3ea565f869721b8ac011ee73b95b773e938 in ubuntu 3.8
14eedc32a3c0ec9dd70448a73763ee21feae3111 in mainline linux
|
|
|
|
|
|
|
|
|
|
|
|
while it might be ok (and hasnt actually blown up since i committed
that) id rather review the code and enable it explicitely.
|
|
|
|
|
|
to scan for the product ID again.
|
|
the sc_devs array.
|
|
|
|
Logic controllers, taken from the Linux kernel.
ok mpi@
|
|
- Allocate/enable sensors wich match both: the static usage table of supported
usage IDs and the usages supported by the device;
- Do not attach when no sensors can be allocated;
- Makes device querying smarter: query the device just once for values stored
in the same reportid reply payload.
- Use sensor_status.
ok mpi@
|
|
call tsleep(9) on resume. deraadt@ pointed that this not needed
for powerdown since `cold' is set.
Another approach would be to call delay() directly in the reset
functions, but let stay coherent with the other HC drivers.
|
|
|
|
|
|
matter if we don't see ourselves, and if we pick another starting point, the
first port we see might disappear half way through (I have seen this happen),
which makes it more complicated to identify when we're back at the start.
|
|
ok kettenis@
|
|
add that, don't try loading firmware for them.
|
|
|
|
the interrupt handler as well. See rev 1.12.
|
|
firmware (2048 for 2k login firmware, 256 otherwise)
pointed out by deraadt@, ok dlg@
|
|
interrupt. With this we can talk to Hitachi disk arrays, which sometimes
return so much sense data that a status continuation response is generated
in addition to the normal status response.
tested by deraadt@
|
|
|
|
|
|
ok jmatthew@
|
|
|
|
in a seperate header file. This will become a dumping ground for similar code.
ok jsg@
|
|
|
|
before suspending the machine.
Prior to this commit, devices were logically disconnected after
resuming the machine leading to funny races since the controller
was reset in between.
ok deraadt@
|
|
call bufq_quiesce() after executing the DVACT_QUIESCE handlers.
This should be safe since no disk nor controller drivers have such
handler but it will allow us to detach sd(4) devices attached to a
USB bus.
Another benefit pointed out by kettenis@ is that drivers that need
to read a firmware from the disk should be able to do it at resume
time in a DVACT_WAKEUP handler.
ok kettenis@, deraadt@
|
|
local devices it has logged in to. This will also be useful for hotplug
later on.
|
|
u_int32_ts rather than u_int64_ts.
ok jmatthew@
|
|
|
|
ok jmatthew@
|
|
ok jmatthew@
|
|
|
