Commit Graph

336 Commits

Author SHA1 Message Date
Hans Petter Selasky
d3bf5efc1f Fix device delete child function.
When detaching device trees parent devices must be detached prior to
detaching its children. This is because parent devices can have
pointers to the child devices in their softcs which are not
invalidated by device_delete_child(). This can cause use after free
issues and panic().

Device drivers implementing trees, must ensure its detach function
detaches or deletes all its children before returning.

While at it remove now redundant device_detach() calls before
device_delete_child() and device_delete_children(), mostly in
the USB controller drivers.

Tested by:		Jan Henrik Sylvester <me@janh.de>
Reviewed by:		jhb
Differential Revision:	https://reviews.freebsd.org/D8070
MFC after:		2 weeks
2016-10-17 10:20:38 +00:00
Adrian Chadd
7c12b677f5 [ar531x] add initial port for the AR231x/531x series of SoCs.
These are older MIPS4kc parts from Atheros.  They typically ran at
sub-200MHz and have 11bg, 11a, or 11abg wifi MAC/PHYs integrated.

This port is the initial non-wifi pieces required to bring up the
chip.  I'll commit the redboot and other pieces later, and then
hopefully(!) wifi support will follow.

Submitted by:   Mori Hiroki <yamori813@yahoo.co.jp>
Differential Revision:  https://reviews.freebsd.org/D7237
2016-10-04 16:27:36 +00:00
Adrian Chadd
ab9df3af7f [arge] add some extra MDIO debugging support
* add an ANY debug level which will always echo the message if debugging
  is compiled in;
* log MDIO transaction timeouts if debugging is compiled in;
* the argemdio device is different to arge, so turning on MDIO debugging
  flags in arge->sc_debug doesn't help.  Add a debug sysctl to argemdio
  as well so that MDIO transactions can be debugged.

Tested:

* AR9331
2016-08-05 17:16:35 +00:00
Adrian Chadd
accdd12e71 [ar71xx_gpio] handle AR934x and QCA953x GPIO OE polarity.
For reasons I won't comment on, the AR934x and QCA953x GPIO_OE register
value is inverted - bit set == input, bit clear == output.

So, fix this in the output setting, in reading the initial state from
the boot loader, and also setting any gpiofunc pins that are necessary.
2016-07-31 06:51:34 +00:00
Landon J. Fuller
ff29b85a34 Replace mips/sentry5 with mips/broadcom
The delta between SENTRY5 and BCM was already small due to BCM being
derived from SENTRY5; re-integrating the two avoids the maintenance
overhead of keeping them both in sync with bhnd(4) changes.


- Re-integrate minor SENTRY5 deltas in bcm_machdep.c
- Modify uart_cpu_chipc to allow specifying UART debug/console flags via
  kenv and device hints.
- Switch SENTRY5 to std.broadcom
- Enabled CFI flash support for SENTRY5

Reviewed by:	Michael Zhilin <mizkha@gmail.com> (Broadcom MIPS support)
Approved by:	re (gjb), adrian (mentor)
Differential Revision:	https://reviews.freebsd.org/D6897
2016-06-25 04:34:54 +00:00
Edward Tomasz Napierala
300be80084 Remove NULL checks after M_WAITOK allocations from sys/mips/.
Reviewed by:	adrian@
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D6301
2016-05-11 09:42:24 +00:00
Pedro F. Giffuni
4ed3c0e713 sys: Make use of our rounddown() macro when sys/param.h is available.
No functional change.
2016-04-30 14:41:18 +00:00
Pedro F. Giffuni
7b6cea2b01 mips: for pointers replace 0 with NULL.
These are mostly cosmetical, no functional change.

Found with devel/coccinelle.

Reviewed by:	adrian
2016-04-15 14:26:24 +00:00
Justin Hibbits
f8fd3fb518 Fix the resource_list_print_type() calls to use uintmax_t.
Missed a bunch from r297000.
2016-03-22 22:25:08 +00:00
Justin Hibbits
da1b038af9 Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.
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
2016-03-18 01:28:41 +00:00
Svatopluk Kraus
a1e1814d76 As <machine/pmap.h> is included from <vm/pmap.h>, there is no need to
include it explicitly when <vm/pmap.h> is already included.

