(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.
This reflects actual type used to store and compare child device orders.
Change is mostly done via a Coccinelle (soon to be devel/coccinelle)
semantic patch.
Verified by LINT+modules kernel builds.
Followup to: r212213
MFC after: 10 days
* Add a function to write to the relevant PLL register
* Break out the PLL configuration for the AR71XX into the CPU ops,
lifted from if_arge.c.
* Add the AR91XX PLL configuration ops, using the AR91XX register
definitions.
This is untested but should at least allow an AR724X to boot.
The current code is lacking the detail needed to expose the PCIe bus.
It is also lacking any NIC, PLL or flush/WB code.
This works well enough to bring a system up to single-user mode
using an MDROOT.
Known Issues:
* The EHCI USB doesn't currently work and will panic the kernel during
attach.
* The onboard ethernet won't work until the PLL routines have been
fleshed out and shoe-horned into if_arge.
* The WMAC device glue (and quite likely the if_ath support)
hasn't yet been implemented.
