Implementing discard counters for the NIU driver turned out to be more
complicated than first assumed.
The discard counters for the NIU neptune chip are only 16-bit (even
though this is a 64-bit chip). These 16-bit counters can overflow
quickly, especially considering this is a 10Gbit/s ethernet card.
The overflow indication bit is, unfortunatly, not usable as the
counter value does not wrap, but remains at max value 0xFFFF.
Resulting in lost counts until the counter is reset.
The read and reset scheme also poses a problem. Both in theory and in
practice counters can be lost in between reading nr64() and clearing
the counter nw64(). For this reason, the number of counter clearings
nw64() is limited/reduced. On the fast-path the counters are only
syncronized once it exceeds 0x7FFF. When read by userspace, its
syncronized fully.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
this warning:
drivers/net/niu.c: In function ‘esr_reset’:
drivers/net/niu.c:741: warning: ‘reset’ may be used uninitialized in this function
triggers because GCC does not recognize the (correct) error flow
between:
- esr_read_reset() and 'reset'
Annotate it.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: David S. Miller <davem@davemloft.net>
these warnings:
drivers/net/niu.c: In function ‘serdes_init_niu_1g_serdes’:
drivers/net/niu.c:451: warning: ‘sig’ may be used uninitialized in this function
drivers/net/niu.c: In function ‘serdes_init_niu_10g_serdes’:
drivers/net/niu.c:550: warning: ‘sig’ may be used uninitialized in this function
triggers because GCC does not recognize that the max_retry loop
always initializes 'sig', due to max_retry != 0.
Annotate them.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: David S. Miller <davem@davemloft.net>
A patch to put names on the niu interrupt vectors according the syntax below.
This is needed to assign correct affinity.
> So on a multiqueue card with 2 RX queues and 2 TX queues we'd
> have names like:
>
> eth0-rx-0
> eth0-rx-1
> eth0-tx-0
> eth0-tx-1
Signed-off-by: Robert Olsson <robert.olsson@its.uu.se>
Tested-by: Jesper Dangaard Brouer <jdb@comx.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch moves neigh_setup and hard_start_xmit into the network device ops
structure. For bisection, fix all the previously converted drivers as well.
Bonding driver took the biggest hit on this.
Added a prefetch of the hard_start_xmit in the fast path to try and reduce
any impact this would have.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Convert this driver to network device ops. Compile tested only (give me hw!)
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This driver is pretty mature, and the worst of the known
problems has been fixed (the 32-bit failures due to readq
implementation).
So let's finally give it a version of 1.0
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds support for the Sun CP3260 ATCA blade which is
a N2 based ATCA blade with 2 NIU ports. The NIU ports do not
have on-board PHY.
Signed-off-by: Santwona Behera <santwona.behera@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes a TX hang reported by Jesper Dangaard Brouer.
When an architecutre cannot provide a fully functional
64-bit atomic readq/writeq, the driver must implement
it's own. This is because only the driver can say whether
doing something like using two 32-bit reads to implement
the full 64-bit read will actually work properly.
In particular one of the issues is whether the top 32-bits
or the bottom 32-bits of the 64-bit register should be read
first. There could be side effects, and in fact that is
exactly the problem here.
The TX_CS register has counters in the upper 32-bits and
state bits in the lower 32-bits. A read clears the state
bits.
We would read the counter half before the state bit half.
That first read would clear the state bits, and then the
driver thinks that no interrupts are pending because the
interrupt indication state bits are seen clear every time.
Fix this by reading the bottom half before the upper half.
Tested-by: Jesper Dangaard Brouer <jdb@comx.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
The generic packet receive code takes care of setting
netdev->last_rx when necessary, for the sake of the
bonding ARP monitor.
Drivers need not do it any more.
Some cases had to be skipped over because the drivers
were making use of the ->last_rx value themselves.
Signed-off-by: David S. Miller <davem@davemloft.net>
This converts pretty much everything to print_mac. There were
a few things that had conflicts which I have just dropped for
now, no harm done.
I've built an allyesconfig with this and looked at the files
that weren't built very carefully, but it's a huge patch.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
The reset_task function in the niu driver does not reset the tx and rx
buffers properly. This leads to panic on reset. This patch is a
modified implementation of the previously posted fix.
Signed-off-by: Santwona Behera <santwona.behera@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The callers of niu_ethflow_to_class expect zero as error, but it returns
-1 instead.
Signed-off-by: Andreas Schwab <schwab@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Implemented ethtool callback functions for configuring receive flow
hashing in the niu driver.
Signed-off-by: Santwona Behera <santwona.behera@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Determine the number of physical ports from the card's VPD data.
Previous fix failed on Maramba platform which doesn't have the
"board-model" property. This fix uses the "model" property which
exists on all cards and Neptune based motherboards.
cstyle cleanup included.
Signed-off-by: Matheos Worku <matheos.worku@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Changeset 7f7c4072ea ("niu: Determine
the # of ports from the card's VPD data") caused maramba on-board
NIU ports to stop probing properly.
The old code had a fallback that would use a num_ports value of
4 if all the probing methods failed, but that was removed.
This restores the fallback of 4 ports, to get things working
again.
Bump driver version and release date.
Signed-off-by: David S. Miller <davem@davemloft.net>
[ Minor coding style and whitespace corrections, also bump
driver version and release date. -DaveM ]
Signed-off-by: Matheos Worku <matheos.worku@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ Fix minor whitespace and coding style stuff... -DaveM ]
Signed-off-by: Matheos Worku <matheos.worku@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ports 0 and 1 of the NIU device are connected to extended fabric
through SERDES. Ports 2 and 3 are connected using RGMII Fiber mode.
[ Coding style cleanups... -DaveM ]
Signed-off-by: Matheos Worku <matheos.worku@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
From: Matheos Worku <Matheos.Worku@Sun.COM>
1) niu_enable_alt_mac() needs to be adjusted so that the mask
is computed properly for the BMAC case.
2) BMAC has 6 alt MAC addresses available, not 7.
Signed-off-by: David S. Miller <davem@davemloft.net>
BMAC port alternate MAC address index needs to start at 1. Index 0 is
used for the main MAC address.
Signed-off-by: Matheos Worku <matheos.worku@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The code in link_status_1g() computes the active speed
and duplex but does not update the link config state
with those values.
As a result the link speed is not reported correctly
and the XIF is not reprogrammed properly on link up
events.
Signed-off-by: David S. Miller <davem@davemloft.net>
From: Mirko Lindner <mlindner@marvell.com>
This patch makes necessary changes in the Neptune driver to support
the new Marvell PHY. It also adds support for the LED blinking
on Neptune cards with Marvell PHY. All registers are using defines
in the niu.h header file as is already done for the BCM8704 registers.
[ Coding style, etc. cleanups -DaveM ]
Signed-off-by: David S. Miller <davem@davemloft.net>
It is possible for the TX ring to have packets sit in it for unbounded
amounts of time.
The only way to defer TX interrupts in the chip is to periodically set
"mark" bits, when processing of a TX descriptor with the mark bit set
is complete it triggers the interrupt for the TX queue's LDG.
A consequence of this kind of scheme is that if packet flow suddenly
stops, the remaining TX packets will just sit there.
If this happens, since those packets could be charged to TCP socket
send queues, such sockets could get stuck.
The simplest solution is to divorce the socket ownership of the packet
once the device takes the SKB, by using skb_orphan() in
niu_start_xmit().
In hindsight, it would have been much nicer if the chip provided two
interrupt sources for TX (like basically every other ethernet chip
does). Namely, keep the "mark" bit, but also signal the LDG when the
TX queue becomes completely empty. That way there is no need to have
a deadlock breaker like this.
Signed-off-by: David S. Miller <davem@davemloft.net>
niu_slowpath_interrupt() expects values to be setup in lp->{v0,v1,v2}
but they aren't. That's only done by niu_schedule_napi() which is
done later in the interrupt path.
If niu_rx_error() returns zero, and v0 is clear, hit the
RX_DMA_CTL_STATE register with a RX_DMA_CTL_STAT_MEX.
Only emit verbose RX error logs if a fatal channel or port error is
signalled. Other cases will be recorded into statistics by
niu_log_rxchan_errors().
Signed-off-by: David S. Miller <davem@davemloft.net>
The LED in the current driver will not be controlled correctly. During
a link change the carrier of the link is not available and the LED
will never turn on.
Signed-off-by: David S. Miller <davem@davemloft.net>
I get the following warning from a powerpc allyesconfig of current
mainline:
drivers/net/niu.c: In function 'niu_size_rbr':
drivers/net/niu.c:3113: warning: large integer implicitly truncated to unsigned type
PAGE_SIZE in this case is 64KB, so I don't quite get why gcc can't
tell that the line in question will never be reached.
I suggest the following instead, but I can unfortunately not do
anything but build test it.
Also, the driver does some other checks to make sure that PAGE_SIZE is
a power of two (BUILD_BUG_ON() in niu_init()), doesn't seem like that
could ever be untrue? Or are there really archs with non-power-of-two
PAGE_SIZE?
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
By the time we get to that switch by PHY type, we have 8bit
value. No need to keep it in u64 when u8 would do.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
With cleanup suggestions and bugs spotted by Stephen Hemminger,
Ingo Oeser, Matheos Worku, and Oliver Hartkopp.
Signed-off-by: David S. Miller <davem@davemloft.net>