Reviewed by:	alc, kib
Differential Revision:	https://reviews.freebsd.org/D5373
2016-02-22 09:02:20 +00:00
Justin Hibbits
7915adb560 Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.
This simplifies checking for default resource range for bus_alloc_resource(),
and improves readability.

This is part of, and related to, the migration of rman_res_t from u_long to
uintmax_t.

Discussed with:	jhb
Suggested by:	marcel
2016-02-20 01:32:58 +00:00
Michal Meloun
cdf4ec6873 EHCI: Make core reset and port speed reading more generic.
Use driver settable callbacks for handling of:
- core post reset
- reading actual port speed

Typically, OTG enabled EHCI cores wants setting of USBMODE register,
but this register is not defined in EHCI specification and different
cores can have it on different offset.

Also, for cores with TT extension, actual port speed must be determinable.
But again, EHCI specification not covers this so this patch provides
function for two most common variant of speed bits layout.

Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D5088
2016-01-28 14:11:59 +00:00
Justin Hibbits
2dd1bdf183 Convert rman to use rman_res_t instead of u_long
Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources.  For
now, this is still compatible with u_long.

This is step one in migrating rman to use uintmax_t for resources instead of
u_long.

Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.

This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.

Reviewed By: jhb
Sponsored by:	Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
Adrian Chadd
50bf167022 Fix missing path conversion from the previous commit to shuffle mdio around.
It turns out the recent work to cut down the number of atheros kernels built
didnt include one with ARGE_MDIO defined..
2015-12-27 07:39:44 +00:00
Adrian Chadd
191f543e29 [qca953x] remove unneeded initialisation.
This was copied from another chip file and it's not required on Honeybee.

Tested:

* AP143, QCA9531 SoC.

Obtained from: OpenWRT
2015-12-15 04:45:00 +00:00
Adrian Chadd
2365b69ef7 [ar71xx] always count interrupts, spurious or otherwise.
This aids in debugging.
2015-12-15 04:44:06 +00:00
Adrian Chadd
ae3f04a5df [arge] add a comment about needing mdio busses in order to use the interface.
This is a holdover from how reset is handled in the ARGE_MDIO world.
You need to define the mdio bus device if you want to use the ethernet
device or the arge setup path doesn't bring the MAC out of reset.
2015-12-15 04:43:28 +00:00
Adrian Chadd
27ddeed4a3 Add QCA9533 to the list of SoCs that require IRQ's be ACKed. 2015-11-16 06:15:01 +00:00
Adrian Chadd
d6141d33bc Add initial support for the QCA953x ("Honeybee") from Qualcomm Atheros.
The QCA953x SoC is an integrated 2x2 2GHz 11n + MIPS24k core, with
a 5 port FE switch, gige WAN port, and all the same stuff you'd find on
its predecessor - the AR9331.

However, buried deep in here somewhere is also a PCIe EP/RC for various
applications and some other weird bits I don't yet know about.

This is enough to get the reference board up and booting.  I haven't yet
had it pass lots of packets - I need to finalise the ethernet switch
bits and the GMAC configuration (ie, how the ethernet ports and switch
are wired up) and I'll bring that in when I commit the base configuration
files to use the thing.

The wifi stuff will come much later.  I have to port that support from
Linux ath9k and extend our vendor HAL to support it.

The reference board (AP143) comes with 32MB RAM and 4MB flash, so in order
to use it I need to get USB working fully so I can run root from there.

Thankyou to Qualcomm Atheros for access to the reference design board.

Details:

