After we get a good power signal, always wait about 10ms before
proceeding.

On boot, some laptops with certain cards in them sometimes fail on
boot, but if the card is inserted after boot it works.

After we get a good power signal, always wait about 10ms before
proceeding.

On boot, some laptops with certain cards in them sometimes fail on
boot, but if the card is inserted after boot it works. Experiments
show that small delays here makes things more reliable. It is
believed that some combinations need a little more time before the
power on the card is really stable enough to be reliable once the
power is stable in the bridge.

show more ...

Merge svn+ssh://svn.freebsd.org/base/head@218816

sysctl(9) cleanup checkpoint: amd64 GENERIC builds cleanly.

Commit the rest of the devices.

Merge from head

Merge from head up to r188941 (last revision before the USB stack switch)

- MFC from head@196987

MFC 196403: Temporarily revert the new-bus locking for 8.0 release.

Approved by: re (kib)

Temporarily revert the new-bus locking for 8.0 release. It will be
reintroduced after HEAD is reopened for commits by re@.

Approved by: re (kib), attilio

- MFC @196061

Make the newbus subsystem Giant free by adding the new newbus sxlock.
The newbus lock is responsible for protecting newbus internIal structures,
device states and devclass flags. It is necessary to h

Make the newbus subsystem Giant free by adding the new newbus sxlock.
The newbus lock is responsible for protecting newbus internIal structures,
device states and devclass flags. It is necessary to hold it when all
such datas are accessed. For the other operations, softc locking should
ensure enough protection to avoid races.

Newbus lock is automatically held when virtual operations on the device
and bus are invoked when loading the driver or when the suspend/resume
take place. For other 'spourious' operations trying to access/modify
the newbus topology, newbus lock needs to be automatically acquired and
dropped.

For the moment Giant is also acquired in some key point (modules subsystem)
in order to avoid problems before the 8.0 release as module handlers could
make assumptions about it. This Giant locking should go just after
the release happens.

Please keep in mind that the public interface can be expanded in order
to provide more support, if there are really necessities at some point
and also some bugs could arise as long as the patch needs a bit of
further testing.

Bump __FreeBSD_version in order to reflect the newbus lock introduction.

Reviewed by: ed, hps, jhb, imp, mav, scottl
No answer by: ariff, thompsa, yongari
Tested by: pho,
G. Trematerra <giovanni dot trematerra at gmail dot com>,
Brandon Gooch <jamesbrandongooch at gmail dot com>
Sponsored by: Yahoo! Incorporated
Approved by: re (ksmith)

show more ...

Update the projects tree to a newer FreeBSD current.

Better name for this routine... it doesn't reset the card, but resets
the power to the card...

Hold off root mounting until we've gone through the loop of our thread
almost once. After we've configured the devices that were present the
first time through, then we know that we're done. If the

Hold off root mounting until we've gone through the loop of our thread
almost once. After we've configured the devices that were present the
first time through, then we know that we're done. If the device has
other devices that are deferred, then it must do a similar dance.
This catches both PC Cards and CardBus cards.

show more ...

Correct signatures to match kobj function definitions.

Minor tweaks to some of the comments. Also, add a XXX wondering if we
need to frob the 16-bit EXCA registers during the new interrupt-driven
power-up sequence.

Use '0' rather than PZERO to not change the priority that I'm waiting
at. I don't think this will make a huge difference, but I have
received a report of a interrupt storm on one 16-bit card that th

Use '0' rather than PZERO to not change the priority that I'm waiting
at. I don't think this will make a huge difference, but I have
received a report of a interrupt storm on one 16-bit card that this
might fix (chances are it won't, since I think that we may need to
check both the CBB registers for the 16-bit card as well as the PCIC
registers for power state change).

Submitted by: jhb@

show more ...

Move to using filter for the change interrupts. Also rework the power
interrupt code to be more robust. I've been running these changes for
over a year... With these changes, I don't see the ath c

Move to using filter for the change interrupts. Also rework the power
interrupt code to be more robust. I've been running these changes for
over a year... With these changes, I don't see the ath card going
into reset like the code in the tree.

show more ...

Minor style nit.

Augment comments, and move things around a smidge.

Implement a method described in NetBSD PR 36652 for coping with the
BAD VCC bit.

Read the config space of the child, not the bridge, to determine when
the child is out of reset... <blush>

fix typo

Submitted by: N.J. Mann

It turns out that checking the first DWORD register is more reliable
on a variety of cards. Adjust the comments accordingly to match the
code. Even if the vendor chose 0xffff for the device ID, the

It turns out that checking the first DWORD register is more reliable
on a variety of cards. Adjust the comments accordingly to match the
code. Even if the vendor chose 0xffff for the device ID, the vendor
ID can't be 0xffff, so the test is still valid from a standards
perspective.

show more ...

After some intial testing, there are even slower cards than the ones
that I have. Wait up to 1.1s for the card to become ready. Document
what the standards say, and use that to justify the behavior

After some intial testing, there are even slower cards than the ones
that I have. Wait up to 1.1s for the card to become ready. Document
what the standards say, and use that to justify the behavior in the
code: PCI standard says that a card must respond to configuration
cycles within 2^25 cycles after reset goes high, which is
approximately 1s. Therefore, give cards a little break and wait for
up to 1.1s for VENDOR to become valid. Only look at the vendor part
of the ID, since only it can't be 0xffff (although in practice
vendor/device will always be != 0xfffffffff). Include detailed
pointers to standards so epople understand why we're doing what we're
doing and why it just might be OK. Make it clear in the timeout
message that it is just a warning, sinc we try to soldier on as best
we can anyway.

This should eliminate an error message that r181453 produced on
certain Atheros cards.

show more ...

Rather than waiting a fixed amount of time, which might not be enough
and also holds things up, check every 20ms to see if we can read the
vendor of device 0.0. It will be 0xffffffff until the card

Rather than waiting a fixed amount of time, which might not be enough
and also holds things up, check every 20ms to see if we can read the
vendor of device 0.0. It will be 0xffffffff until the card is out of
reset. Always wait at least 20ms, for safety.

I think this is a better fix to the reset problem. However, I did it
as a separate commit in case something bad happens, people can roll
back to the commit before this one to see if that gives them reliable
behavior. I don't have FreeBSD up on enough machines to do exhaustive
testing on all known bridges...

show more ...