Commits · e5395e92a470769d67369c002a41e59619f5214b · Kirill Smelkov / linux

05 Apr, 2012 8 commits

net/mlx4_core: set port QoS attributes · e5395e92

Amir Vadai authored Apr 04, 2012

Adding QoS firmware commands:
- mlx4_en_SET_PORT_PRIO2TC - set UP <=> TC
- mlx4_en_SET_PORT_SCHEDULER - set promised BW, max BW and PG number
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

e5395e92

net/mlx4_en: Force user priority by QP attribute · 0e98b523

Amir Vadai authored Apr 04, 2012

Instead of relying on HW to change schedule queue by UP, schedule
queue is fixed for a tx_ring, and UP in WQE is ignored in this aspect.  This
resolves two issues with untagged traffic:
1. untagged traffic has no UP in packet which is needed for QoS. The change
   above allows setting the schedule queue (and by that the UP) of such a stream.
2. BlueFlame uses the same field used by vlan tag. So forcing UP from QPC
   allows using BF for untagged but prioritized traffic.

In old firmware that force UP is not supported, untagged traffic will not subject to
QoS.

Because UP is set by QP, need to always have a tx ring per UP, even if pfcrx
module paramter is false.
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

0e98b523

net: sh_eth: add support R8A7740 · 73a0d907

Yoshihiro Shimoda authored Apr 04, 2012

The R8A7740 has a Gigabit Ethernet MAC. This patch supports it.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

73a0d907

Ethernet driver for the WIZnet W5100 chip · 8b1467a3

Mike Sinkovsky authored Apr 04, 2012

Based on original driver from chip manufacturer, but nearly full rewite.
Tested and used in production with Blackfin BF531 embedded processor.
Signed-off-by: Mike Sinkovsky <msink@permonline.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>

8b1467a3

Ethernet driver for the WIZnet W5300 chip · 9899b81e

Mike Sinkovsky authored Apr 04, 2012

9899b81e

vxge: Convert macro to inline function · 044a3813

Joe Perches authored Apr 03, 2012

Convert the macro to inline function to check the arguments.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

044a3813

team: add loadbalance mode · 01d7f30a

Jiri Pirko authored Apr 04, 2012

This patch introduces new team mode. It's TX port is selected by
user-set BPF hash function.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

01d7f30a

team: add binary option type · 2615598f

Jiri Pirko authored Apr 04, 2012

For transfering generic binary data (e.g. BPF code), introduce new
binary option type.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

2615598f

04 Apr, 2012 32 commits

stmmac: update the driver version March 2012 · bd856615

Giuseppe CAVALLARO authored Apr 04, 2012

Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bd856615

stmmac: MDC clock dynamically based on the csr clock input · cd7201f4

Giuseppe CAVALLARO authored Apr 04, 2012

If a specific clk_csr value is passed from the platform
this means that the CSR Clock Range selection cannot be
changed at run-time and it is fixed (as reported in the driver
documentation). Viceversa the driver will try to set the MDC
clock dynamically according to the actual clock input.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Reviewed-by: Francesco Virlinzi <francesco.virlinzi@st.com>
Reviewed-by: David Laight <david.laight@aculab.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

cd7201f4

stmmac: extend CSR Clock Range programming · 18f05d64

Giuseppe CAVALLARO authored Apr 04, 2012

The CSR Clock Range has been reworked and new macros has
been added in the platform header to allow the CSR Clock
Range selection in the GMII Address Register.
The previous work didn't add the other fields
that can be used to achieve MDC clock of frequency
higher than the IEEE 802.3 specified frequency limit
of 2.5 MHz and program a clock divider of lower value.
On such platforms, these are used indeed so this patch
adds them.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

18f05d64

stmmac: add clk management support · ba1377ff

Giuseppe CAVALLARO authored Apr 04, 2012

this patch adds the way to enable/disable the MAC
clock when call the open/close and resume/restore
functions.
This has been tested on ST platforms and SPEAr; thanks
to Francesco and Deepak.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Tested-by: Francesco Virlinzi <francesco.virlinzi@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ba1377ff

