where it looks straightforward, and pci_aprint_devinfo_fancy in a few
others where drivers want to supply their own device names instead
of the pcidevs generated one. More complicated cases, where names
are composed at runtime, are left alone for now. It certainly makes
sense to simplify the drivers here rather than inventing a catch-all API.
This should serve as as example for new drivers, and also ensure
consistent output in the AB_QUIET ("boot -q") case. Also, it avoids
excessive stack usage where drivers attach child devices because the
buffer for the device name is not kept on the local stack anymore.
-cardbus doesn't use multiple interrupt lines like PCI, and it doesn't
use machanisms like interrupt line register and swizzling -- no need
to carry around dummy information, this is all dealt with by the
bridge
(I'm asking myself how "rbus_ppb" can work -- a bridge attached to
cardbus just can't work like a normal PCI bridge as far as interrupts
are concerned. I thing that should be a hardware specific driver
because behavior is not covered by a standard.)
-cardbus always uses 3.3V -- no need for a variable to keep track
of the voltage
bus_space_tag_create(9), and bus_space_tag_destroy(9). Use
bus_space_is_equal(9) throughout the kernel to compare
bus_space_tag_t's. Tested on i386 and on sparc64.
substitution: for all practical purposes, pcitag_t and cardbustag_t are
interchangeable, so just use pcitag_t. Ditto pcireg_t and cardbusreg_t.
Poison new uses of cardbusreg_t and cardbustag_t by deleting the type
definitions.
and non-const types, and the kernel uses both const and non-const
PMF qualifiers and device suspensors, so change the pmf_qual_t and
device_suspensor_t typedefs from "pointers to const" to non-pointer,
non-const types.
and wakeup(9).
Use mstohz(9).
XXX Protection against spurious wakeups is still needed, but this patch
XXX makes the code no worse than before in this regard.
acquired bus space from bus_space_alloc(9) or from rbus_space_alloc(),
so that we use the appropriate routine to release the bus space in
pccbbdetach(). This stops panics during cbb(4) detachment (esp. at
shutdown) on some systems.
Thanks to Kurt Schreiner for testing the fix, Kurt, Patrick Welche,
Pouya D. Tafti, and Matt Green for reporting.
Call the detach routine for every device in the device tree, starting
with the leaves and moving toward the root, expecting that each
(pseudo-)device driver will use the opportunity to gracefully commit
outstandings transactions to the underlying (pseudo-)device and to
relinquish control of the hardware to the system BIOS.
Detaching devices is not suitable for every shutdown: in an emergency,
or if the system state is inconsistent, we should resort to a fast,
simple shutdown that uses only the pmf(9) shutdown hooks and the
(deprecated) shutdownhooks. For now, if the flag RB_NOSYNC is set in
boothowto, opt for the fast, simple shutdown.
Add a device flag, DVF_DETACH_SHUTDOWN, that indicates by its presence
that it is safe to detach a device during shutdown. Introduce macros
CFATTACH_DECL3() and CFATTACH_DECL3_NEW() for creating autoconf
attachments with default device flags. Add DVF_DETACH_SHUTDOWN
to configuration attachments for atabus(4), atw(4) at cardbus(4),
cardbus(4), cardslot(4), com(4) at isa(4), elanpar(4), elanpex(4),
elansc(4), gpio(4), npx(4) at isa(4), nsphyter(4), pci(4), pcib(4),
pcmcia(4), ppb(4), sip(4), wd(4), and wdc(4) at isa(4).
Add a device-detachment "reason" flag, DETACH_SHUTDOWN, that tells the
autoconf code and a device driver that the reason for detachment is
system shutdown.
Add a sysctl, kern.detachall, that tells the system to try to detach
every device at shutdown, regardless of any device's DVF_DETACH_SHUTDOWN
flag. The default for kern.detachall is 0. SET IT TO 1, PLEASE, TO
HELP TEST AND DEBUG DEVICE DETACHMENT AT SHUTDOWN.
This is a work in progress. In future work, I aim to treat
pseudo-devices more thoroughly, and to gracefully tear down a stack of
(pseudo-)disk drivers and filesystems, including cgd(4), vnd(4), and
raid(4) instances at shutdown.
Also commit some changes that are not easily untangled from the rest:
(1) begin to simplify device_t locking: rename struct pmf_private to
device_lock, and incorporate device_lock into struct device.
(2) #include <sys/device.h> in sys/pmf.h in order to get some
definitions that it needs. Stop unnecessarily #including <sys/device.h>
in sys/arch/x86/include/pic.h to keep the amd64, xen, and i386 releases
building.
and return all-ones explicitely.
Since pccbb.c rev. 1.151 the cbb is set to translate cardbus master
aborts which makes that the PCI configuration read on the primary bus
returns random junk. This can cause the probing code to get confused.
The issue was reported by KIYOHARA Takashi and Jonathan A. Kollasch,
the patch was tested by KIYOHARA Takashi.
uses in pcmcia ressource management which is copied from ISA pcic,
so use our softc as handle exported to generic pcmcia code and kill
the ph_parent backpointer - this makes the code simpler and smaller
and debug code, from Patrick Welche
(we could as well drop pcic_handle completely and use our softc as
the opaque handle for the pcmcia code - this would simplify the code
even more)
Extract some data structures for ressource management into our private
header instead. This allows to use a typed pointer instead of a
generic one which saves a lot of typecasts.
Also remove something marked as "dirty hack" which I admittedly don't
understand, but it doesn't look useful...
There were cardbus_intr_line_t and cardbus_intr_handle_t used intermixed
for the same variable, and that variable is pretty much useless because
cardbus doesn't follow the PCI interrupt swizzling etc scheme.
Useless interrupt numbers were printed on cardbus device attach.
So as a first step to sanity, kill cardbus_intr_handle_t and poison
cardbus_intr_line_t to discourage printing it as a %d.
Use cardbus_intr_line_t consistently throughout the code.
Remove the "interrupting at foo" messages because the information
is misleading. We could come up with a better interrupt vector
information, but because cardbus interrupts are mediated by pccbb
it would still be misleading.
since the driver must acknowledge some interrupts while it leaves
the suspended state. This protects against an interrupt storm that
will hang the system while I resume rtw0 at cardbus1.
establish the interrupt handler before enabling interrupts, so that
we will not get an interrupt storm that keeps the system from making
any progress. (We may have only been susceptible to the storm if
cbb(4) shared an interrupt with, say, uhci(4)). Also, finish
setting up the pcic_handle before enabling interrupts, so that the
Pcic_read() call in pccbbintr() will not jump to address 0!
Now, pccbb_intrinit() encapsulates all of the interrupt initialization.
Explicitly enable card-status changed (CSTSCHG) events.
Paranoia: ensure that writes to the socket event register (interrupt
acknowledgements) are flushed to the h/w by reading the register
(gross). We really need something like
bus_space_sync(BUS_SPACE_BARRIER_WRITE_BEFORE_INTERRUPT).
More paranoia: in pccbbintr(), if the device is inactive, get out.
a pointer to that struct, so that we cannot assign pointers of
arbitrary type to cardbus_chipset_tag_t. Tweak cbb(4) to accomodate
this change.
Make Cardbus_conf_read() and Carbus_conf_write() pass the right
arguments to cardbus_functions->cardbus_conf_{read,write}() for a
change.
Let's hope this stops the crash in cardbus_function_enable() that
macallan@ reported to me.
of this entire device tree:
pci0 at mainbus0
elansc0 at pci0
gpio0 at elansc0
cbb0 at pci0
cardslot0 at cbb0
cardbus0 at cardslot0
pcmcia0 at cardslot0
cbb1 at pci0
cardslot1 at cbb1
cardbus1 at cardslot1
rtw0 at cardbus1
pcmcia1 at cardslot1
sip0 at pci0
nsphyter0 at sip0
sip1 at pci0
nsphyter1 at sip1
Whew!
drochner