in the not APIC_IO case. This should silence the warnings when
building pcic.c as well as the undefined functions when the kernel
links.
Noticed by: several people in -current and me building the kernel
This will trigger inserted()) to be called twice which confuses pccardd.
Add code to not process pcicitr())'s when in the middle of a resume
process. The real insertion of cards and the emulated one in the suspend/resume
code really do not mix up.
however is only marginally useful until the new-style bus (pci and isa)
stuff comes onboard to give us a better shot at actually pci and isa
drivers loadable (or preloadable anyway).
We do the same thing we do with all the other Vadem chips and print the
right identification for these chips. Tested with the 365, and inferred
for the 465.
This allows the cheapo PCMCIA card that I got from necx to print the right
chip number on boot.
`void *' arg. Fixed or hid most of the resulting type mismatches.
Handlers can now be updated locally (except for reworking their
global declarations in isa_device.h).
option PCIC_NOCLRREGS). This is now the default behavior since it's
apparently required for the CLPD6832, and doesn't negatively affect
any of my test machines.
Requested by: Ted Faber <faber@ISI.EDU>
(update_intr_masks might not need to be done in 3.X, but the new generic
interrupt code is incomplete w/regard to support for the PCCARD code, so
to avoid any potential problems use it. It can't hurt).
- Correctly register pcic_imask with the system interrupt code.
- Call update_intr_masks() so that pcic_imask modifications that occur
when card interrupts are registered get updated in the system
interrupt code.
follow.
* Rename/reorder all of the pccard structures, change many of the member
names to be descriptive, and follow more closely other 'bus' drivers
naming schemes.
* Rename a bunch of parameter and local variable names to be more
consistant in the code.
* Renamed the PCCARD 'crd' device to be the 'card' device
* KNF and make the code consistant where it was obvious.
* ifdef'd out some unused code
speaker. Cirrus Logic PCIC chips must enable this. There is also a Low
Power Dynamic Mode bit that claims to reduce power consumption by 30%,
so enable it and hope for the best.
PR: 4650
Submitted by: Nick Sayer <nsayer@quack.kfu.com>
(pt. unused) for TI PCI1130.
2. pccard.c: PCIC_RESUME_RESET is now (also) a sysctl. (Never make it
a #ifdef if it can be made a sysctl!)
3. pcic.c: make getb() and putb() proper member functions of struct
pcic_slot. Add a couple of missing casts.
Use the name argument almost the same in all LKM types. Maintain
the current behavior for the external (e.g., modstat) name for DEV,
EXEC, and MISC types being #name ## "_mod" and SYCALL and VFS only
#name. This is a candidate for change and I vote just the name without
the "_mod".
Change the DISPATCH macro to MOD_DISPATCH for consistency with the
other macros.
Add an LKM_ANON #define to eliminate the magic -1 and associated
signed/unsigned warnings.
Add MOD_PRIVATE to support wcd.c's poking around in the lkm structure.
Change source in tree to use the new interface.
Reviewed by: Bruce Evans
non-broken chipssets whose ID is 0x84, such as the one found in the NEC
6030H.
> The code relies on the assumption that on a genuine_broken vlsi, you
> don't get 0x84 when probing slot 1 in the normal location. On the versa I
> do get 0x84 when probing slot 1 in the normal location. What you get on
> genuine_broken at the normal slot 1 location is unknown to me;
Submitted by: Chris Timmons <skynyrd@opus.cts.cwu.edu>
Assuming that the intr_mask[] was updated by changing the maskptrs (the
existing update_intr_masks() function will not work) this code was
written so the PCIC controller insertion/removal events will not
interrupt the card IRQ handler events.
Some possible scenarios:
+ Card is removed during IRQ handler:
- PCIC card handler is allowed to interrupt
- card removal event is called, removing the driver and data structures
* card interrupt handler continues w/out driver, data structures, and hardware
OR (the code just committed)
* card IRQ handler has no hardware to read/write to, but has code and
data to run on (XXX- Assume it completes and doesn't spin forever)
- PCIC card handler unloads the card driver
The current situation at least leaves the card interrupt handlers the
drivers and data structures to work with although the hardware can't be
guaranteed.
Reviewed by: bde
