This clears out my outstanding netgraph changes.
There is a netgraph change of design in the offing and this is to some
extent a superset of soem of the new functionality and some of the old
functionality that may be removed.
This code works as before, but allows some new features that I want to
work with and evaluate. It is the basis for a version of netgraph
with integral locking for SMP use.
This is running on my test machine with no new problems :-)
- Move PCI core code to dev/pci.
- Split bridge code out into separate modules.
- Remove the descriptive strings from the bridge drivers. If you
want to know what a device is, use pciconf. Add support for
broadly identifying devices based on class/subclass, and for
parsing a preloaded device identification database so that if
you want to waste the memory, you can identify *anything* we know
about.
- Remove machine-dependant code from the core PCI code. APIC interrupt
mapping is performed by shadowing the intline register in machine-
dependant code.
- Bring interrupt routing support to the Alpha
(although many platforms don't yet support routing or mapping
interrupts entirely correctly). This resulted in spamming
<sys/bus.h> into more places than it really should have gone.
- Put sys/dev on the kernel/modules include path. This avoids
having to change *all* the pci*.h includes.
place the LOCKing macros within the areas within if_wxvar.h that
is set aside for them. Put any platform specific data also in those
areas.
For ease of maintenance purposes, merge in the OpenBSD version codebase here.
on. So stop failing the attach if the IRQ is unassigned. With this
patch, I can now boot with PNP-OS YES in my BIOS no differently than
PNP-OS NO (which is a good thing since Windows hangs with PNP-OS NO).
Obtained from: msmith
like the args to the config space accessors these functions replaced.
This reduces the likelyhood of overflow when the args are used in
macros on the alpha. This prevents memory management faults when
probing the pci bus on sables, multias and nonames.
Approved by: dfr
Tested by: Bernd Walter <ticso@cicely8.cicely.de>
the interface to use callout_* instead of timeout(). Also add an
IS_MPSAFE #define (currently off) which will mark the driver as mpsafe
to the upper layers.
before adding/removing packets from the queue. Also, the if_obytes and
if_omcasts fields should only be manipulated under protection of the mutex.
IF_ENQUEUE, IF_PREPEND, and IF_DEQUEUE perform all necessary locking on
the queue. An IF_LOCK macro is provided, as well as the old (mutex-less)
versions of the macros in the form _IF_ENQUEUE, _IF_QFULL, for code which
needs them, but their use is discouraged.
Two new macros are introduced: IF_DRAIN() to drain a queue, and IF_HANDOFF,
which takes care of locking/enqueue, and also statistics updating/start
if necessary.
(identified by the IO map being 256 bytes long instead of 128)
This chip works very unreliably on my Lanner embedded PC with the rl driver.
Lots of watchdog timeouts or poor performance.
Forcing the media type to 10 Meg (ifconfig rl0 media 10baseT/UTP) is a good
workaround.
This looks very similar to the problem reported in PR kern/18790
It is interesting to note that the linux driver has lots of special
case code for this chip.
is already in 32-bit mode, we need to be able to detect this and still
read the chip ID code. Detecting 32-bit mode is actually a little
tricky, since we want to avoid turning it on accidentally. The easiest
way to do it is to just try and read the PCI subsystem ID from the
bus control registers using 16-bit accesses and compare that with the
value read from PCI config space. If they match, then we know we're in
16-bit mode, otherwise we assume 32-bit mode.
16-bit mode. Technically, pcn_probe() is destructive because once the
chip goes into 32-bit mode, the only way to get it out again is a
hardware reset. And once the device is in 32-bit mode, the lnc driver
won't be able to talk to it. So if pcn_probe() is called before the
lnc probe routine, and pcn_probe() rejects the chip as one it doesn't
support, the lnc driver will be SOL.
I don't like this. I think it's a design flaw that you can't switch
the chip out of 32-bit mode once it's selected. The only 'right'
solution is for the pcn driver to support all of the PCI devices
in 32-bit mode, however I don't have samples of all the PCnet series
cards for testing.
pollution in <sys/mutex.h>. This was half fixed in rev.1.3 of
midwayreg.h. The pollution exposed the bug that this driver was using
toy versions of the bus space macros under FreeBSD. Disabling the
toy versions made this driver compile but dependent on the pollution.
There was still a toy version of bus_space_read_1() in unreachable code.
and nobroadcast bits in the mode register and call it both from
pcn_init() and pcn_ioctl(). Sometimes we need to force the state
of the nobroadcast bit after switching out of promisc mode.
them. If we leave garbage in them, the dc_apply_fixup() routine may
try to follow bogus pointers when applying the reset fixup.
Noticed by: Andrew Gallatin
- Add DRIVER_MODULE() declaration to make this driver a
child of cardbus
- Handle different width EEPROMs
The CIS parser still barfs when scanning this card, but it seems to
probe/attach correctly anyway. I can't do a traffic test just yet
since I don't have a proper crossover cable handy.
the offending inline function (BUF_KERNPROC) on it being #included
already.
I'm not sure BUF_KERNPROC() is even the right thing to do or in the
right place or implemented the right way (inline vs normal function).
Remove consequently unneeded #includes of <sys/proc.h>
command register is too aggressive. Revert to the previous behaviour, but
leave the new behaviour available as an undocumented option. It's not
clear what the Right, Right Thing is to do here, but the more conservative
approach is safer.
a RealTek 8139 cardbus device. Unfortunately it doesn't quite work yet
because the CIS parser barfs on it.
Submitted by msmith, with some small tweaks by me.
because it only takes a struct tag which makes it impossible to
use unions, typedefs etc.
Define __offsetof() in <machine/ansi.h>
Define offsetof() in terms of __offsetof() in <stddef.h> and <sys/types.h>
Remove myriad of local offsetof() definitions.
Remove includes of <stddef.h> in kernel code.
NB: Kernelcode should *never* include from /usr/include !
Make <sys/queue.h> include <machine/ansi.h> to avoid polluting the API.
Deprecate <struct.h> with a warning. The warning turns into an error on
01-12-2000 and the file gets removed entirely on 01-01-2001.
Paritials reviews by: various.
Significant brucifications by: bde
the PCI latency timer value to 0x80. Davicom's Linux driver does this,
and it drastically reduces the number of TX underruns in my tests. (Note:
this is done only for the Davicom chips. I'm not sure it's a good idea to
do it for all of them.)
Again, still waiting on confirmation before merging to stable.
DM9100/DM9102 chips. Do not set DC_TX_ONE. The DC_TX_USE_TX_INTR flag
causes dc_encap() to set the 'interrupt on TX completion' bit only
once every 64 packets. This is an attempt to reduce the number
of interrupts generated by the chip. You're supposed to get a 'no more
TX buffers left' interrupt once you hit the last packet whether you
ask for one or not, however it seems the Davicom chip doesn't generate
this interrupt, or at least it doesn't generate it under the same
circumstances. The result is that if you transmit n packets, where
n is less than 64, and then wait 5 seconds, you'll get a watchdog
timeout whether you want one or not. The DC_TX_INTR_ALWAYS causes
dc_encap() to request an interrupt for every frame.
I'm still waiting on confirmation from a couple of users to see if this
fixes their problems with the Davicom DM9102 before I merge this into
-stable, but this fixed the problem for me in my own testing so I'm
willing to make the change to -current right away.
Have if_ti stop "hiding" the softc pointer in the buffer region. Rather,
use the available void * passed to the free routine and pass the softc
pointer through there.
To note: in MEXTADD(), TI_JUMBO_FRAMELEN should probably be TI_JLEN. I left it
unchanged, because this way I'm sure to not damage anything in this respect...
This commit adds support for Xircom X3201 based cardbus cards.
Support for the TDK 78Q2120 MII is also added.
IBM Etherjet, Intel and Xircom cards uses these chips.
Note that as a result of this commit, some Intel/DEC 21143 based cardbus
cards will also attach, but not get link. That is being looked at.
rather than all the flags. This prevents setting being read from ROM,
which is a problem. If this breaks anything, it will only break the
3C556B cards minipci cards, which mainly exist at rpi as far as rpi
has been able to tell.
Submitted by: Louis Gerbarg <gerbal@rpi.edu>
#ifdef away the offending code until somebody with more newbus fu than
me can figure out where to put a default function that returns 255
without touching each alpha chipset driver..
takes care of all the 10/100 and gigE PCI drivers that I've done.
Next will be the wireless drivers, then the USB ones. I may pick up
some stragglers along the way. I'm sort of playing this by ear: if
anyone spots any places where I've screwed up horribly, please let me
know.
of the Am79c973 with "AlertIT Technology," whatever that is. Also mention
support for the PCnet/FAST III cards in the documentation. The
PCnet/FAST III chips have integrated 10/100 PHYs.
adapters. This is necessary in order to make this driver work with
the built-in ethernet on the alpha Miata machines. These systems
have a 21143-PC chip on-board and optional daughtercards with either
a 10/100 MII transceiver or a 10baseT/10base2 transceiver. In both
cases, you need to twiddle the GPIO bits on the controller in order
to turn the transceivers on, and you have to read the media info
from the SROM in order to find out what bits to twiddle.
Add lockdestroy() and appropriate invocations, which corresponds to
lockinit() and must be called to clean up after a lockmgr lock is no
longer needed.
this just involves adding the chip ID to the supported list: the PCnet/PRO
is compatible with the PCnet/FAST+ and friends and should "just work"
with this driver.
Also try to handle mbuf allocation failures in the receive handler
more gracefully.
i386/isa/pcibus.c. This gets -current running again on multiple host->pci
machines after the most recent nexus commits. I had discussed this with
Mike Smith, but ended up doing it slightly differently to what we
discussed as it turned out cleaner this way. Mike was suggesting creating
a new resource (SYS_RES_PCIBUS) or something and using *_[gs]et_resource(),
but IMHO that wasn't ideal as SYS_RES_* is meant to be a global platform
property, not a quirk of a given implementation. This does use the ivar
methods but does so properly. It also now prints the physical pci bus that
a host->pci bridge (pcib) corresponds to.
a result of mii_phy_probe()) and use that rather than hardcoding a
constant. The hardcoded way was too specific to the particular card
I had and caused PHY probing to fail on at least one laptop with a
built-in AMD chip.
Reported by: rjk@grauel.com (Richard J Kuhns)
Previously, these cards were supported by the lnc driver (and they
still are, but the pcn driver will claim them first), which is fine
except the lnc driver runs them in 16-bit LANCE compatibility mode.
The pcn driver runs these chips in 32-bit mode and uses the RX alignment
feature to achieve zero-copy receive. (Which puts it in the same
class as the xl, fxp and tl chipsets.) This driver is also MI, so it
will work on the x86 and alpha platforms. (The lnc driver is still
needed to support non-PCI cards. At some point, I'll need to newbusify
it so that it too will me MI.)
The Am79c978 HomePNA adapter is also supported.
