* Re: [PATCH net-next 2/7] net: dsa: mv88e6xxx: 6185 has only 256 FDBs
From: Andrew Lunn @ 2016-03-27 2:52 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Patrick Uiterwijk,
Guenter Roeck
In-Reply-To: <1459043983-12088-3-git-send-email-vivien.didelot@savoirfairelinux.com>
On Sat, Mar 26, 2016 at 09:59:38PM -0400, Vivien Didelot wrote:
> The 6185 family has only 256 indexable address databases, while the
> others (such as 6352) have 4095. Explicit and use these maximum values
> in the _mv88e6xxx_fid_new function.
Hi Vivien
I've been looking at the Marvell reference code, in particular, the
function gfdbGetAtuAllCount().
The following device have 16 databases.
( DEV_88E6021 | DEV_88E6060 | DEV_88E6063 | \
DEV_FH_VPN | DEV_88E6083 | DEV_88E6183 | DEV_88E6093 | DEV_88E6061 )
The following device have 64 databases.
( DEV_88E6065 )
The following devices have 256 databases
( DEV_88E6095_FAMILY | DEV_88E6185_FAMILY )
And the following devices have 4096
( DEV_88E6097_FAMILY | DEV_88E6165_FAMILY | DEV_88E6\
351_FAMILY| DEV_88E6352_FAMILY )
Andrew
^ permalink raw reply
* Re:Hola
From: hi @ 2016-03-27 2:06 UTC (permalink / raw)
To: nesus
hola
ordenador portátil, cámara, televisión, gultar, bicicleta. ... Te ofrecemos un 50% de descuento y envío gratis
iphone 6s,388euro
s ite: slooone . com
^ permalink raw reply
* [PATCH net-next 5/7] net: dsa: mv88e6xxx: fix VTU FID access for 6185
From: Vivien Didelot @ 2016-03-27 1:59 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn,
Patrick Uiterwijk, Guenter Roeck, Vivien Didelot
In-Reply-To: <1459043983-12088-1-git-send-email-vivien.didelot@savoirfairelinux.com>
The 6352 family has an entire register for its 12-bit FID used by the
VTU operations. The 6185 family has no such register. Its 8-bit FID
(called DBNum) is split in the VTU Operation register.
Modify the VTU read and write access to support this switch family.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx.c | 20 +++++++++++++++++++-
drivers/net/dsa/mv88e6xxx.h | 2 +-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 4b3c466..366fda1 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1355,6 +1355,17 @@ static int _mv88e6xxx_vtu_getnext(struct dsa_switch *ds,
return ret;
next.sid = ret & GLOBAL_VTU_SID_MASK;
+ } else if (mv88e6xxx_6185_family(ds)) {
+ /* VTU DBNum[7:4] are located in VTU Operation 11:8, and
+ * VTU DBNum[3:0] are located in VTU Operation 3:0
+ */
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL,
+ GLOBAL_VTU_OP);
+ if (ret < 0)
+ return ret;
+
+ next.fid = (ret & 0xf00) >> 4;
+ next.fid |= ret & 0xf;
}
}
@@ -1416,6 +1427,7 @@ unlock:
static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch *ds,
struct mv88e6xxx_vtu_stu_entry *entry)
{
+ u16 op = GLOBAL_VTU_OP_VTU_LOAD_PURGE;
u16 reg = 0;
int ret;
@@ -1442,6 +1454,12 @@ static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch *ds,
ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_FID, reg);
if (ret < 0)
return ret;
+ } else if (mv88e6xxx_6185_family(ds)) {
+ /* VTU DBNum[7:4] are located in VTU Operation 11:8, and
+ * VTU DBNum[3:0] are located in VTU Operation 3:0
+ */
+ op |= (entry->fid & 0xf0) << 8;
+ op |= entry->fid & 0xf;
}
reg = GLOBAL_VTU_VID_VALID;
@@ -1451,7 +1469,7 @@ loadpurge:
if (ret < 0)
return ret;
- return _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_VTU_LOAD_PURGE);
+ return _mv88e6xxx_vtu_cmd(ds, op);
}
static int _mv88e6xxx_stu_getnext(struct dsa_switch *ds, u8 sid,
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 94d3cb3..b1f1269 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -376,7 +376,7 @@ struct mv88e6xxx_atu_entry {
struct mv88e6xxx_vtu_stu_entry {
/* VTU only */
u16 vid;
- u16 fid;
+ u16 fid; /* 8-bit DBNum in 88E6185 family */
/* VTU and STU */
u8 sid;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 4/7] net: dsa: mv88e6xxx: fix ATU FID access for 6185
From: Vivien Didelot @ 2016-03-27 1:59 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn,
Patrick Uiterwijk, Guenter Roeck, Vivien Didelot
In-Reply-To: <1459043983-12088-1-git-send-email-vivien.didelot@savoirfairelinux.com>
The 6185 family does not have a ATU FID register. It splits it in the
ATU Control register and the ATU Operation.
Add 6185 support for FID (a.k.a. DBNum) in ATU commands.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx.c | 14 ++++++++++++++
drivers/net/dsa/mv88e6xxx.h | 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index df3f219..4b3c466 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -961,6 +961,20 @@ static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 fid, u16 cmd)
ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
if (ret < 0)
return ret;
+ } else if (mv88e6xxx_6185_family(ds)) {
+ /* ATU DBNum[7:4] are located in ATU Control 15:12 */
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_CONTROL,
+ (ret & 0xfff) |
+ ((fid << 8) & 0xf000));
+ if (ret < 0)
+ return ret;
+
+ /* ATU DBNum[3:0] are located in ATU Operation 3:0 */
+ cmd |= fid & 0xf;
} else {
return -EOPNOTSUPP;
}
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index febab76..94d3cb3 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -366,7 +366,7 @@ struct mv88e6xxx_switch_id {
};
struct mv88e6xxx_atu_entry {
- u16 fid;
+ u16 fid; /* 8-bit DBNum in 88E6185 family */
u8 state;
bool trunk;
u16 portv_trunkid;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 7/7] net: dsa: mv88e6131: enable hardware bridging
From: Vivien Didelot @ 2016-03-27 1:59 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn,
Patrick Uiterwijk, Guenter Roeck, Vivien Didelot
In-Reply-To: <1459043983-12088-1-git-send-email-vivien.didelot@savoirfairelinux.com>
By adding support for bridge operations, FDB operations, and optionally
VLAN operations (for 802.1Q and VLAN filtering aware systems), the
switch bridges ports correctly, the CPU is able to populate the hardware
address databases, and thus hardware bridging becomes functional within
the 88E6185 family of switches.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6131.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index a92ca65..2407028 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -169,6 +169,17 @@ struct dsa_switch_driver mv88e6131_switch_driver = {
.get_ethtool_stats = mv88e6xxx_get_ethtool_stats,
.get_sset_count = mv88e6xxx_get_sset_count,
.adjust_link = mv88e6xxx_adjust_link,
+ .port_bridge_join = mv88e6xxx_port_bridge_join,
+ .port_bridge_leave = mv88e6xxx_port_bridge_leave,
+ .port_vlan_filtering = mv88e6xxx_port_vlan_filtering,
+ .port_vlan_prepare = mv88e6xxx_port_vlan_prepare,
+ .port_vlan_add = mv88e6xxx_port_vlan_add,
+ .port_vlan_del = mv88e6xxx_port_vlan_del,
+ .port_vlan_dump = mv88e6xxx_port_vlan_dump,
+ .port_fdb_prepare = mv88e6xxx_port_fdb_prepare,
+ .port_fdb_add = mv88e6xxx_port_fdb_add,
+ .port_fdb_del = mv88e6xxx_port_fdb_del,
+ .port_fdb_dump = mv88e6xxx_port_fdb_dump,
};
MODULE_ALIAS("platform:mv88e6085");
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 6/7] net: dsa: mv88e6xxx: map destination addresses for 6185
From: Vivien Didelot @ 2016-03-27 1:59 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn,
Patrick Uiterwijk, Guenter Roeck, Vivien Didelot
In-Reply-To: <1459043983-12088-1-git-send-email-vivien.didelot@savoirfairelinux.com>
The 88E6185 switch also has a MapDA bit in its Port Control 2 register.
When this bit is cleared, all frames are sent out to the CPU port.
Set this bit to rely on address databases (ATU) hits and direct frames
out of the correct ports, and thus allow hardware bridging.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 366fda1..35d0ace 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -2413,7 +2413,8 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds, int port)
reg = 0;
if (mv88e6xxx_6352_family(ds) || mv88e6xxx_6351_family(ds) ||
mv88e6xxx_6165_family(ds) || mv88e6xxx_6097_family(ds) ||
- mv88e6xxx_6095_family(ds) || mv88e6xxx_6320_family(ds))
+ mv88e6xxx_6095_family(ds) || mv88e6xxx_6320_family(ds) ||
+ mv88e6xxx_6185_family(ds))
reg = PORT_CONTROL_2_MAP_DA;
if (mv88e6xxx_6352_family(ds) || mv88e6xxx_6351_family(ds) ||
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 3/7] net: dsa: mv88e6xxx: write FID in ATU command
From: Vivien Didelot @ 2016-03-27 1:59 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn,
Patrick Uiterwijk, Guenter Roeck, Vivien Didelot
In-Reply-To: <1459043983-12088-1-git-send-email-vivien.didelot@savoirfairelinux.com>
Some switch models don't have a separate ATU FID register, but bury it
in the ATU Operation register.
Factorize the write of the FID and opcode in the ATU command function.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 1d9b5dd..df3f219 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -951,10 +951,20 @@ out:
return ret;
}
-static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 cmd)
+static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, u16 fid, u16 cmd)
{
int ret;
+ if (mv88e6xxx_6097_family(ds) || mv88e6xxx_6165_family(ds) ||
+ mv88e6xxx_6351_family(ds) || mv88e6xxx_6352_family(ds)) {
+ /* 88E6352 and similar have their own ATU FID register */
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
+ if (ret < 0)
+ return ret;
+ } else {
+ return -EOPNOTSUPP;
+ }
+
ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_OP, cmd);
if (ret < 0)
return ret;
@@ -1001,11 +1011,6 @@ static int _mv88e6xxx_atu_flush_move(struct dsa_switch *ds,
return err;
if (entry->fid) {
- err = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID,
- entry->fid);
- if (err)
- return err;
-
op = static_too ? GLOBAL_ATU_OP_FLUSH_MOVE_ALL_DB :
GLOBAL_ATU_OP_FLUSH_MOVE_NON_STATIC_DB;
} else {
@@ -1013,7 +1018,7 @@ static int _mv88e6xxx_atu_flush_move(struct dsa_switch *ds,
GLOBAL_ATU_OP_FLUSH_MOVE_NON_STATIC;
}
- return _mv88e6xxx_atu_cmd(ds, op);
+ return _mv88e6xxx_atu_cmd(ds, entry->fid, op);
}
static int _mv88e6xxx_atu_flush(struct dsa_switch *ds, u16 fid, bool static_too)
@@ -1973,11 +1978,7 @@ static int _mv88e6xxx_atu_load(struct dsa_switch *ds,
if (ret < 0)
return ret;
- ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, entry->fid);
- if (ret < 0)
- return ret;
-
- return _mv88e6xxx_atu_cmd(ds, GLOBAL_ATU_OP_LOAD_DB);
+ return _mv88e6xxx_atu_cmd(ds, entry->fid, GLOBAL_ATU_OP_LOAD_DB);
}
static int _mv88e6xxx_port_fdb_load(struct dsa_switch *ds, int port,
@@ -2060,11 +2061,7 @@ static int _mv88e6xxx_atu_getnext(struct dsa_switch *ds, u16 fid,
if (ret < 0)
return ret;
- ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
- if (ret < 0)
- return ret;
-
- ret = _mv88e6xxx_atu_cmd(ds, GLOBAL_ATU_OP_GET_NEXT_DB);
+ ret = _mv88e6xxx_atu_cmd(ds, fid, GLOBAL_ATU_OP_GET_NEXT_DB);
if (ret < 0)
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/7] net: dsa: mv88e6xxx: 6185 has only 256 FDBs
From: Vivien Didelot @ 2016-03-27 1:59 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn,
Patrick Uiterwijk, Guenter Roeck, Vivien Didelot
In-Reply-To: <1459043983-12088-1-git-send-email-vivien.didelot@savoirfairelinux.com>
The 6185 family has only 256 indexable address databases, while the
others (such as 6352) have 4095. Explicit and use these maximum values
in the _mv88e6xxx_fid_new function.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 1d9ae48..1d9b5dd 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1575,8 +1575,12 @@ static int _mv88e6xxx_fid_new(struct dsa_switch *ds, u16 *fid)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
DECLARE_BITMAP(fid_bitmap, MV88E6XXX_N_FID);
struct mv88e6xxx_vtu_stu_entry vlan;
+ u16 max = 4095;
int i, err;
+ if (mv88e6xxx_6185_family(ds))
+ max = 256;
+
bitmap_zero(fid_bitmap, MV88E6XXX_N_FID);
/* Set every FID bit used by the (un)bridged ports */
@@ -1608,7 +1612,7 @@ static int _mv88e6xxx_fid_new(struct dsa_switch *ds, u16 *fid)
* databases are not needed. Return the next positive available.
*/
*fid = find_next_zero_bit(fid_bitmap, MV88E6XXX_N_FID, 1);
- if (unlikely(*fid == MV88E6XXX_N_FID))
+ if (unlikely(*fid > max))
return -ENOSPC;
/* Clear the database */
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/7] net: dsa: mv88e6xxx: 6185 port default FID is 8-bit
From: Vivien Didelot @ 2016-03-27 1:59 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn,
Patrick Uiterwijk, Guenter Roeck, Vivien Didelot
In-Reply-To: <1459043983-12088-1-git-send-email-vivien.didelot@savoirfairelinux.com>
In the 6352 family, FIDs are 12-bit. In the 6185 family, they are 8-bit.
Fix the upper mask, which was overlapping on the port Trunk ID (even
though it is not used yet).
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx.c | 10 +++++++---
drivers/net/dsa/mv88e6xxx.h | 3 ++-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index fa086e0..1d9ae48 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1511,9 +1511,13 @@ loadpurge:
static int _mv88e6xxx_port_fid(struct dsa_switch *ds, int port, u16 *new,
u16 *old)
{
+ u16 upper_mask = PORT_CONTROL_1_FID_11_4_MASK;
u16 fid;
int ret;
+ if (mv88e6xxx_6185_family(ds))
+ upper_mask = PORT_CONTROL_1_DBNUM_7_4_MASK;
+
/* Port's default FID bits 3:0 are located in reg 0x06, offset 12 */
ret = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_BASE_VLAN);
if (ret < 0)
@@ -1536,11 +1540,11 @@ static int _mv88e6xxx_port_fid(struct dsa_switch *ds, int port, u16 *new,
if (ret < 0)
return ret;
- fid |= (ret & PORT_CONTROL_1_FID_11_4_MASK) << 4;
+ fid |= (ret & upper_mask) << 4;
if (new) {
- ret &= ~PORT_CONTROL_1_FID_11_4_MASK;
- ret |= (*new >> 4) & PORT_CONTROL_1_FID_11_4_MASK;
+ ret &= ~upper_mask;
+ ret |= (*new >> 4) & upper_mask;
ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_CONTROL_1,
ret);
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 9a038ab..febab76 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -133,7 +133,8 @@
#define PORT_CONTROL_STATE_LEARNING 0x02
#define PORT_CONTROL_STATE_FORWARDING 0x03
#define PORT_CONTROL_1 0x05
-#define PORT_CONTROL_1_FID_11_4_MASK (0xff << 0)
+#define PORT_CONTROL_1_DBNUM_7_4_MASK (0xf << 0) /* 6185 */
+#define PORT_CONTROL_1_FID_11_4_MASK (0xff << 0) /* 6352 */
#define PORT_BASE_VLAN 0x06
#define PORT_BASE_VLAN_FID_3_0_MASK (0xf << 12)
#define PORT_DEFAULT_VLAN 0x07
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/7] net: dsa: mv88e6xxx: HW bridging support for 6185
From: Vivien Didelot @ 2016-03-27 1:59 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn,
Patrick Uiterwijk, Guenter Roeck, Vivien Didelot
All packets passing through a switch of the 6185 family are currently all
directed to the CPU port. This means that port bridging is software driven.
To enable hardware bridging for this switch family, we need to implement the
port mapping operations, the FDB operations, and optionally the VLAN operations
(for 802.1Q and VLAN filtering aware systems).
However this family only has 256 FDBs indexed by 8-bit identifiers, opposed to
4096 FDBs with 12-bit identifiers for other families such as 6352. It also
doesn't have dedicated FID registers for ATU and VTU operations.
This patchset fixes these differences, and enable hardware bridging for 6185.
Vivien Didelot (7):
net: dsa: mv88e6xxx: 6185 port default FID is 8-bit
net: dsa: mv88e6xxx: 6185 has only 256 FDBs
net: dsa: mv88e6xxx: write FID in ATU command
net: dsa: mv88e6xxx: fix ATU FID access for 6185
net: dsa: mv88e6xxx: fix VTU FID access for 6185
net: dsa: mv88e6xxx: map destination addresses for 6185
net: dsa: mv88e6131: enable hardware bridging
drivers/net/dsa/mv88e6131.c | 11 ++++++
drivers/net/dsa/mv88e6xxx.c | 84 ++++++++++++++++++++++++++++++++-------------
drivers/net/dsa/mv88e6xxx.h | 7 ++--
3 files changed, 76 insertions(+), 26 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: mv88e6xxx: Introduce _mv88e6xxx_phy_page_{read,write}
From: Vivien Didelot @ 2016-03-26 22:58 UTC (permalink / raw)
To: Guenter Roeck, Patrick Uiterwijk
Cc: davem, linux, andrew, netdev, Dennis Gilmore, Peter Robinson
In-Reply-To: <56F6F79C.2030102@roeck-us.net>
Hi Guenter,
Guenter Roeck <linux@roeck-us.net> writes:
>>>>> Is there some good reason for changing the name of those labels ?
>>>>
>>>> Vivien suggested to rename this since it makes more clear that this write is
>>>> meant to return to page 0 to make sure that phylib doesn't get confused
>>>> about the currently active page.
>>>>
>>>
>>> And "clear:" accomplishes that ? I would not have guessed.
>>> Wonder if anyone else does. I would have used a comment.
>>> /* Try to return to page 0 even after an error */
>>> or something like that.
>>
>> "error" definitely doesn't make sense, especially in case of success. If
>> one has a better suggestion that "clear" for the label, I don't really
>> mind.
>
> Sounds like POV to me. I don't like changing label names, because someone
> else may come the next day and change it again. At the end, one ends up
> in a label name war. It also makes patches look more complicated than
> necessary, and it _is_ an unrelated change. I don't understand the
> problem with adding a comment, and using a label name in place of a
> comment seems odd to me.
>
> Anyway, this has all become philosophical, meaning I'll stay out of it.
> Pick whatever you want ...
Sorry I don't fully agree. There is no war or philosophical
concerns. "error" is just not correct here, this is not only an error
path. Why should we end up with a wrongly named label plus a comment,
when we can have a self documented function?
But I do agree that this change is not related. As the patch is moving
the core of these functions, it was just a good opportunity to rename
the label. I would understand and won't mind a very first 1/3 patch only
renaming the label. That might be a bit overkill however...
Thanks,
Vivien
^ permalink raw reply
* [PATCH] net: sxgbe: fix error paths in sxgbe_platform_probe()
From: Rasmus Villemoes @ 2016-03-26 21:24 UTC (permalink / raw)
To: David Miller; +Cc: Rasmus Villemoes, netdev, linux-kernel
In-Reply-To: <877fgue1mx.fsf@rasmusvillemoes.dk>
We need to use post-decrement to ensure that irq_dispose_mapping is
also called on priv->rxq[0]->irq_no; moreover, if one of the above for
loops failed already at i==0 (so we reach one of these labels with
that value of i), we'll enter an essentially infinite loop of
out-of-bounds accesses.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
David, can you take this directly? Of the three samsung people listed
by get_maintainer.pl, one address bounces and another informed me
privately that he's not actually a maintainer of this anymore.
drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c b/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
index b02eed12bfc5..73427e29df2a 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
@@ -155,11 +155,11 @@ static int sxgbe_platform_probe(struct platform_device *pdev)
return 0;
err_rx_irq_unmap:
- while (--i)
+ while (i--)
irq_dispose_mapping(priv->rxq[i]->irq_no);
i = SXGBE_TX_QUEUES;
err_tx_irq_unmap:
- while (--i)
+ while (i--)
irq_dispose_mapping(priv->txq[i]->irq_no);
irq_dispose_mapping(priv->irq);
err_drv_remove:
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/2] net: dsa: mv88e6xxx: Introduce _mv88e6xxx_phy_page_{read,write}
From: Guenter Roeck @ 2016-03-26 20:57 UTC (permalink / raw)
To: Vivien Didelot, Patrick Uiterwijk
Cc: davem, linux, andrew, netdev, Dennis Gilmore, Peter Robinson
In-Reply-To: <87vb49gkdo.fsf@ketchup.mtl.sfl>
On 03/26/2016 11:32 AM, Vivien Didelot wrote:
> Hi Guenter,
>
> Guenter Roeck <linux@roeck-us.net> writes:
>
>>>> Is there some good reason for changing the name of those labels ?
>>>
>>> Vivien suggested to rename this since it makes more clear that this write is
>>> meant to return to page 0 to make sure that phylib doesn't get confused
>>> about the currently active page.
>>>
>>
>> And "clear:" accomplishes that ? I would not have guessed.
>> Wonder if anyone else does. I would have used a comment.
>> /* Try to return to page 0 even after an error */
>> or something like that.
>
> "error" definitely doesn't make sense, especially in case of success. If
> one has a better suggestion that "clear" for the label, I don't really
> mind.
Sounds like POV to me. I don't like changing label names, because someone
else may come the next day and change it again. At the end, one ends up
in a label name war. It also makes patches look more complicated than
necessary, and it _is_ an unrelated change. I don't understand the
problem with adding a comment, and using a label name in place of a
comment seems odd to me.
Anyway, this has all become philosophical, meaning I'll stay out of it.
Pick whatever you want ...
Cheers,
Guenter
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: mv88e6xxx: Introduce _mv88e6xxx_phy_page_{read,write}
From: Vivien Didelot @ 2016-03-26 20:15 UTC (permalink / raw)
To: Andrew Lunn
Cc: Guenter Roeck, Patrick Uiterwijk, davem, linux, netdev,
Dennis Gilmore, Peter Robinson
In-Reply-To: <20160326194637.GB5547@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
>> page_0 is fine. What about an even more explicit "clear_page_0" label?
>
> We are not clearing anything. We are changing to page 0. So
>
> restore_page_0?
+1
^ permalink raw reply
* Delivery
From: FedEx Delivery Express Service @ 2016-03-26 18:54 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 18 bytes --]
See Attached File
[-- Attachment #2: DELIVERY DETAILS.pdf --]
[-- Type: application/pdf, Size: 130330 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: mv88e6xxx: Introduce _mv88e6xxx_phy_page_{read,write}
From: Andrew Lunn @ 2016-03-26 19:46 UTC (permalink / raw)
To: Vivien Didelot
Cc: Guenter Roeck, Patrick Uiterwijk, davem, linux, netdev,
Dennis Gilmore, Peter Robinson
In-Reply-To: <87lh55hvyb.fsf@ketchup.mtl.sfl>
> page_0 is fine. What about an even more explicit "clear_page_0" label?
We are not clearing anything. We are changing to page 0. So
restore_page_0?
Andrew
^ permalink raw reply
* Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.
From: Tom Herbert @ 2016-03-26 19:41 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, Linux Kernel Network Developers
In-Reply-To: <1458405122-12565-3-git-send-email-jesse@kernel.org>
On Sat, Mar 19, 2016 at 9:32 AM, Jesse Gross <jesse@kernel.org> wrote:
> When drivers express support for TSO of encapsulated packets, they
> only mean that they can do it for one layer of encapsulation.
> Supporting additional levels would mean updating, at a minimum,
> more IP length fields and they are unaware of this.
>
This patch completely breaks GRO for FOU and GUE.
> No encapsulation device expresses support for handling offloaded
> encapsulated packets, so we won't generate these types of frames
> in the transmit path. However, GRO doesn't have a check for
> multiple levels of encapsulation and will attempt to build them.
>
> UDP tunnel GRO actually does prevent this situation but it only
> handles multiple UDP tunnels stacked on top of each other. This
> generalizes that solution to prevent any kind of tunnel stacking
> that would cause problems.
>
GUE and FOU regularly create packets that will be both GSO UDP tunnels
and IPIP, SIT, GRE, etc. This is by design. There should be no
ambiguity in the drivers as to what this means. For instance, if
SKB_GSO_UDP_TUNNEL and SKB_GSO_GRE are set that is GRE/UDP packet, a
driver can use ndo_features_check to validate.
So multiple levels of encapsulation with GRO is perfectly valid and I
would suggest to simply revert this patch. The one potential issue we
could have is the potential for GRO to construct a packet which is a
UDP-encapsulation inside another encapsulation, like UDP-encap in GRE.
In this case the GSO flags don't provide enough information to
distinguish say between GRE/UDP (common case) and UDP/GRE (uncommon
case). To make this clear we can set udp_mark in GRE, ipip, and sit
but *not* check for it.
Tom
> Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack")
> Signed-off-by: Jesse Gross <jesse@kernel.org>
> ---
> v2: No change.
> ---
> include/linux/netdevice.h | 4 ++--
> net/core/dev.c | 2 +-
> net/ipv4/af_inet.c | 15 ++++++++++++++-
> net/ipv4/gre_offload.c | 5 +++++
> net/ipv4/udp_offload.c | 6 +++---
> net/ipv6/ip6_offload.c | 15 ++++++++++++++-
> 6 files changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index be693b3..f9eebd5 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2096,8 +2096,8 @@ struct napi_gro_cb {
> /* This is non-zero if the packet may be of the same flow. */
> u8 same_flow:1;
>
> - /* Used in udp_gro_receive */
> - u8 udp_mark:1;
> + /* Used in tunnel GRO receive */
> + u8 encap_mark:1;
>
> /* GRO checksum is valid */
> u8 csum_valid:1;
> diff --git a/net/core/dev.c b/net/core/dev.c
> index edb7179..43c74ca 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4438,7 +4438,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
> NAPI_GRO_CB(skb)->same_flow = 0;
> NAPI_GRO_CB(skb)->flush = 0;
> NAPI_GRO_CB(skb)->free = 0;
> - NAPI_GRO_CB(skb)->udp_mark = 0;
> + NAPI_GRO_CB(skb)->encap_mark = 0;
> NAPI_GRO_CB(skb)->gro_remcsum_start = 0;
>
> /* Setup for GRO checksum validation */
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 9659233..0fefba6 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1380,6 +1380,19 @@ out:
> return pp;
> }
>
> +static struct sk_buff **ipip_gro_receive(struct sk_buff **head,
> + struct sk_buff *skb)
> +{
> + if (NAPI_GRO_CB(skb)->encap_mark) {
> + NAPI_GRO_CB(skb)->flush = 1;
> + return NULL;
> + }
> +
> + NAPI_GRO_CB(skb)->encap_mark = 1;
> +
> + return inet_gro_receive(head, skb);
> +}
> +
> #define SECONDS_PER_DAY 86400
>
> /* inet_current_timestamp - Return IP network timestamp
> @@ -1682,7 +1695,7 @@ static struct packet_offload ip_packet_offload __read_mostly = {
> static const struct net_offload ipip_offload = {
> .callbacks = {
> .gso_segment = inet_gso_segment,
> - .gro_receive = inet_gro_receive,
> + .gro_receive = ipip_gro_receive,
> .gro_complete = ipip_gro_complete,
> },
> };
> diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
> index 540866d..dd03161 100644
> --- a/net/ipv4/gre_offload.c
> +++ b/net/ipv4/gre_offload.c
> @@ -126,6 +126,11 @@ static struct sk_buff **gre_gro_receive(struct sk_buff **head,
> struct packet_offload *ptype;
> __be16 type;
>
> + if (NAPI_GRO_CB(skb)->encap_mark)
> + goto out;
> +
> + NAPI_GRO_CB(skb)->encap_mark = 1;
> +
> off = skb_gro_offset(skb);
> hlen = off + sizeof(*greh);
> greh = skb_gro_header_fast(skb, off);
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 8a3405a..8007f73 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -311,14 +311,14 @@ struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb,
> unsigned int off = skb_gro_offset(skb);
> int flush = 1;
>
> - if (NAPI_GRO_CB(skb)->udp_mark ||
> + if (NAPI_GRO_CB(skb)->encap_mark ||
> (skb->ip_summed != CHECKSUM_PARTIAL &&
> NAPI_GRO_CB(skb)->csum_cnt == 0 &&
> !NAPI_GRO_CB(skb)->csum_valid))
> goto out;
>
> - /* mark that this skb passed once through the udp gro layer */
> - NAPI_GRO_CB(skb)->udp_mark = 1;
> + /* mark that this skb passed once through the tunnel gro layer */
> + NAPI_GRO_CB(skb)->encap_mark = 1;
>
> rcu_read_lock();
> uo_priv = rcu_dereference(udp_offload_base);
> diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
> index eeca943..82e9f30 100644
> --- a/net/ipv6/ip6_offload.c
> +++ b/net/ipv6/ip6_offload.c
> @@ -258,6 +258,19 @@ out:
> return pp;
> }
>
> +static struct sk_buff **sit_gro_receive(struct sk_buff **head,
> + struct sk_buff *skb)
> +{
> + if (NAPI_GRO_CB(skb)->encap_mark) {
> + NAPI_GRO_CB(skb)->flush = 1;
> + return NULL;
> + }
> +
> + NAPI_GRO_CB(skb)->encap_mark = 1;
> +
> + return ipv6_gro_receive(head, skb);
> +}
> +
> static int ipv6_gro_complete(struct sk_buff *skb, int nhoff)
> {
> const struct net_offload *ops;
> @@ -302,7 +315,7 @@ static struct packet_offload ipv6_packet_offload __read_mostly = {
> static const struct net_offload sit_offload = {
> .callbacks = {
> .gso_segment = ipv6_gso_segment,
> - .gro_receive = ipv6_gro_receive,
> + .gro_receive = sit_gro_receive,
> .gro_complete = sit_gro_complete,
> },
> };
> --
> 2.5.0
>
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: mv88e6xxx: Introduce _mv88e6xxx_phy_page_{read,write}
From: Vivien Didelot @ 2016-03-26 19:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: Guenter Roeck, Patrick Uiterwijk, davem, linux, netdev,
Dennis Gilmore, Peter Robinson
In-Reply-To: <20160326191844.GA5547@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
>> "error" definitely doesn't make sense, especially in case of success. If
>> one has a better suggestion that "clear" for the label, I don't really
>> mind.
>
> Hi Vivien, Guenter
>
> page_0 ?
For some unjustified reasons I prefered single word labels, but multiple
words will be cleared indeed.
page_0 is fine. What about an even more explicit "clear_page_0" label?
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: mv88e6xxx: Introduce _mv88e6xxx_phy_page_{read,write}
From: Andrew Lunn @ 2016-03-26 19:18 UTC (permalink / raw)
To: Vivien Didelot
Cc: Guenter Roeck, Patrick Uiterwijk, davem, linux, netdev,
Dennis Gilmore, Peter Robinson
In-Reply-To: <87vb49gkdo.fsf@ketchup.mtl.sfl>
> "error" definitely doesn't make sense, especially in case of success. If
> one has a better suggestion that "clear" for the label, I don't really
> mind.
Hi Vivien, Guenter
page_0 ?
Andrew
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: mv88e6xxx: Clear the PDOWN bit on setup
From: Vivien Didelot @ 2016-03-26 18:36 UTC (permalink / raw)
To: Patrick Uiterwijk, linux, davem
Cc: linux, andrew, netdev, dennis, pbrobinson, Patrick Uiterwijk
In-Reply-To: <1458951004-27424-2-git-send-email-patrick@puiterwijk.org>
Patrick Uiterwijk <patrick@puiterwijk.org> writes:
> Some of the vendor-specific bootloaders set up this part
> of the initialization for us, so this was never added.
> However, since upstream bootloaders don't initialize the
> chip specifically, they leave the fiber MII's PDOWN flag
> set, which means that the CPU port doesn't connect.
>
> This patch checks whether this flag has been clear prior
> by something else, and if not make us clear it.
>
> Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>
> ---
> drivers/net/dsa/mv88e6xxx.c | 99 +++++++++++++++++++++++++++++++--------------
> drivers/net/dsa/mv88e6xxx.h | 8 ++++
> 2 files changed, 76 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> index 13db5d8..05b2efb 100644
> --- a/drivers/net/dsa/mv88e6xxx.c
> +++ b/drivers/net/dsa/mv88e6xxx.c
> @@ -2264,6 +2264,57 @@ static void mv88e6xxx_bridge_work(struct work_struct *work)
> mutex_unlock(&ps->smi_mutex);
> }
>
> +static int _mv88e6xxx_phy_page_write(struct dsa_switch *ds, int port, int page,
> + int reg, int val)
> +{
> + int ret;
> +
> + ret = _mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
> + if (ret < 0)
> + goto clear;
> +
> + ret = _mv88e6xxx_phy_write_indirect(ds, port, reg, val);
> +clear:
> + _mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
> +
> + return ret;
> +}
> +
> +static int _mv88e6xxx_phy_page_read(struct dsa_switch *ds, int port, int page,
> + int reg)
> +{
> + int ret;
> +
> + ret = _mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
> + if (ret < 0)
> + goto clear;
> +
> + ret = _mv88e6xxx_phy_read_indirect(ds, port, reg);
> +clear:
> + _mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
> +
> + return ret;
> +}
> +
> +static int mv88e6xxx_power_on_serdes(struct dsa_switch *ds)
> +{
> + int ret;
> +
> + ret = _mv88e6xxx_phy_page_read(ds, REG_FIBER_SERDES, PAGE_FIBER_SERDES,
> + MII_BMCR);
> + if (ret < 0)
> + return ret;
> +
> + if (ret & BMCR_PDOWN) {
> + ret = ret & ~BMCR_PDOWN;
> + ret = _mv88e6xxx_phy_page_write(ds, REG_FIBER_SERDES,
> + PAGE_FIBER_SERDES, MII_BMCR,
> + ret);
> + }
> +
> + return ret;
> +}
> +
> static int mv88e6xxx_setup_port(struct dsa_switch *ds, int port)
> {
> struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
> @@ -2367,6 +2418,23 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds, int port)
> goto abort;
> }
>
> + /* If this port is connected to a SerDes, make sure the SerDes is not
> + * powered down.
> + */
> + if (mv88e6xxx_6352_family(ds)) {
> + ret = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_STATUS);
> + if (ret < 0)
> + goto abort;
> + ret &= PORT_STATUS_CMODE_MASK;
> + if ((ret == PORT_STATUS_CMODE_100BASE_X) ||
> + (ret == PORT_STATUS_CMODE_1000BASE_X) ||
> + (ret == PORT_STATUS_CMODE_SGMII)) {
> + ret = mv88e6xxx_power_on_serdes(ds);
> + if (ret < 0)
> + goto abort;
> + }
> + }
> +
> /* Port Control 2: don't force a good FCS, set the maximum frame size to
> * 10240 bytes, disable 802.1q tags checking, don't discard tagged or
> * untagged frames on this port, do a destination address lookup on all
> @@ -2708,21 +2776,6 @@ int mv88e6xxx_switch_reset(struct dsa_switch *ds, bool ppu_active)
> return 0;
> }
>
> -static int _mv88e6xxx_phy_page_read(struct dsa_switch *ds, int port, int page,
> - int reg)
> -{
> - int ret;
> -
> - ret = _mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
> - if (ret < 0)
> - goto clear;
> - ret = _mv88e6xxx_phy_read_indirect(ds, port, reg);
> -clear:
> - _mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
> -
> - return ret;
> -}
> -
> int mv88e6xxx_phy_page_read(struct dsa_switch *ds, int port, int page, int reg)
> {
> struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
> @@ -2735,22 +2788,6 @@ int mv88e6xxx_phy_page_read(struct dsa_switch *ds, int port, int page, int reg)
> return ret;
> }
>
> -static int _mv88e6xxx_phy_page_write(struct dsa_switch *ds, int port, int page,
> - int reg, int val)
> -{
> - int ret;
> -
> - ret = _mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
> - if (ret < 0)
> - goto clear;
> -
> - ret = _mv88e6xxx_phy_write_indirect(ds, port, reg, val);
> -clear:
> - _mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
> -
> - return ret;
> -}
> -
> int mv88e6xxx_phy_page_write(struct dsa_switch *ds, int port, int page,
> int reg, int val)
> {
Please introduce directly _mv88e6xxx_phy_page_{read,write} above
mv88e6xxx_setup_port in patch 1/2, where they will actually be
needed. That will avoid to move them in patch 2/2.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: mv88e6xxx: Introduce _mv88e6xxx_phy_page_{read,write}
From: Vivien Didelot @ 2016-03-26 18:32 UTC (permalink / raw)
To: Guenter Roeck, Patrick Uiterwijk
Cc: davem, linux, andrew, netdev, Dennis Gilmore, Peter Robinson
In-Reply-To: <56F5F71B.3090703@roeck-us.net>
Hi Guenter,
Guenter Roeck <linux@roeck-us.net> writes:
>>> Is there some good reason for changing the name of those labels ?
>>
>> Vivien suggested to rename this since it makes more clear that this write is
>> meant to return to page 0 to make sure that phylib doesn't get confused
>> about the currently active page.
>>
>
> And "clear:" accomplishes that ? I would not have guessed.
> Wonder if anyone else does. I would have used a comment.
> /* Try to return to page 0 even after an error */
> or something like that.
"error" definitely doesn't make sense, especially in case of success. If
one has a better suggestion that "clear" for the label, I don't really
mind.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net-next v3.16]r8169: Add delay on set_rx_mode
From: Eric Dumazet @ 2016-03-26 17:19 UTC (permalink / raw)
To: Corcodel Marian; +Cc: netdev, Francois Romieu
In-Reply-To: <1458991291-1600-1-git-send-email-asd@marian1000.go.ro>
On Sat, 2016-03-26 at 13:21 +0200, Corcodel Marian wrote:
> Set one line space extra delay on set_rx_mode for starting
> on full duplex and full speed.
>
> Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
> ---
> drivers/net/ethernet/realtek/r8169.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 0ae8969..457b12a 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -4646,6 +4646,7 @@ static void rtl_set_rx_mode(struct net_device *dev)
> mc_filter[1] = mc_filter[0] = 0xffffffff;
>
> RTL_W32(MAR0 + 4, mc_filter[1]);
> +
> RTL_W32(MAR0 + 0, mc_filter[0]);
>
> RTL_W32(RxConfig, tmp);
Seriously ?
^ permalink raw reply
* Re: [PATCH 1/2 net-next v3.16]r8169: Disable set bit multicast enable per multicast address.
From: Eric Dumazet @ 2016-03-26 17:18 UTC (permalink / raw)
To: Corcodel Marian; +Cc: netdev, Francois Romieu
In-Reply-To: <1458989821-19782-1-git-send-email-asd@marian1000.go.ro>
On Sat, 2016-03-26 at 12:57 +0200, Corcodel Marian wrote:
> This patch correct set bit multicast enable only once per set_rx_mode
> invocation.
>
> Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
> ---
> drivers/net/ethernet/realtek/r8169.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 7f6fb1f..f7b0dfb 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -4619,12 +4619,11 @@ static void rtl_set_rx_mode(struct net_device *dev)
> } else {
> struct netdev_hw_addr *ha;
>
> - rx_mode = AcceptBroadcast | AcceptMyPhys;
> + rx_mode = AcceptBroadcast | AcceptMyPhys | AcceptMulticast;
> mc_filter[1] = mc_filter[0] = 0;
> netdev_for_each_mc_addr(ha, dev) {
> int bit_nr = ether_crc(ETH_ALEN, ha->addr) >> 26;
> mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31);
> - rx_mode |= AcceptMulticast;
> }
> }
>
If the list is empty, why should we enable AcceptMulticast ?
^ permalink raw reply
* [PATCH 2/2 net-next v3.16]r9169: Search for registers on set_rx_mode
From: Corcodel Marian @ 2016-03-26 10:57 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu, Corcodel Marian
In-Reply-To: <1458989821-19782-1-git-send-email-asd@marian1000.go.ro>
This patch add searching for needed registers on set_rx_mode function
and add delay to bee ready.This is for starting on full duplex on full
speed.
Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
---
drivers/net/ethernet/realtek/r8169.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index f7b0dfb..0ae8969 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4604,6 +4604,9 @@ static void rtl_set_rx_mode(struct net_device *dev)
int rx_mode;
u32 tmp = 0;
+ if (!(RTL_R32(MAR0) | RTL_R32(MAR0 + 4) | RTL_R32(RxConfig)))
+ return;
+
if (dev->flags & IFF_PROMISC) {
/* Unconditionally log net taps. */
netif_notice(tp, link, dev, "Promiscuous mode enabled\n");
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2 net-next v3.16]r8169: Disable set bit multicast enable per multicast address.
From: Corcodel Marian @ 2016-03-26 10:57 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu, Corcodel Marian
This patch correct set bit multicast enable only once per set_rx_mode
invocation.
Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
---
drivers/net/ethernet/realtek/r8169.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 7f6fb1f..f7b0dfb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4619,12 +4619,11 @@ static void rtl_set_rx_mode(struct net_device *dev)
} else {
struct netdev_hw_addr *ha;
- rx_mode = AcceptBroadcast | AcceptMyPhys;
+ rx_mode = AcceptBroadcast | AcceptMyPhys | AcceptMulticast;
mc_filter[1] = mc_filter[0] = 0;
netdev_for_each_mc_addr(ha, dev) {
int bit_nr = ether_crc(ETH_ALEN, ha->addr) >> 26;
mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31);
- rx_mode |= AcceptMulticast;
}
}
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox