on-board, glued to the AR71xx CPU. These may forgo separate WMAC EEPROMs
(which store configuration and calibration data) and instead store
it in the main board SPI flash.
Normally the NIC reads the EEPROM attached to it to setup various PCI
configuration registers. If this isn't done, the device will probe as
something different (eg 0x168c:abcd, or 0x168c:ff??.) Other setup registers
are also written to which may control important functions.
This introduces a new compile option, AR71XX_ATH_EEPROM, which enables the
use of this particular code. The ART offset in the SPI flash can be
specified as a hint against the relevant slot/device number, for example:
hint.pcib.0.bus.0.17.0.ath_fixup_addr=0x1fff1000
hint.pcib.0.bus.0.18.0.ath_fixup_addr=0x1fff5000
TODO:
* Think of a better name;
* Make the PCIe version of this fixup code also use this option;
* Maybe also check slot 19;
* This has to happen _before_ the SPI flash is set from memory-mapped
to SPI-IO - so document that somewhere.
This was preventing the ath driver from being loaded at runtime.
It worked fine when compiled statically into the kernel but not when
kldload'ed after the system booted.
The root cause was that PCIR_INTLINE (register 60) was being
overwritten by zeros when register 62 was being written to.
A subsequent read of this register would return 0, and thus
the rest of the PCI glue assumed an IRQ resource had already
been allocated. This caused the device to fail to attach at
runtime as the device itself didn't contain any IRQ resources.
TODO: go back over the ar71xx and ar724x PCI config read/write
code and ensure it's correct.
performance issues.
* Access to the GPIO bus is already locked by requesting
and releasing the bus - thus the lock isn't really needed
for each GPIO pin change.
* Don't lock and unlock the GPIO bus for -each- i2c access -
the i2c bus code is already doing this by calling the upper
layer callback to request/release the bus. This thus locks
the bus for the entirety of the transaction.
TODO:
* Further verify that everything is correctly requesting/
releasing the GPIO bus.
* Look at how to lock the GPIO pin configuration stuff,
potentially by locking/unlocking the bus at the gpiobus
layer.
config and function mask setup.
* "gpiomask" now specifies which GPIO pins to enable, for devices to bind to.
* "function_set" allows bits in the function register to be set at GPIO setup.
* "function_clear" allows bits in the function register to be cleared at
GPIO setup.
The function_set/function_clear bits allow for individual GPIO pins to either
drive a GPIO line or an alternate function - eg USB, JTAG, etc. This allows
for things like CS1/CS2 be enabled for those boards w/ >1 SPI device connected,
or disabling JTAG for the AR7240 (which is apparently needed ..)
I've verified this on the AR71xx.
This patch should remove the need for kldunload of USB
controller drivers at suspend and kldload of USB controller
drivers at resume.
This patch also fixes some build issues in avr32dci.c
MFC after: 2 weeks
the ar71xx platform code should assume a uboot or redboot environment.
The current code gets very confused (and just crashes) on a uboot
environment, where each attribute=value pair is in a single entry.
Redboot on the other hand stores it as "attribute", "value", "attribute",
"value", ...
This allows the kernel to boot on a TP-LINK TL-WR1043ND from flash,
where the uboot environment gets setup. This didn't show up during a netboot
as "tftpboot" and "go" don't setup the uboot environment variables.
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
Because driver is accessing a common MII structure in
mii_pollstat(), updating user supplied structure should be done
before dropping a driver lock.
Reported by: Karim (fodillemlinkarimi <> gmail dot com)
(reporting IFM_LOOP based on BMCR_LOOP is left in place though as
it might provide useful for debugging). For most mii(4) drivers it
was unclear whether the PHYs driven by them actually support
loopback or not. Moreover, typically loopback mode also needs to
be activated on the MAC, which none of the Ethernet drivers using
mii(4) implements. Given that loopback media has no real use (and
obviously hardly had a chance to actually work) besides for driver
development (which just loopback mode should be sufficient for
though, i.e one doesn't necessary need support for loopback media)
support for it is just dropped as both NetBSD and OpenBSD already
did quite some time ago.
- Let mii_phy_add_media() also announce the support of IFM_NONE.
- Restructure the PHY entry points to use a structure of entry points
instead of discrete function pointers, and extend this to include
a "reset" entry point. Make sure any PHY-specific reset routine is
always used, and provide one for lxtphy(4) which disables MII
interrupts (as is done for a few other PHYs we have drivers for).
This includes changing NIC drivers which previously just called the
generic mii_phy_reset() to now actually call the PHY-specific reset
routine, which might be crucial in some cases. While at it, the
redundant checks in these NIC drivers for mii->mii_instance not being
zero before calling the reset routines were removed because as soon
as one PHY driver attaches mii->mii_instance is incremented and we
hardly can end up in their media change callbacks etc if no PHY driver
has attached as mii_attach() would have failed in that case and not
attach a miibus(4) instance.
Consequently, NIC drivers now no longer should call mii_phy_reset()
directly, so it was removed from EXPORT_SYMS.
- Add a mii_phy_dev_attach() as a companion helper to mii_phy_dev_probe().
The purpose of that function is to perform the common steps to attach
a PHY driver instance and to hook it up to the miibus(4) instance and to
optionally also handle the probing, addition and initialization of the
supported media. So all a PHY driver without any special requirements
has to do in its bus attach method is to call mii_phy_dev_attach()
along with PHY-specific MIIF_* flags, a pointer to its PHY functions
and the add_media set to one. All PHY drivers were updated to take
advantage of mii_phy_dev_attach() as appropriate. Along with these
changes the capability mask was added to the mii_softc structure so
PHY drivers taking advantage of mii_phy_dev_attach() but still
handling media on their own do not need to fiddle with the MII attach
arguments anyway.
- Keep track of the PHY offset in the mii_softc structure. This is done
for compatibility with NetBSD/OpenBSD.
- Keep track of the PHY's OUI, model and revision in the mii_softc
structure. Several PHY drivers require this information also after
attaching and previously had to wrap their own softc around mii_softc.
NetBSD/OpenBSD also keep track of the model and revision on their
mii_softc structure. All PHY drivers were updated to take advantage
as appropriate.
- Convert the mebers of the MII data structure to unsigned where
appropriate. This is partly inspired by NetBSD/OpenBSD.
- According to IEEE 802.3-2002 the bits actually have to be reversed
when mapping an OUI to the MII ID registers. All PHY drivers and
miidevs where changed as necessary. Actually this now again allows to
largely share miidevs with NetBSD, which fixed this problem already
9 years ago. Consequently miidevs was synced as far as possible.
- Add MIIF_NOMANPAUSE and mii_phy_flowstatus() calls to drivers that
weren't explicitly converted to support flow control before. It's
unclear whether flow control actually works with these but typically
it should and their net behavior should be more correct with these
changes in place than without if the MAC driver sets MIIF_DOPAUSE.
Obtained from: NetBSD (partially)
Reviewed by: yongari (earlier version), silence on arch@ and net@
of endian-ness issues with the AR724x.
From Luiz:
* Fix the bus space tag used so endian-ness is correctly handled;
* Only do the workaround for the AR7240; AR7241/AR7242 (PB92)
don't require this
From me:
* Add a read flush from openwrt
Submitted by: Luiz Otavio O Souza
This is reported to work on the AR7240 based Ubiquiti Rocket M5
but I haven't tested it on that hardware. I also don't yet have
it fully working on the AR7242 based development board here;
probe/attach functions but the register space resource looks like
the endian-ness is wrong (0x10000000 instead of 0x00001000).o
Further digging will be required.
Submitted by: Luiz Otavio O Souza
bus driver at detach, hence ehci_detach() does exactly this since r199718.
Submitted by: Luiz Otavio O Souza
MFC after: 7 days
Approved by: thompsa (mentor)
levels. TX would hang, RX wouldn't. A bit of digging showed the interface
send queue was full, but IFF_DRV_OACTIVE was clear and the hardware TX
queue was empty.
It turns out that there wasn't a check to drain the interface send
queue once hardware TX had completed, so if the interface send queue
had filled up in the meantime, subsequent packets would be dropped
by the higher layers and if_start (and thus arge_start()) would never
be called.
The fix is simple - call arge_start_locked() in the software interrupt
handler after the hardware TX queue has been handled or a TX underrun
occured. This way the interface send queue gets drained.
offset in the flash.
Some devices (eg the TPLink WR-1043ND) don't have a flash environment
partition which can be queried for the current board settings.
This particular workaround allows for image creators to use a hint
to set the base MAC address. For example:
hint.arge.0.eeprommac=0x1f01fc00
just for Redboot.
At some point we're going to need to build options for different
boot environments - for example, the UBoot setups I've seen simply
have the MAC address hard-coded at a fixed location in flash.
The OpenWRT support simply yanks the if_arge MAC directly from that
in code, rather than trying to find a uboot environment to pull it
from.
memory detected from Redboot, or overrides the "otherwise" case
if no Redboot information was found.
Some AR71XX platforms don't use Redboot (eg TP-LINK devices using
UBoot; some later Ubiquiti devices which apparently also use
UBoot) and at least one plain out lies - the Ubiquiti LS-SR71A
Redboot says there's 16mb of RAM when in fact there's 32mb.
A more "clean" solution will be needed at a later date.
The AR913x/AR724x USB lives at a different offset to the AR71xx
USB, so this needs to be either adjusted for in a subsequent
commit, or updated in hints for kernels compiled for those
platforms.
Submitted by: Luiz Otavio O Souzau <loos.br@gmail.com>
mipsel' or 'machine mips mipseb' into the config file (with a few 64's
tossed in for good measure). This will let us build the proper
kernels with different worlds as part of make universe.