stmmac: Replace infinite loops by timeouts in mdio r/w · 39b401db

Deepak SIKRI authored Apr 04, 2012

This patch removes the infinite waits from the mdio read and
write interfaces. These infinite waits have been replaced by
the timeout handling. In case if a time out occurs, an error is
returned.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

39b401db

stmmac: re-work the internal GMAC DMA platf parameters · 8327eb65

Deepak SIKRI authored Apr 04, 2012

This patch re-works the internal GMAC DMA parameters
passed from the platform.
In the past, we only passed the pbl but, with new core,
other parameters can be passed and are mandatory on some
platforms.

New parameters are documented in stmmac.txt because this
patch has an impact for many platforms.
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

8327eb65

stmmac: Define MDC clock selection macros · faeae3fa

Deepak SIKRI authored Apr 04, 2012

The patch adds the macros to be used for MDC clock selection. The MDC clock
frequency is based on scaled system clock, and has to be confined to a range
of 1-2.5 MHz. Based on the input CSR clock, the scaling factor has to be
selected.
The platform specific code will provide the default value of this scaling
factor, based on the input CSR clock.
There is an option to set MDC clock higher than the IEEE 802.3 specified
frequency limit of 2.5 MHz. This applies for the interfacing chips that
support higher MDC clocks. The resultant higher clock of 12.5 MHz requires
additional Macros to be defined for the clock divider corresponding to the
to the following selection.
-----------------------------------------
	Selection	MDC Clock
-----------------------------------------
	1000 		clk_csr_i/4
	1001 		clk_csr_i/6
	1010 		clk_csr_i/8
	1011 		clk_csr_i/10
	1100 		clk_csr_i/12
	1101	 	clk_csr_i/14
	1110 		clk_csr_i/16
	1111 		clk_csr_i/18

This support has to be added both in the include file, as well as driver. The
driver need to program the registers based on the interfacing chips. This would
be more board specific information and needs to be passed through the platform
code to the driver. This work would be carried out in the future patch set
release.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

faeae3fa

stmmac: sanitize the rx coe and add the type-1 csum (v2) · 38912bdb

Deepak SIKRI authored Apr 04, 2012

This patch sanities the RX coe and adds the Type-1 Rx checksum offload engine (COE).

So the RX COE can be passed through the platform but can be fixed
at run-time in case of the core has the HW capability register.

Also to support the Type-1 Rx COE the driver must append the
HW checksum at the end of payload in case the Rx checksum
engine was used to  offload the HW checksum.

This v2 version also fixes the IPC that has to be enabled and verified.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

38912bdb

stmmac: Define CSUM offload engine Types · 55f9a4d6

Deepak SIKRI authored Apr 04, 2012

This patch explicitly defines the CSUM offload engine type which need
(not mandatory) to be passed from the platform code.
STMMAC core supports two check sum offload engine types- Type-1 & Type-2.
Also, there are STMMAC cores that do not have the check sum offload
capabilities.

The behaviour of Type-1 & Type-2 cores related to provision of checksum
increases the packet length for Type-1 cores by 2, as the checksum is appended
at the end of data packet and the same is made accountable in the DMA status.
The STMMAC cores beyond Version-3.5 provide HW interface registers which allows
the user to read the HW capabilities, while to support the previous cores the
information related to HW capabilities has to be provided from the platform
code.

The Type-1 cores which do not have the HW register interface need this
information.

This patch also updates the driver's doc.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

55f9a4d6

stmmac: Allow stmmac to work with other PHY buses(v3). · f142af2e

Srinivas Kandagatla authored Apr 04, 2012

As stmmac mdio bus name prefix is hardcoded in the driver, this allows
only phys on stmmac mdio buses to connect, however stmmac should allow
phys on other mdio buses too.

This patch adds new variable phy_bus_name to plat_stmmacenet_data
struct to let the BSP decide which phy bus to be used by stmmac driver.
A typical use-case is to have generic MDIO buses like mdio-gpio on top
of stmmac.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>