* Add register definitions from openwrt;
* It looks like a QCA955x but shrunk down to a QCA933x footprint, so
  use the QCA955x bits and fix up the clock detection code to do the
  QCA953x bits (they're very subtly different);
* Teach GPIO about it;
* Teach EHCI about it;
* Teach if_arge about it;
* Teach the CPU detection code about it.

Tested:

* AP143, QCA9533v2 SoC

Obtained from:	Linux, Linux OpenWRT
2015-11-16 04:28:00 +00:00
Adrian Chadd
3036d0128e Remove this; it's also in sys/conf/files.mips. 2015-11-03 21:03:26 +00:00
Adrian Chadd
f17acb5fbe arge_mdio: fix barriers; correctly check MII indicator register.
* use barriers in a slightly better fashion.  You can blame this
  glass of whiskey on putting barriers in the wrong spot.  Grr adrian.

* steal/rewrite the mdio busy check from ag7100 from openwrt and
  refactor the existing code out.  This is .. more correct.

This seems to fix the boot-to-boot variation that I've been seeing
and it quietens the switch port status flapping.

Tested:

* QCA9558 SoC (AP135.)

Obtained from:	Linux OpenWRT
2015-10-30 23:59:52 +00:00
Adrian Chadd
78e1370bbc arge: fix barrier macro. 2015-10-30 23:57:20 +00:00
Adrian Chadd
29f88ae706 arge: attempt to close a transmit race by only enabling the descriptor at the end of setup.
This driver and the linux ag71xx driver both treat the transmit ring
as a circular linked list of descriptors.  There's no "end" pointer
that is ever NULL - instead, it expects the MAC to hit a finished
descriptor (ARGE_DESC_EMPTY) and stop.

Now, since it's a circular buffer, we may end up with the hardware
hitting the beginning of our multi-descriptor frame before we've finished
setting it up. It then DMA's it in, starts sending it, and we finish
writing out the new descriptor.  The hardware may then write its
completion for the next descriptor out; then we do, and when we next
read it it'll show up as "not done" and transmit completion stops.

This unfortunately manifests itself as the transmit queue always
being active and a massive TX interrupt storm.  We need to actively
ACK packets back from the transmit engine and if we don't (eg because
we think the transmit isn't finished but it is) then the unit will
just keep generating interrupts.

I hit this finally with the below testing setup.  This fixed it for me.

Strictly speaking I should put in a sync in between writing out all of
the descriptors and writing out that final descriptor.

Tested:

* QCA9558 SoC (AP135 reference board) w/ arge1 + vlans acting as a
  router, and iperf -d (tcp, bidirectional traffic.)

Obtained from:	Linux OpenWRT (ag71xx_main.c.)
2015-10-30 23:18:02 +00:00
Adrian Chadd
70487bd29b arge: just use 1U since it's a 32 bit unsigned destination value. 2015-10-30 23:09:08 +00:00
Adrian Chadd
a73d5cc09f arge: do an explicit flush between updating the TX ring and starting transmit.
The MIPS busdma sync operations currently are a big no-op on coherent memory.
This isn't strictly correct behaviour as we need a SYNC in here to ensure that
the writes have finished and are visible in main memory before the MMIO accesses
occur.  This will have to be addressed in a later commit.

But, before that happens, let's at least do a flush here to make things
more "correct".

This is required for even remotely sensible behaviour on mips74k with
write-through memory enabled.
2015-10-30 23:07:32 +00:00
Adrian Chadd
ab2477c2c1 arge_mdio: add explicit read barriers for MDIO_READs.
The mips74k programmers guide notes that reads can be re-ordered, even
uncached ones, so we need an explicit SYNC between them.

Yes, this is a case of a driver author actively doing a bus barrier
operation.

This ends up being necessary when the mips74k core is run in write-back
mode rather than write-through mode.  That's coming in an upcoming
commit.

Tested:

* mips74k, QCA9558 SoC (AP135 reference board), arge<->arge interface
  routing traffic tests.
2015-10-30 23:00:47 +00:00
Adrian Chadd
47ed24efe2 arge: ensure there's enough space in the TX ring before attempting to
send frames.

This matches the other check for space.

"enough" is a misnomer, for "reasons".  The biggest reason is that
the TX ring is actually a circular linked list, with no head/tail pointers.
This is just a bit more headroom between head/tail so we have time to
schedule frames before we hit where the hardware is at.

Ideally this would be tunable and a little larger.
2015-10-30 22:55:41 +00:00
Adrian Chadd
3b8a3b85eb arge: do a read-after-write on all arge register writes, not just MDIO writes.
This flushes out the write to the system before anything continues.

The mips74k guide, chapter 3.3.3 (write gathering) notes that writes
can be buffered in FIFOs - even uncached ones - so we can't guarantee
the device has felt its effects.  Now, since we're all lazy driver
authors and don't pepper read/write barriers everywhere, fake it here.

tested:

* mips74k - QCA9558 SoC (AP135 reference board)
2015-10-30 22:53:30 +00:00
Adrian Chadd
948457f1be Oops - use the wrong array offset. 2015-10-28 23:39:33 +00:00
Adrian Chadd
3ea1870967 Add some debugging code (under ARGE_DEBUG) that counts each interrupt source.
This should make it easier to track down interrupt storms from arge.

Tested:

* AP135 (QCA955x) SoC - defaults to ARGE_DEBUG enabled
* Carambola2 (AR9331 SoC) - defaults to ARGE_DEBUG disabled
2015-10-28 05:11:06 +00:00
Adrian Chadd
141a008498 arge(4): flip this on for AR9344 SoCs.
I couldn't test arge0->arge1 bridging, only arge0 VLAN bridging.
The DIR-825C1 only hooks up arge0 to the switch GMAC0 and so
you need to abuse VLANs to test.

Tested:

* DIR-825C1 (AR9344)
2015-10-24 22:37:59 +00:00
Adrian Chadd
73f96038d2 arge: use 1-byte TX and RX alignment for AR9330/AR9331.
This part seems to work bug-free with single byte TX/RX buffer alignment.

This drops the CPU requirement to bridge 100mbit iperf from 100% CPU
to ~ 50% CPU.

Tested:

* AP121 (AR9330) SoC, highly magic netbooted kernel + USB rootfs
  due to 4mb flash, 16mb RAM; doing bridging between arge0 and arge1.

Notes:

* Yes, I likely can also turn this on for the AR934x SoC family now.

  But since hardware design apparently follows similar branching
  strategies to software design, I'll go and make sure all the AR934x's
  that made it out into shipping products work before I flip it on.
2015-10-22 08:02:27 +00:00
Adrian Chadd
c358c04640 arge: Remove the debugging printf that snuck in.
This was triggering when using it as an AP bridge rather than an ethernet
bridge.

The code is unclear but it works; I'll fix it to be clearer and test
performance at a later stage.
2015-10-21 05:52:04 +00:00
Adrian Chadd
240de6998b arge: don't do the rx fixup copy and just offset the mbuf by 2 bytes
The existing code meets the "alignment" requirement for the l3 payload
by offsetting the mbuf by uint64_t and then calling an rx fixup routine
to copy the frame backwards by 2 bytes.  This DWORD aligns the
L3 payload so tcp, etc doesn't panic on unaligned access.

This is .. slow.

For arge MACs that support 1 byte TX/RX address alignment, we can do
the "other" hack: offset the RX address of the mbuf so the L3 payload
again is hopefully DWORD aligned.

This is much cheaper - since TX/RX is both 1 byte align ready (thanks
to the previous commit) there's no bounce buffering going on and there
is no rx fixup copying.

This gets bridging performance up from 180mbit/sec -> 410mbit/sec.
There's around 10% of CPU cycles spent in _bus_dmamap_sync(); I'll
investigate that later.

Tested:

* QCA955x SoC (AP135 reference board), bridging arge0/arge1
  by programming the switch to have two vlangroups in dot1q mode:

# ifconfig bridge0 inet 192.168.2.20/24
# etherswitchcfg config vlan_mode dot1q
# etherswitchcfg vlangroup0 members 0,1,2,3,4
# etherswitchcfg vlangroup1 vlan 2 members 5,6
# etherswitchcfg port5 pvid 2
# etherswitchcfg port6 pvid 2
# ifconfig arge1 up
# ifconfig bridge0 addm arge1
2015-10-21 01:41:18 +00:00
Adrian Chadd
9919dec83c if_arge: fix up TX workaround; add TX/RX requirements for busdma; add stats
The early ethernet MACs (I think AR71xx and AR913x) require that both
TX and RX require 4-byte alignment for all packets.

The later MACs have started relaxing the requirements.

For now, the 1-byte TX and 1-byte RX alignment requirements are only for
the QCA955x SoCs.  I'll add in the relaxed requirements as I review the
datasheets and do testing.

* Add a hardware flags field and 1-byte / 4-byte TX/RX alignment.
* .. defaulting to 4-byte TX and 4-byte RX alignment.
* Only enforce the TX alignment fixup if the hardware requires a 4-byte
  TX alignment.  This avoids a call to m_defrag().
* Add counters for various situations for further debugging.
* Set the 1-byte and 4-byte busdma alignment requirement when
  the tag is created.

This improves the straight bridging performance from 130mbit/sec
to 180mbit/sec, purely by removing the need for TX path bounce buffers.

The main performance issue is the RX alignment requirement and any RX
bounce buffering that's occuring.  (In a local test, removing the RX
fixup path and just aligning buffers raises the performance to above
400mbit/sec.

In theory it's a no-op for SoCs before the QCA955x.

Tested:

* QCA9558 SoC in AP135 board, using software bridging between arge0/arge1.
2015-10-18 00:59:28 +00:00
Bjoern A. Zeeb
5f3a15445d Remove more unused variables leading to compile time errors. 2015-09-17 12:04:41 +00:00
Bjoern A. Zeeb
b7c61ac8b7 Remove unused variable leading to compile errors. 2015-09-17 06:07:49 +00:00
Zbigniew Bodek
18c72666ce Add domain support to PCI bus allocation
When the system has more than a single PCI domain, the bus numbers
are not unique, thus they cannot be used for "pci" device numbering.
Change bus numbers to -1 (i.e. to-be-determined automatically)
wherever the code did not care about domains.

Reviewed by:   jhb
Obtained from: Semihalf
Sponsored by:  The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3406
2015-09-16 23:34:51 +00:00
Adrian Chadd
85b543e06d Populate hw.model with the CPU model information.
Now you see something like:

# sysctl hw.model
hw.model: Atheros AR9330 rev 1

Tested:

* Carambola 2, AR9331 SoC
2015-07-14 05:14:10 +00:00
Adrian Chadd
c37904e8ba Reshuffle all of the DDR flush operations into a single switch/mux,
and start teaching subsystems about it.

The Atheros MIPS platforms don't guarantee any kind of FIFO consistency
with interrupts in hardware.  So software needs to do a flush when it
receives an interrupt and before it calls the interrupt handler.

There are new ones for the QCA934x and QCA955x, so do a few things:

* Get rid of the individual ones (for ethernet and IP2);
* Create a mux and enum listing all the variations on DDR flushes;
* replace the uses of IP2 with the relevant one (which will typically
  be "PCI" here);
* call the USB DDR flush before calling the real USB interrupt handlers;
* call the ethernet one upon receiving an interrupt that's for us,
  rather than never calling it during operation.

Tested:

* QCA9558 (TP-Link archer c7 v2)
* AR9331 (Carambola 2)

TODO:

* PCI, USB, ethernet, etc need to do a double-check to see if the
  interrupt was truely for them before doing the DDR.  For now I
  prefer "correct" over "fast".
2015-07-04 03:05:57 +00:00
Adrian Chadd
ef19855701 Oops - fix typo. 2015-07-03 07:00:24 +00:00
Adrian Chadd
9d0e5a1718 Enable setting the QCA955x GPIO output mux configuration.
It's not used by any boards yet, but it's going to creep up soon
as more boards show up.
2015-07-03 03:34:21 +00:00
Adrian Chadd
3facd56c71 Add register defines for the QCA955x DDR flush and GPIO control. 2015-07-03 03:32:54 +00:00
Adrian Chadd
b2c9e1e324 Add initial support for the QCA955x PCIe host controller.
The QCA955x looks a lot like the AR724x PCIe controller, except it
supports two root complexes.  Unfortunately I only have one, so
although this code has started down the path of supporting more than
one, it's definitely not yet ready.

Tested:

* AP135 board (QCA9558 SoC), with the 11ac NIC swapped for an AR9380
  PCIe NIC.

Notes:

* Yes, this driver isn't very pretty.  I decided to commit what I have
  versus holding onto something that isn't yet finished.  It is enough
  to bring up the above NIC and interrupt routing works, so it's a good
  start.

* However, yes, the DDR flush routine hooks need to be fixed up.
  I don't think I'm firing the right one at the moment.
2015-05-19 05:31:58 +00:00
Andrew Turner
405ada37fb Add support for the uart classes to set their default register shift value.
This is needed with the pl011 driver. Before this change it would default
to a shift of 0, however the hardware places the registers at 4-byte
addresses meaning the value should be 2.

This patch fixes this for the pl011 when configured using the fdt. The
other drivers have a default value of 0 to keep this a no-op.

MFC after:	1 week
2015-04-11 17:16:23 +00:00
Adrian Chadd
b7d7ad0b90 Begin moving support for board MAC addresses over to being explicitly defined.
A lot of these dinky atheros based MIPS boards don't have a nice, well,
anything consistent defining their MAC addresses for things.

The Atheros reference design boards will happily put MAC addresses
into the wifi module calibration data like they should, and individual
ethernet MAC addresses into the calibration area in flash.
That makes my life easy - "hint.arge.X.eeprommac=<addr>" reads from
that flash address to extract a MAC, and everything works fine.

However, aside from some very well behaved vendors (eg the Carambola 2
board), everyone else does something odd.

eg:

* a MAC address in the environment (eg ubiquiti routerstation/RSPRO)
   that you derive arge0/arge1 MAC addresses from.
* a MAC address in flash that you derive arge0/arge1 MAC addresses from.
* The wifi devices having their own MAC addresses in calibration data,
  like normal.
* The wifi devices having a fixed, default or garbage value for a MAC
  address in calibration data, and it has to be derived from the
  system MAC.

So to support this complete nonsense of a situation, there needs to be
a few hacks:

* The "board" MAC address needs to be derived from somewhere and squirreled
  away.  For now it's either redboot or a MAC address stored in calibration
  flash.

* Then, a "map" set of hints to populate kenv with some MAC addresses
  that are derived/local, based on the board address.  Each board has
  a totally different idea of what you do to derive things, so each
  map entry has an "offset" (+ve or -ve) that's added to the board
  MAC address.

* Then if_arge (and later, if_ath) should check kenv for said hint and
  if it's found, use that rather than the EEPROM MAC address - which may
  be totally garbage and not actually work right.

In order to do this, I've undone some of the custom redboot expecting
hacks in if_arge and the stuff that magically adds one to the MAC
address supplied by the board - instead, as I continue to test this
out on more hardware, I'll update the hints file with a map explaining
(a) where the board MAC should come from, and (b) what offsets to use
for each device.

The aim is to have all of the tplink, dlink and other random hardware
we run on have valid MAC addresses at boot, so (a) people don't get
random B:S:Dx:x ethernet MACs, and (b) the wifi MAC is valid
so it works rather than trying to use an invalid address that
actually upsets systems (think: multicast bit set in BSSID.)

Tested:

* TP-Link TL_WDR3600 - subsequent commits will add the hints map
  and the if_ath support.

TODO:

* Since this is -HEAD, and I'm all for debugging, there's a lot of
  printf()s in here.  They'll eventually go under bootverbose.
* I'd like to turn the macaddr routines into something available
  to all drivers - too many places hand-roll random MAC addresses
  and parser stuff.  I'd rather it just be shared code.
  However, that'll require more formal review.
* More boards.
2015-03-28 23:40:29 +00:00
Adrian Chadd
753370121e Add GPIO function mux configuration for AR934x SoCs.
The AR934x (and maybe others in this family) have a more complicated
GPIO mux.  The AR71xx just has a single function register for a handful
of "GPIO or X" options, however the AR934x allows for one of roughly
100 behaviours for each GPIO pin.

So, this adds a quick hints based mechanism to configure the output
functions, which is required for some of the more interesting board
configurations.  Specifically, some use external LNAs to improve
RX, and without the MUX/output configured right, the 2GHz RX side
will be plain terrible.

It doesn't yet configure the "input" side yet; I'll add that if
it's required.

Tested:

* TP-Link TL-WDR3600, testing 2GHz STA/AP modes, checking some
  basic RX sensitivity things (ie, "can I see the AP on the other
  side of the apartment that intentionally has poor signal reception
  from where I am right now.")

Whilst here, fix a silly bug in the maxpin routine; I was missing
a break.
2015-03-21 06:08:35 +00:00
Adrian Chadd
358811c4e3 add QCA955x PCIe configuration registers.
These are /not/ absolute addresses, as the QCA955x SoC has 2 PCIe RC's
(and 1 PCIe EP.)
2015-03-21 06:00:46 +00:00
Adrian Chadd
3d58374a29 Note that the AR724x PCIe registers are actually from the PCI_CTRL
register range.
2015-03-21 05:59:45 +00:00