sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

cardbus: clean up empty lines in .c and .h files

Regularize my copyright notice

o Remove All Rights Reserved from my notices
o imp@FreeBSD.org everywhere
o regularize punctiation, eliminate date ranges
o Make sure that it's clear that I don't clai

Regularize my copyright notice

o Remove All Rights Reserved from my notices
o imp@FreeBSD.org everywhere
o regularize punctiation, eliminate date ranges
o Make sure that it's clear that I don't claim All Rights reserved by listing
All Rights Reserved on same line as other copyright holders (but not
me). Other such holders are also listed last where it's clear.

show more ...

1k objects on the stack are a bad idea. While it's likely safe in this
context, it's also safe to allocate the memory and free it instead.

Noticed by: Eugene Grosbein's script

sys/dev: further adoption of SPDX licensing ID tags.

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

sys/dev: further adoption of SPDX licensing ID tags.

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.

show more ...

sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

sys/dev: use our nitems() macro when it is avaliable through param.h.

No functional change, only trivial cases are done in this sweep,
Drivers that can get further enhancements will be done independ

sys/dev: use our nitems() macro when it is avaliable through param.h.

No functional change, only trivial cases are done in this sweep,
Drivers that can get further enhancements will be done independently.

Discussed in: freebsd-current

show more ...

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physic

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

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

show more ...

Partially revert 222753: If a CardBus card stores its CIS in a BAR, delete
the BAR after parsing the CIS. This forces the resource range to be
reallocated if the BAR is reused by the device.

Submit

Partially revert 222753: If a CardBus card stores its CIS in a BAR, delete
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)

show more ...

Minor cleanup:
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 r

Minor cleanup:
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.

show more ...

More properly handle Cardbus cards that that store their CIS in a BAR after
the recent changes to track BAR state explicitly. The code would now
attempt to add the same BAR twice in this case. Inst

More properly handle Cardbus cards that that store their CIS in a BAR after
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

show more ...

Fix an error case I missed in the previous change so that the CIS resource
is fully cleaned up if we fail to find the CIS in the devices ROM.

Delete the CIS resource after releasing it. This is needed when the CIS is
stored in a BAR since the CIS BAR is mapped before the PCI bus driver
enumerates all the BARs. Without this change, the PC

Delete the CIS resource after releasing it. This is needed when the CIS is
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.

show more ...

Teach the PCI bus driver to handle PCIR_BIOS BARs properly and remove special
handling for the PCIR_BIOS decoding enable bit from the cardbus driver.
The PCIR_BIOS BAR does include type bits like oth

Teach the PCI bus driver to handle PCIR_BIOS BARs properly and remove special
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

show more ...

Use bus_*() rather than bus_space_*().

Minorly improved debugging. Use the DEVPRINTF macro and report the
offset for memory when mapping in the CIS.

Overhaul of CIS parsing, next step: keep a cached copy of the CIS,
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 diff

Overhaul of CIS parsing, next step: keep a cached copy of the CIS,
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!

show more ...

First step in cleaning up CIS parsing and /dev/cardbus*.cis: remove
redundant malloc/free. Add comments about how this should really be
done. Fix an overly verbose comment about under 1MB mapping:

First step in cleaning up CIS parsing and /dev/cardbus*.cis: remove
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.

show more ...

Use child (the card) in preference to cbdev (the bridge) when
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
deb

Use child (the card) in preference to cbdev (the bridge) when
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

show more ...

gcc 4.2 thinks that tupleid is uninitialized. Or might be used
uninitialized. It gets passed into other routines that initialize
it... Cope by initializing.

Submitted by: mjacob

Change PCIM_CIS_ASI_TUPLE to _CONFIG.
Add PCI_MAX_BAR_0
minor style nit.
Add PCIM_CIS_CONFIG_MASK

Minor cleanup of CIS parsing.

Better error message when the CIS is a non-standards conforming '0'.

Use the child to allocate the resource rather than bridge, since we're
allocating a resource that's in the card itself.

Remove more now-redundant resource_list_add, and now-redunant code
that lives

Use the child to allocate the resource rather than bridge, since we're
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.

show more ...