Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Replace archaic "busses" with modern form "buses."
Intentionally excluded:
* Old/random drivers I didn't recognize
* Old hardware in general
* Use of "busses" in code as identifiers
No functional change.
http://grammarist.com/spelling/buses-busses/
PR: 216099
Reported by: bltsrc at mail.ru
Sponsored by: Dell EMC Isilon
- Add a pcib_detach() function for the PCI-PCI bridge driver. It
tears down the NEW_PCIB and hotplug state including destroying
resource managers, deleting child devices, and disabling hotplug
events.
- Add a detach method to the ACPI PCI-PCI bridge driver which calls
pcib_detach() and then frees the copy of the _PRT interrupt routing
table.
- Add a detach method to the PCI-Cardbus bridge driver which frees
the PCI bus resources in addition to calling cbb_detach().
- Explicitly clear any pending hotplug events during attach to ensure
future events will generate an interrupt.
- If a the Command Completed bit is set in the slot status register
when the command completion timeout fires, treat it as if the
command completed and the completion interrupt was just lost rather
than forcing a detach.
- Don't wait for a Command Completed notification if Command Completion
interrupts are disabled. The spec explicitly says no interrupt is
enabled when clearing CCIE, and on my T400 no interrupt is generated
when CCIE is changed from cleared to set, either. In addition, the
T400 doesn't appear to set the Command Completed bit in the cases
where it doesn't generate an interrupt, so don't schedule the timer
either. (If the CC bit were always set, one could always set the timer
and rely on the logic of treating CC set as a missed interrupt.)
Reviewed by: imp (older version)
Differential Revision: https://reviews.freebsd.org/D6424
On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).
Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.
Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)
Tested PAE and devinfo on virtualbox (live CD)
Special thanks to bz for his testing on ARM.
Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544
Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.
This is step one in migrating rman to use uintmax_t for resources instead of
u_long.
Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.
This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.
Reviewed By: jhb
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075
initialize the MFUNC registers. Our old test of assuming that if this
register is set at all is not quite right. Many scenarios (including
the power-on defaults for chips w/o EEPROMs) land us in trouble. The
MFUNC0 pin should be set to signal #INTA and the MFUNC1 pin should be
set to signal #INTB of multi-socketed devices. Since my memory recalls
issues with blindly clearing the upper bytes of this register, perform
the heuristic only when both MFUNC0 and 1 are clear. We won't work
well using these pins for GPIO, and the serial interrupts won't save
us because we go out of our way to generally disable them. They are
needed to support legacy drivers for 16-bit PC Cards that are
hard-wired to specific IRQ values. Since FreeBSD never had any of
these, we configure the more reliable direct signaling. This was just
one small piece of that which had been left out back in the day.
(type 1 and type 2) as well as leaf devices (type 0). In particular,
this allows the existing PCI bus logic to save and restore capability
registers such as MSI and PCI-express work for bridge devices rather than
requiring that code to be duplicated in bridge drivers. It also means
that bridge drivers no longer need to save and restore basic registers
such as the PCI command register or BARs nor manage powerstates for the
bridge device.
While here, pci_setup_secbus() has been changed to initialize the 'sec'
and 'sub' fields in the 'secbus' structure instead of requiring the pcib
and pccbb drivers to do this in the NEW_PCIB + PCI_RES_BUS case.
Differential Revision: https://reviews.freebsd.org/D2240
Reviewed by: imp, jmg
MFC after: 2 weeks
resume sometimes (but not others). On powerup, other wierd issues show
up (sometimes the card comes up, but with really bogus pci config
space stuff. There may be more, but given my experience of historical
fussiness, stick to what works and make more minimal changes to that.
can suspend / resume and unload / load cbb and cardbus without errors
on my Lenovo T400, which wasn't possible before. Cards suspending
and resuming in the CardBus slot not yet tested.
o Enable memory cycles to the bridge early (as part of the new
cbb_pci_bridge_init). This fixes the Bad VCC errors which were
caused by the code accessing the device registers with this
cleared. The suspend / resume process clears it.
o Refactor suspend / resume into bus specific code (though the ISA
code is just stubbed). This isn't strictly necessary, but makes
the initializaiton code more uniform and should be more bullet
proof in the face of variant behavior among cardbus bridges.
o Fixup comments in the power-up sequence to reflect reality. These
comments were written for one regime of power-up, but not updated
as things were revised.
o Add a paranoid small delay (100ms) to cover noisy cards powering
down.
o Fix some debugging prints to be easier to grep from dmesg.
Sponsored by: Netflix
bridges in strange ways, either rendering them unable to detect
insertion and removal events, or possibly unable to read from the
device behind the bridge.
This fixes at least one laptop, a Toshiba Tecra M5 with a Texas
Instruments PCxx12 (d=0x8039 v=0c104c) bridge. The very similar
Tecra M9 has the same bridge, but worked fine without this change.
The bridge chip has no I/O port BAR, and there is nothing in the spec
to suggest I/O decoding should be enabled; however enabling it fixes
the issue. Add an XXX comment to this effect.
Discussed with: jhb, imp
MFC after: 2 weeks
I/O windows, the default is to preserve the firmware-assigned resources.
PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture
defines a PCI_RES_BUS resource type.
- Add a helper API to create top-level PCI bus resource managers for each
PCI domain/segment. Host-PCI bridge drivers use this API to allocate
bus numbers from their associated domain.
- Change the PCI bus and CardBus drivers to allocate a bus resource for
their bus number from the parent PCI bridge device.
- Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the
full range of bus numbers from secbus to subbus from their parent bridge.
The drivers also always program their primary bus register. The bridge
drivers also support growing their bus range by extending the bus resource
and updating subbus to match the larger range.
- Add support for managing PCI bus resources to the Host-PCI bridge drivers
used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib).
- Define a PCI_RES_BUS resource type for amd64 and i386.
Reviewed by: imp
MFC after: 1 month
command register. The lazy BAR allocation code in FreeBSD sometimes
disables this bit when it detects a range conflict, and will re-enable
it on demand when a driver allocates the BAR. Thus, the bit is no longer
a reliable indication of capability, and should not be checked. This
results in the elimination of a lot of code from drivers, and also gives
the opportunity to simplify a lot of drivers to use a helper API to set
the busmaster enable bit.
This changes fixes some recent reports of disk controllers and their
associated drives/enclosures disappearing during boot.
Submitted by: jhb
Reviewed by: jfv, marius, achadd, achim
MFC after: 1 day
This allows my TI1510 cardbus/PCI bridge to work after a suspend/resume,
without having to unload/reload the cbb driver.
I've also tested this on stable/9. I'll MFC it shortly.
PR: kern/170058
Reviewed by: jhb
MFC after: 1 day
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
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.
o Try to be smarter about reading the ExCA CSC register. Now, we only
do it for 16-bit cards. Add some experimental code to treat it like
a power interrupt, but I'm not 100% sure that I like it. It may be
removed upon further testing. It seemed to help in one test case, but
the evidence may be inconclusive. This may be beneficial for cleaning up
exca_reset and exca_wait_ready.
o Check for CSTS events on the socket event register. We ask for it when
we're powering up a card, but I don't think we're otherwise using
it. Just ACK the interrupt for now. In theory, we can use it
instead of the busy wait we do in cbb_cardbus_reset. More research
is necessary to see if we can optimize things there when we're
waiting for the DEVVENDOR register to become valid.
o Rework the comments a bit. Minor tidying up. Etc.
the power interrupt and init code waiting for the interrupt are
running on different CPUs. I haven't seen this make any real
difference, but I've also had some reports of odd behavior I can't
otherwise explain. It is an infrequent operation, and certainly
wouldn't hurt.
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.
to kproc_xxx as they actually make whole processes.
Thos makes way for us to add REAL kthread_create() and friends
that actually make theads. it turns out that most of these
calls actually end up being moved back to the thread version
when it's added. but we need to make this cosmetic change first.
I'd LOVE to do this rename in 7.0 so that we can eventually MFC the
new kthread_xxx() calls.
support machines having multiple independently numbered PCI domains
and don't support reenumeration without ambiguity amongst the
devices as seen by the OS and represented by PCI location strings.
This includes introducing a function pci_find_dbsf(9) which works
like pci_find_bsf(9) but additionally takes a domain number argument
and limiting pci_find_bsf(9) to only search devices in domain 0 (the
only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are
changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order
to no longer report false positives when searching for siblings and
dupe devices in the same domain respectively.
Along with this change the sole host-PCI bridge driver converted to
actually make use of PCI domain support is uninorth(4), the others
continue to use domain 0 only for now and need to be converted as
appropriate later on.
Note that this means that the format of the location strings as used
by pciconf(8) has been changed and that consumers of <sys/pciio.h>
potentially need to be recompiled.
Suggested by: jhb
Reviewed by: grehan, jhb, marcel
Approved by: re (kensmith), jhb (PCI maintainer hat)
own entry in the softc. This should allow more of cbb_pci_intr() to
migrate to a new cbb_pci_filt() so that we don't have to run cbb's ISR
in almost every case we get an interrupt. We can't just move
cbb_pci_intr into cbb_pci_filt because it does things that aren't safe
to do from a fast interrupt handler, err I mean from a filter. This is
an important first step.
# I wonder if I need to make cardok volatile or not.
o when turning off the socket for a 16-bit card, write 0 to INTR register
rather than just tying to just clear the rest bit. this seems to fix
card insert detection after an eject on TI bridges (ricoh bridges work
either way, apparently). This is a MFp4.
o Cope better with TOPIC95 bridges on powerup. According to NetBSD driver,
these bridges don't set POWER_STATE, so cope accordingly in our power
code. They also need a little extra time to settle, so do that as well.
o It appears that we need to turn on/off one of the clocks to the card
when we power up/down that socket on a TOPIC97, also from NetBSD.
o TOPIC97 bridges need to specifically enable LV card support. Unconditionally
do this in the hopes that all laptops that have these chips support LV
voltages (they should, since they are required for CardBus).
o TOPIC register name regularization. Registers specific to models of TOPIC
are now called out as such.
# I need a machine with a TOPIC95 for testing.
o Don't busy wait on powerup. Instead, use the power up interrupt to wait
for the card to power up. Don't wait when we're turning the card off,
since no interrupt happens in that case.
o Convert many of the long DELAYs to tsleeps. We do not run before
the timer have stared, so DELAY isn't necessary. More DELAYs can likely
be eliminated in the future.
o When powering up the card, don't do anything if the card is already
powered up (before we'd power cycle it). This means that for most
cards we power them up once and then never change the power.
o On card eject, mask (by clearing) the CD bit. Before we set it, which
was wrong. We don't want to see any CD events past the first one since
they need to be debounced.
With these changes, I can insert/eject 16bit cards without glitching xmms'
sound output. Something very important to the development of better pccard
drivers :-)
pcib_route_interrupt interface. Since there's only one interrupt pin
in the CardBus form factor, everybody gets to share it. Implement
cbb_route_interrupt to return the interrupt we have.
Suggested by: bms
