controller - no matter if we are called from attach or not.
This makes my FreeCOM CD drive work at first attach (PR 13480).
Something is wrong with the detach code; it won't work on second attach
and will panic on second detach - but that has to wait until the kids
took care of some easter eggs.
(de)activate for pcmcia cards.
Implement detach/(de)activate for PCI cards.
Clean up internal state (free call-descriptors) if a controller is
detached while it has open connections.
and move them in their proper places.
Move the BRI registry from layer 2 (duh!) to layer 4, so active cards
(which don't have layer 3 or layer 2 in their driver). Remove all remaining
hard coded controller and driver types. Remove any arbitrary hard coded
limits, at least those that show up in the internal API.
This fixes PR 15950.
for the registers, which was true, but actually the same as the driver
did without this option.
What it realy did is work around a stupid bug in the driver that did not
use the "offset" result from the pcmcia_mem_map call mapping the CIS memory.
We got away with this for a long time since on i386 and typical pcmcia
bridged the offset returned will be 0. It always failed (without
RAY_USE_AMEM=1) if the check for a different function CCR aliases in pcmcia.c
failed and mapped the CCR base new - this time at the CCR base of this
function (0xf00), so all register acceses (that had 0xf00 added) happened
way off in neverland.
Now we do not hardcode the CCR base to the register definitions, but
instead use the offset returned by pcmcia_mem_map. This makes the driver
work with and without CCR base aliases being found.
not support a value (e.g., it's to be used as "options FOO" instead of
"options FOO=xxx"). options that take a value were converted to
defparam recently.
- minor whitespace & formatting cleanups
o Add devices from OpenBSD
o Minor sorting problems in my sorting attempt.
o A few additional -1 vendors for better card pattern generation.
o Add Zoom Air_4000 (needs to be added to awi)
o Add Netgear FA411 info (needs to be added to ne, plus quirks/fixes
to base pccard stuff before it will work).
o Merges through FreeBSD 1.22
of my Xircom RealPort Ethernet 10/100 + Modem (REM56G) work.
The modem part is still not usable (this would need some PCMCIA magic that
I don't know how to do; see my message to tech-kern on Oct 07).
Change to pcmcia_cis.c from OpenBSD.
I checked that this doesn't break a 3com 3C562D (ethernet+modem) which I
also have.
time. Vendors are sorted by number. Vendors are grouped
alphabetically, with entries within a vendor's group arranged
numerically. CIS entries sorted alphabetically by identifier.
I have a weird PC-card-style appliance (I'm not sure I may call it a PC card)
whose ``CIS'' reads zeros forever, which caused kernel panic.
For your interest, it is a cooling fan to be inserted to a PC card slot.
if_ieee80211subr.c, which can be shared between any IEEE 802.11
drivers.
However, most of current working IEEE 802.11b wireless LAN cards
have rich firmware and we cannot have a control to management frames
for such cards.
IBSS creation is now supported for the awi driver.
* teach it to read the MAC addr from the correct place (from OpenBSD)
* change order of intr_dis/establish() and function_en/disable() to
avoid panics on this multifunction card due to the CCR window
not being mapped in intr_dis/establish()
- data alignment fix
- kludge around broken multicast by using promisc mode
(IPv6 router solicitation now works)
- add support as random source
- support device power-up and power-down
- vlan support
- misc. comment and style fixes
Roaming mode can change value into 'firm mode' and disable.
Authentication mode can change into 'Open System authentication'
and 'Shared Key Authentication' with Prism2 chip.
wi_get_id() was introduced in order that chip might judge automatically
whether it is Prism2 chip. Therefore, a pp_prism2 entry in
"struct wi_pcmcia_product" became unnecessary.
This is a completely rewritten scsipi_xfer execution engine, and the
associated changes to HBA drivers. Overview of changes & features:
- All xfers are queued in the mid-layer, rather than doing so in an
ad-hoc fashion in individual adapter drivers.
- Adapter/channel resource management in the mid-layer, avoids even trying
to start running an xfer if the adapter/channel doesn't have the resources.
- Better communication between the mid-layer and the adapters.
- Asynchronous event notification mechanism from adapter to mid-layer and
peripherals.
- Better peripheral queue management: freeze/thaw, sorted requeueing during
recovery, etc.
- Clean separation of peripherals, adapters, and adapter channels (no more
scsipi_link).
- Kernel thread for each scsipi_channel makes error recovery much easier
(no more dealing with interrupt context when recovering from an error).
- Mid-layer support for tagged queueing: commands can have the tag type
set explicitly, tag IDs are allocated in the mid-layer (thus eliminating
the need to use buggy tag ID allocation schemes in many adapter drivers).
- support for QUEUE FULL and CHECK CONDITION status in mid-layer; the command
will be requeued, or a REQUEST SENSE will be sent as appropriate.
Just before the merge syssrc has been tagged with thorpej_scsipi_beforemerge
saves about 2.2MB under /usr/include/dev/. Discussed on tech-kern@
recently.
I HOPE to get the list right. The headers I left in are ones
used for MI tools and those whose usage I discovered by grep over tree sources.
Feel free to put needed includes back in if you encounter anything which
should not be removed from lists.
This now provides slightly more functionality than the FreeBSD layer1-newbus
interface. It was meant to be a simple change to one header and a few
c files, but the change rippled all through various stuff.
To prevent a change to the kernel<->userland interface right now the kernel
is now lying about card types to userland (but who cares). This will be fixed
when the userland interface changes, after layer 3 <-> layer 4 has been
fixed.
Functional changes:
Provide a clean interface for hardware drivers to attach to the upper
layers. This will need another small change in the B-channel handling
when a similar change to the layer 3 <-> layer 4 interface happens.
Avoid passing indices into global arrays of pointers around, instead pass
the pointers itself. Don't code hardware driver types by predefined magic
numbers (think LKM). Prepare for detachable drivers (think pcmcia).
While there remove some sets of function pointers always pointing to the
same function (meant to be the configurable set of D channel protocol
handlers). It is unlikely another supported D-channel protocol will fit into
that (maximal layer interface) abstraction. When we get support for another
protocol, we will need to come up with a workable interface. Besides, the
old implementation was, uhm, strange.
remove all (legacy) "i4b_" prefixes outside of sys/netisdn.
Prefix all card specific driver support files with the basename
of the driver bus attachement file.
Renamed here:
i4b_isic_pcmcia.c -> isic_pcmcia.c
i4b_isic_pcmcia.h -> isic_pcmcia.h
i4b_avm_fritz_pcmcia.c -> isic_pcmcia_avm_fritz.c
i4b_elsa_isdnmc.c -> isic_pcmcia_elsa_isdnmc.c
i4b_elsa_mcall.c -> isic_pcmcia_elsa_mcall.c
i4b_sbspeedstar2.c -> isic_pcmcia_sbspeedstar2.c
Don't allocate one large io range, this fails about every time on real
pcmcia buses (not attached to pci/cardbus bridges) because of other
devices interfering in that range. Use the bogusly small region for
now, which works purely by chance (map granularity) on cardbus bridges
too (more or less).
XXX - make this map three different, small regions after layer1 <-> layer2
XXX interface has been brought in shape.
places into the CIS reading code.
The card in question has IO8 only enabled in its CIS info and is apparently
not able to keep up with quick reads. It words fine in a pcmcia slot but
panics(!) the kernel in a TI 1250 cardbus slot. This may be a failure of
the pci cardbus code when initializing this bridge. When finding (and
fixing) that, we should back this change out.
The card I am testing with is not broken, I have multiple versions of it
(AVM Fritz! pcmcia ISDN card), all work fine on windows and all cause
us to panic because of bogus CIS info read.
XXX - panicing because of bogus CIS data is probably another error.
martin