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
Most calls to bus_alloc_resource() use "anywhere" as the range, with a given
count. Migrate these to use the new bus_alloc_resource_anywhere() API.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D5370
legal in the spec. Add newline to the verbose messages we print when
debugging when this happens. The Hitachi HT-4840-11 is the only card
to hit these in years, and it works well enough if we're liberal about
what we accept.
says that in such cases we can pick any interrupt. One of these cards
is the LG11 Wireless LAN card. I don't have one of these, but I do
know that this doesn't hurt any cards I've tried it with.
PR: 92070
Submitted by: Helge Oldach
MFC after: 3 days
cards stopped working. Specifically the AVM B1 PCMCIA Card no longer
detected. Its CIS chain read back as all FF's. Putting the delay
back solves those problems. I've opted to put in a much shorter delay
because as far as I can tell, no delay is really needed here. We'll
see how well this works in practice.
problems we were having properly mapping the CIS attr space on some
cards. Those problems have been solved other ways, so this kludge is
no longer necessary. Remove it and have pccards come up a whole
second faster.
scan the CIS for interesting tuples. 95% of what can be obtained from
the CIS is harvested by the pccard layer and presented to the user in
standard function calls. However, there are special needs at times
where the standard stuff doesn't suffice. This is for those special
cases.
CARD_SCAN_CIS(device_get_parent(dev), function, argp)
scans the CIS of the card, passing each tuple to function with
the tuple and argp as its arguments. Returning 0 continues the scan,
while returning 1 terminates the scan. The value of the last
invocation of function is returned from this function.
int (*pccard_scan_t)(struct pccard_tuple *tuple, void *argp)
function called for each tuple. Elements of the CIS tuple can be
read with pccard_tuple_read_{1,2,3,4,n}(). You are reading
the actual tuple memory each time, in case your card has
registers in the CIS.
# I suppose these things should be documented in pccard(4) or something like
# that.
# I plan on unifying cardbus CIS support in a similar way.
Approved by: re (scottl)
are equal to PCCARD_TPCE_FS_MEMSPACE_NONE, memspace will be zero, so
testing for this case inside of the if statement results in dead code.
We'd fail to set a value to zero that's already zero (since it is
initialized to 0 indirectly) with this code being there. Well, except
in the very rare case that we have a card that has a defualt entry
that includes a memory space followed by one that has no memory space
(these are extremely rare, I don't recall ever having seen one :-).
Fix this by setting num_memspace to 0 in a more appropriate place.
Submitted by: Coverity Prevent analysis tool
as type 0, rather than the usualy type 4. Assume that this format is
from an old standard and go with it. The Fujitsu FMV-186A and Silicom
Ethernet cards I have both have tuples with this format, and they are
both pretty old cards.
# if somebody knows for sure, please let me know.
(1) Align to 64k for the CIS. Some cards don't like it when we aren't
aligned to a 64k boundary. I can't find anything in the standard
that requires this, but I have 1/2 dozen cards that won't work at
all unless I enable this.
(2) Sleep 1s before scanning the CIS. This may be a nop, but has little
harm.
(3) The CIS can be up to 4k in some weird, odd-ball edge cases. Since we
have limiters for when that's not the case, it does no harm to increase
it to 4k.
#1 was submitted, in a different form, by Carlos Velasco.
o minor optimization of cardbus_cis processing. Remove a bunch of generic
entries that are handled by generic.
o no longer need the card_get_type stuff.
are all bogus, and the cards that don't decode things quite right
often have hundreds of them. This will fix starvation of small dmesg
buffers and allow better debugging to happen. I thought about adding
an override, but there is such a thing as too many knobs. :-)
to what is in NetBSD. I have a few cards that tickles this bug, and
this just keeps us from panicing. It doesn't actually fix the problem
(that will happen once I figure out why some cards hate the address
their CIS is mapped to high memory).
give us slightly better error checking than before and interpret what
default bits mean better. See the NetBSD CVS tree for the authors of
these changes (revs 1.10 .. 1.17).
allows us to properly parse cards with attribute memory based CIS that
before wouldn't parse correctly, sometimes with a panic. This allows
me to get my 3C562 modem/ethernet card to fail to attach due to
problems in the ep and sio drivers rather than due to problems in the
CIS parsing code :-).
We weren't setting the address to jump to for the function entries.
This caused us to only work when the addional entries were after the
first ones. On the 3C562/3C563 card this was not the case.
We were also mapping Attribute memory when common memory was asked for
in the target of the LONGLINK_{A,C} or LONGLINK_MFC.
My IBM Home And Away Modem/LAN card still fails for reasons unknown.
I've done this by having requests to allocate memory propigate up the
tree. We'll see how well this works and reevaluate if it isn't
working well. Also initialize ptr in the tuple. As well as minor
reorg of memory allocation. Likely need to do similar things for I/O
when the time comes.
I've move all defines from pccardchip.h into pccardvar.h and
eliminated pccardchip.h.
o Eliminate cross calls between the devices. Instead move to using the
newbus messaging system. Added three new card calls: attach_card,
detach_card, get_type.
o Eliminate interrupt routine in pccard we never use.
o Move from deactivate to detach for removing cards.
o Start mapping CIS memory, but it is broken and causes panics. At least
it is closer to working than before.
o Eliminate struct device everywhere. It was bogus.
o Initialize softc for pccard device so we have valid pointers to
ourselves.
o Implement routine to find the pcic ivar for a child device of the pccard so
we can use it to talk to the pcic hardware.
o Lots of minor tiding up.
This version now panics when we try to read the CIS. The next batch
of work to make this work is what was outlined in my posting to mobile
about resource allocation and such.
Pass sc->dev rather than a bogusly cast pccard_softc *sc.
This allows us to insert and remove cards w/o panicing the kernel.
However, the cis isn't mapped in, so the pccard_scan_cis function
fails.
Remove RF_PCCARD_ATTR in anticipation of removing it from sys/rman.h
Add interface for setting "attributes" of pccard/cardbus devices.
Minor formatting nits.
o ifdef out pccardchip.h (almost all of it, there are dangling bits
o Add rid/res members to pccard_function
o remove pct/pch from pccard_softc
o map memory properly in scan_cis (almost, see XXX for more work)
o manage ccr.
o remove bogus comment I added about touching the ccr being a layering
violation for pccard. It is properly done at that level.
o More function prototyping
o Implement memory and I/O activation/deactivation. irq not handled.
o switch pcic_chip functions around to use more convenient types.
o kill __P and most of the old K&R prototypes just to be mean.
o minor other nits
it would work), or a specialized one. Most of these have been
creatively stolen from pccard_nkb, which in turn stole from isa
showing that generic bus_ versions of bus_{set,get,delete}_resource
might be profitable.
Fix a couple of minor bugs introduced in the last round of updates
from NetBSD.
Start on the pccard_ivar structure which will hold the resources and
slot number.
Add tcic as a possible attachment for pccard and rename the attachment
for pcicx to pcic since the name has changed since I originally wrote
this stuff.
Next up:
stringing together the various memory and I/O
allocation/mapping primitives in i82365.c, final touches on the isa
attach routine and other fun stuff in that line of attach.
incomplete and likely has problem. The code was originally pcmcia,
but I renamed it to pccard and made it compile on FreeBSD -current. I
converted SIMPLEQ to STAILQ as well as a few sc->dev.xname ->
device_printf changes. This is a green port of fairly mature code.
I derived this work from the FreeBSD newconfig project
(http://www.jp.freebsd.org/newconfig). Any problems with it are
likely introduced by me.
Obtained from: newconfig project
