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
sometimes. It will power up wrong and identify itself badly:
cardbus0: <network, ethernet> at device 0.0 (no driver attached)
cardbus0: <simple comms, UART> at device 0.1 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.2 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.3 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.4 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.5 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.6 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.7 (no driver attached)
All the higher numbered functions (.2 and above) have a config space
of all 0's. This smells a bit like a special debug mode, but the
current atheros driver doesn't cope. It is unclear if this card is
just a flake, or if we're doing something wrong in the power-up
sequence.
Put a work around into the code that tests for this rather unusual
condition. If we power a CardBus device up, and the device says it is
multi-function, and any of the functions have a 0 device ID, try the
power-up sequence again.
These changes prevent sysctl(8) from returning proper output,
such as:
1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.
Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.
MFC after: 2 weeks
Sponsored by: Mellanox Technologies
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
The tag enforces a single restriction that all DMA transactions must not
cross a 4GB boundary. Note that while this restriction technically only
applies to PCI-express, this change applies it to all PCI devices as it
is simpler to implement that way and errs on the side of caution.
- Add a softc structure for PCI bus devices to hold the bus_dma tag and
a new pci_attach_common() routine that performs actions common to the
attach phase of all PCI bus drivers. Right now this only consists of
a bootverbose printf and the allocate of a bus_dma tag if necessary.
- Adjust all PCI bus drivers to allocate a PCI bus softc and to call
pci_attach_common() from their attach routines.
MFC after: 2 weeks
The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.
the BAR after parsing the CIS. This forces the resource range to be
reallocated if the BAR is reused by the device.
Submitted by: deischen
Reviewed by: imp
Approved by: re (kib)
o Consider No CIS a normal event and stop whining about it so much
(too many cards are like this, espeically usb/firewire cards).
o Add comments to the cis reading code.
o Made the read from config space a smidge easier to read and eliminate
a loop that can be done mathematically.
the recent changes to track BAR state explicitly. The code would now
attempt to add the same BAR twice in this case. Instead, change this so
that it recognizes this case and only adds it once and do not delete the
BAR outright after parsing the CIS.
Tested by: bschmidt
pci_delete_child() function called by the cardbus driver. The new function
uses resource_list_unreserve() to release the BARs decoded by the device
being removed.
Reviewed by: imp
Tested by: brooks
stored in a BAR since the CIS BAR is mapped before the PCI bus driver
enumerates all the BARs. Without this change, the PCI bus driver would
attempt to initialize a BAR that was already allocated resulting in a panic.
handling for the PCIR_BIOS decoding enable bit from the cardbus driver.
The PCIR_BIOS BAR does include type bits like other BARs. Instead, it is
always a 32-bit non-prefetchable memory BAR where the low bit is used as a
flag to enable decoding.
Reviewed by: imp
the PORTEN and MEMEN bits in the command register than to zero the
bars.
Use pci_write_ivar directly instead of a one-line wrapper that adds no
value.
Track verbosity changes in pci.
Remove a stray blank line.
read before we configure the card, so we can implement
/dev/cardbus*.cis. Also, do this on a per-child basis, so we now have
a different name than before. I think i'll have to fix that for some
legacy tools to keep working.
I can now do a dumpcis on my running atheros card and have it still work!
redundant malloc/free. Add comments about how this should really be
done. Fix an overly verbose comment about under 1MB mapping: go ahead
and set the bits, but we ignore them.
allocating resources to read the CIS. I'm not sure when this changed,
but it is totally wrong. Also, add a minor improvement to the
debugging.
This should help everybody trying to run dumpcis on atheros wireless
card as well.
MFC after: 2 days
right... Good thing the size was ignored...
Where this macro is used, there's no reason to do it anyway. There
seems to have been some old-time confusion between the CIS pointer
definition, and the BAR definitions at the base of this bug.
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)
because on at least my dc based cards there's garbage in there. The
recent changes in the resource code appears to have unmasked this
problem... At least dc now probes/attaches better than it did before.
Also, we no longer need to write to the cfg for the other registers.
share devclass pointers, a mistake I've encouraged in the past) and
move the declaration of the pci_driver kobj class from cardbus.c to
pci_private.h so that other drivers can inherit from pci_driver.
allocating a resource that's in the card itself.
Remove more now-redundant resource_list_add, and now-redunant code
that lives in the pci layer.
# This fixes the atheros card that I have which had its CIS in one of
# the BARs. Don't know yet if this fixes the amd64 issues reported.
