general cleanup of the API. The entire API now consists of two functions
similar to the pre-KSE API. The suser() function takes a thread pointer
as its only argument. The td_ucred member of this thread must be valid
so the only valid thread pointers are curthread and a few kernel threads
such as thread0. The suser_cred() function takes a pointer to a struct
ucred as its first argument and an integer flag as its second argument.
The flag is currently only used for the PRISON_ROOT flag.
Discussed on: smp@
detect 3.3V cards for the 6710 and another method for the 6722. This
latter method is also how the 6729/6730 is supposed to detect 3.3V
cards. This method works great on my Fujitsu Stylistic 500. Sadly,
it appears that not all laptop makers are as detail oriented as the
folks that made the Stylistic. IBM Thinkpad 701C and AST Asentia 810N
both hang hard when the 6729 method is used, but at least the thinkpad
works when the 6710 method is used. The failure mode appears to be any
access to the memory that we've mapped the CIS in causes the machine to
hang until you eject the card. The Thinkpad, at least, works with this
change, and it doesn't break my Stylistic.
MFC after: 4 days
value (-1) in lue of 50 (which assumes a 5.0V card). The rest of the
pccard system doesn't detect the proper voltage for the card, so we have
to do it on powerup. Many (all?) 3.3V cards can tolerate 5.0V for reading
the CIS, but may fail to operate properly when so powered.
Idea from: Chiharu Shibata-san <chi@bd.mbn.or.jp> in bsd-nomads:15867
o Bite the bullet and create controller types for the 6729 and also for
the 673x. Rename the 672x to 6722.
o Define minimal extended register info (just register 0xa for reading VS[12]).
# I think the last version may have broken 673x controllers, but this should
# fix them.
Tested on the 6722, but not the 6729.
Ideas from: Chiharu Shibata-san's article in bsd-nomads:15866
on my CL-PD6722, but won't work on the CL-PD6729. The latter two need
more sophisticated detection of 3.3V cards than I'm up to at the
moment. Also, only a few of the ISA chipsets that support 3.3V will
likely work at the moment.
It appears that for 3.3V cards we must detect them and adjust the
pwr.vcc value from 50 to 33. Give a strong hint to automatically
power up the card for PD_POWER cards.
This makes my SMC 2602W (the 3.3V version of the 2632W) work on my
Fujitsu Stylistic 500.
SMC 3.3V card donated by: Ryan Losh
Thanks to: bsd-nomads for reviews of past 3.3V code
should also whine if the old pccardd is used, but that's a little
harder than it sounds.
This also has the effect of fixing a typo that was in the last
version I committed.
this accross suspend/resume events and this was causing the dreaded false
positive hit on my "static bug" test.
Note: the PCI bus code should do this for us.
Note2: We don't do the same for I/O based pci devices since it is
more code and doesn't appear to be necessary.
Submitted by: Toshiyuki Kawashima-san <tos@fa2.so-net.ne.jp>
Obtained from: bsd-nomads:16012
with the pccards deactivated. This can work around some problems in
pccard system, but is also for people that want to explicitly turn on
cards after boot rather that at boot.
MFC after: 7 days
Submitted by: iwasaki-san
Reviewed by: ume-san, shiba-san
for initializing the parts. Since I don't have any of these parts in
any of my working laptops, I'm committing this to allow people to test
it. Will MFC when I receive reports of it working.
o Move initialization of the slot bst and bsh to inside the for loop.
o move sc there as well.
o Remove debug printf that prints the ID of the first slot twice.
o Use the sp for the relevant slot in getb, rather than for the 0th slot.
again? That NEVER works!" "This time for sure!"
Minor overhaul of how we do interrupts for the pci interrupt routing
case to cope with card ejection better (read: make it not hand on so
many cards):
o Reintroduce func_intr and func_arg and use the to store the
interrupt handler to call.
o Create a pcic_pci_func_intr to call the real interrupt handler
iff the card hasn't been ejected.
o Remove some checks in pcic_setup_intr now that it is used
exclusively for isa routed interrupts.
o Defer the eject event until later too, but make sure we can't
do any client driver ISR calling in the interrum.
o Add some simple code to make sure that we don't attach more
than one child. This should fix pccardd starting twice
problem (ala single user -> multi-user when you started pccardd
by hand in SU).
MFC: after jkh thinks I've put the crack pipe away.
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
message. Some scsi devices have rather elaberate flags, and it is
hard to know which ones were specified in pccard.conf when debug
information only includes the dmesg.
When either bit 3 or 4 is set, we need to *SET* bit 5, not clear it in
the card control register. This makes TI PCI-1030, 1130 and 1131 not
work anymore without this fix.
MFC: soon
help with the hanging problem on reboot. Note: we need to do the
other things as well. Also, turn off the bits in the stat change
interrupt mask and the cardbus interrupt mask as well in an attempt to
shut off all interrupt sources.
# Note: The ToPIC 100 and the ToPIC 97 datasheets are in disagreement
# as to if this bit is supposed to be set or cleared to enable INTA routing
# so I made my best guess.
Also, comments about the various chipsets, including some grumpy ones
about how vague the O2micro datasheets are.
function and csc interrupt routing path (eg, ISA or PCI) so that we
can more easily switch between the two.
When we don't have a card ISR, put the function interrupt into ISA
mode. This effectively masks the interrupt since it happens once, and
not again until we have an ISR. This should help hangs, and might
help people that unwisely update the kernel w/o updating pccardd.
This is done at mapirq time.
Force CL-PD6729/30 to use ISA interrupt routing and maybe even detect
the number of pccard slots properly (this is still WIP). We aren't
going to support PCI interrupts for this release. A future release
should support them, however. Shibata-san's 3.3V fixes are not
included.
Add a hack which should, in i386, rewrite IRQ 0 cardbus bridges to be
IRQ 255, which should cause interrupts to be routed. This is mostly
untested since my one tester disappeared after reporting nothing
changed.
Implement, but do not use, a power method called cardbus. It looked
like a great way to get around the 3.3V problem, but it seems that you
can only use it to power cardbus cards (I get no CIS when I enable it,
so maybe we're programming things bogusly).
GC the intr and argp stuff from the slot database.
Improve the ToPIC support with the power hacks that Nakagawa-san
published in FreeBSD Press and that Hiroyuki Aizu-san ported to
-stable. The ToPIC hacks were for 3.3V support in ToPIC 100, but it
looks like the '97 also has identical registers, so use them too.
Add some #defines for the cardbus power stuff.
Finally implement making CSC on the Ricoh chips ISA or PCI. This will
allow polling mode to work on vaios, I think.
Add some minor debugging. This should likely be cleaned up or put
behing a bootverbose.
Some of this work, and earlier work, was influanced by Chiharu
Shibata-san's power handing patches posted to bsd-nomads:15866.
MFC: Soon, if possible.
config space that I'm aware of) work. I'm committing this from such
a machine.
Remove warning about I/O based bridges. Warn users that the PCI routing
of interrupts still doesn't work for these cards.
o For TI PCI-1130, you need to set bit 5 of register 91 if you want
ANY pci interrupts. Then set bits 3 and/or 4 as appropriate. This
will fix those people with 1030, 1130 and 1131 in their machines
trying to do PCI interrupts.
o Fix case where we were trying to automatically fail back to ISA
interrupt routing. We were dereferencing a NULL pointer. This
was true of ANY chipset.
o The bus_setup_intr method needs to be pcic_setup_intr so that "FAST"
interrupts fail on PCI case (modems act flakey if we don't force
them to fall back to normal interrupts). Also needed so that the
proper ISA IRQ can be set in the ExCA register. This fixes the
people whose ISA routing was failing[*].
o When we find a generic yenta/pccard bridge, go ahead and print its
vendor ID in boot verbose.
Machine with theses symptoms and a serial console by: jedgar
[*] Looks like my pc98 machine has some interrupt source on IRQ 15
that gave about 30 interrupts per second, which masked this problem on
my PC-9821Nr15.
interrupt for the CSC interrupt, then we revert to ISA. If we didn't
have an interrupt set up with hw.pcic.irq, then do polling.
Also, don't complain about ignoring function 1 for any devices except
pcic devices. This would normally only show up if someone set
hw.pcic.ignore_function_1=1.
MFC: as soon as I can test it on some troublesome laptops.
explain the subtle side effects that are going to happen and why we go
ahead and ack the interrupt source. This stuff is tricky to get
right.
Also, emperical tests have shown that doing a shutdown in attach to be
ineffectual, so remove it from there. Analysis of the code paths
shows that nearly identical writes to these registers happen in later
parts of the code. The hanging problem on thinkpads when we change
the interrupt routing type is something else.
shutdown and also before we get going with the device initialization.
This may fix the hangs some people are seeing on warmboot. It appears
that some machines will reset the cardbus bridge on boot, while others
don't. So we turn off the card, and ack the interrupts (which likely
is a nop in the shutdown case since we're still fielding interrupts).
This should turn off the interrupts.
Since I don't have hardware that hangs on reboot, I'm committing this
without testing that aspect of the patch (it causes no harm on my
Dell).
initialization structure. Warn the user for those chipsets that
aren't yet customized that they might not work. Second, try to power
off the slot on attach and ack the interrupts. I don't know, but this
might solve the hangs that people will see on Thinkpads if they set
hw.pcic.init_routing=1.
request and just calling it when we get a bridge interrupt. The
problem is that if other code wants to block hardware interrupts for a
little bit with splXXX, those masks aren't updated the way we're doing
it. This doesn't matter for -current, but does for -stable.
The whole reason that we were catching interrupts was to detect that
the card was still there. Ian's fixes however ensure that the card
will be there with an interrupt handler, or not there at all. Since
the pcic interrupt is at a high priority, this should be OK.
This should fix the network related crashes people started seeing in
stable after I merged the pcic as a pci device code.
Submitted indirectly by: Ian Dowse
MFC when: Ian has had a chance to do his torture hang testing.
the ISR. We keep track of the card state and don't call the IRS when
the card isn't inserted. This helps quite a bit with card ejection
problems that Ian was seeing.
Submitted by: Ian Dowse
MFC upon: re approvel.
assing an IRQ. Add better comments while I'm here.
MFC after: 1 day
# Note: That's merging all the -current pci pcic code, not just this one
# change for the Aug 15th code freeze.
register. It enables Zoom Video. It appears that on at least one
card that Monzoon is using sets these bits by default. Nothing works
when these bits are set, everything works when they are clear.
Add commentary on some of the ti bits. Make code a little clearer.
Also remove a call to pcic_pci_pd6729 which was prematurely added in
the last commit.
can't blindly write zero into it to disable the card. We must
preserve this bit. This changes pcic_disable to only clear the bits
we know we need to clear on card disable, thus preserving the magic
bit for many TI bridges.
This appears to have fixed the problems that people are reporting
about the system failing to recognize cards being inserted or removed
(or both). Greg: This may fix your problem too :-).
is the diagnostics register at offset 0x93. When bit 5 is set in this
register, bits 4-7 in ExCA register 0x5 being 0000 are required for
pci interrupt routing. When it is clear, then bit 4 of ExCA register
0x3 is used to enable it.
The only other issue is that when you route interrupts this way, you
must read ExCA register 0x4 in order to clear the interrupt, else you
get an interrupt storm.
Deal with this requirement by setting things up. It is believed that
this won't hurt other chipsets, but other chipsets may require their
own work arounds.
o Move PIOCSRESOURCE from pccard to pcic so the kernel can give pccardd
better hints as to what resources to use.
o Implement an undocumented hw.pcic.interrupt_route to allow people that
need to do so to route their interrupts in a non-standard way.
o Only preallocate a resource in probe if we're routing via pci.
o If we aren't routing via pci, then set the irq to use explicitly
to defeat the automatic IRQ routing of the pci layer.
This, with the pccardd code should be close to what can be committed
to -stable.
resources it is attempting to assign to a child object. This should
help people track down mysterious resource allocation problems more
easily.
# Unfortunately, it is harder to do the conflict check and report which
# resource failed if the driver itself doesn't.
strictly necessary on current, but having it in here makes the diffs with
stable smaller and doesn't hurt anything except for phk's redundant include
finder.
hw.pcic.irq Globally set the IRQ for all pcic devices' management
interrupt (aka card status change or CSC interrupt)
This is what used to be known as
machdep.pccard.pcic_irq (which has been retained for
now for compatibility).
hw.pcic.ignore_fuction_1 Ignores function 1 for all PCIC bridges by not
attaching to them. Lucent released a huge batch
of cards that were imporperly manufactuered (lacking
the 0 ohm resister to disable slot 1). This is
a big hammer to keep those cards from causing problems
(I've had 4 people contact me saying my patches
worked great once they added a kludge to always ignore
function 1, or until they soldered these resistors
in place!).
No clue where to document these. They act as both boot loader environment
variables, as well as read-only sysctls after boot.
At the same time, sort sys/systm.h in its proper order after sys/sysctl.h.
o kill blank line that I introduced in cardinfo.h
o Delete unused variable wasinactive.
o return 0 from pccard_resume.
o Set the state and lastsate initially to be empty.
o move comment above code for interrupt dispatching.
o Powerstate interface is now available as of 430002, not 500000 (note that
this change will be not 100% correct since the power state stuff didn't
enter current until well after 500000, but it is good enough for the two
branche we have going now).
power x 0.
pccardc power x 0 used to disable the slot. But a suspend/resume
would reactivate the pccard. It no longer does that. Now the
disabling of the slot is sticy until it is reset with power x 1 or the
card is ejected. This seems closer to correct behavior to me.
o Process all card state changes the same using pccard_do_stat_change().
o Cleanup disabling the card so that we can preserve the state after
the change. Basically, don't set it to empty as often as we do.
o On suspend, the new state is "empty" and the laststate is "suspend"
o Document state machine with a diagram of states and edges. The
edges are labeld to tell the reader what event causes the external
state changes.
o "machdep.pccard.pcic_resume_reset" may be obsolete now. We always
call the bridge driver's resume method on resume now. Otherwise cards
won't automatically show up. If it needs to stay, I'll add it back.
longer have a pccard in the slot. This fixes the problem where pccard
would say that a card had been inserted on resume. This also appears
to make the insert/remove events more reliable after a resume as well,
but that may be a different bug I need to hunt down.
Sometimes, when pccardd is restarted, it fails to realize that the
device is already attached and tries to attach it again. This leads
to bad mojo since the pccard code isn't setup to handle that, so the
panic was put in. Now it appears that it is triggering too easily, so
I'm backing it off to a non-fatal error.
