Network activity LED trigger
Here comes a basic patch that adds a network led activity. It is not
configurable yet, but is enough to make a LED configured with
the network-activity trigger to blink on network activity.
Netdev people can probably comment on the place of ledtrig_network_activity(),
which is probably not adequate. Also the ledtrig_network_activity can be
network device specific for instance.
Signed-off-by: Florian Fainelli [EMAIL PROTECTED]
--
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 80acd08..25d2b58 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -127,5 +127,12 @@ config LEDS_TRIGGER_HEARTBEAT
load average.
If unsure, say Y.
+config LEDS_TRIGGER_NETWORK_ACT
+ tristate LED Network Activity Trigger
+ depends on LEDS_TRIGGER NET
+ help
+ This allow LEDs to be controlled by network activity at layer-3
networking.
+ If unsure, say Y.
+
endmenu
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..bc899d3 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+obj-$(CONFIG_LEDS_TRIGGER_NETWORK_ACT) += ledtrig-network-activity.o
diff --git a/drivers/leds/ledtrig-network-activity.c
b/drivers/leds/ledtrig-network-activity.c
new file mode 100644
index 000..88d17bb
--- /dev/null
+++ b/drivers/leds/ledtrig-network-activity.c
@@ -0,0 +1,61 @@
+/*
+ * LED Network Activity Trigger
+ * based on ledtrig-ide-disk by Richard Purdie
+ *
+ * Copyright 2007 Florian Fainelli [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/module.h
+#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/timer.h
+#include linux/leds.h
+
+static void ledtrig_network_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_network);
+static DEFINE_TIMER(ledtrig_network_timer, ledtrig_network_timerfunc, 0, 0);
+static int network_activity, network_lastactivity;
+
+void ledtrig_network_activity(void)
+{
+ network_activity++;
+ if (!timer_pending(ledtrig_network_timer))
+ mod_timer(ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_network_activity);
+
+static void ledtrig_network_timerfunc(unsigned long data)
+{
+ if (network_lastactivity != network_activity) {
+ network_lastactivity = network_activity;
+ led_trigger_event(ledtrig_network, LED_FULL);
+ mod_timer(ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+ } else {
+ led_trigger_event(ledtrig_network, LED_OFF);
+ }
+}
+
+static int __init ledtrig_network_init(void)
+{
+ led_trigger_register_simple(network-activity, ledtrig_network);
+ return 0;
+}
+
+static void __exit ledtrig_network_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_network);
+}
+
+module_init(ledtrig_network_init);
+module_exit(ledtrig_network_exit);
+
+MODULE_AUTHOR(Florian Fainelli [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(LED Network Activity trigger);
+MODULE_LICENSE(GPL);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 88afcef..ed3774e 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -110,4 +110,10 @@ extern void ledtrig_ide_activity(void);
#define ledtrig_ide_activity() do {} while(0)
#endif
+#ifdef CONFIG_LEDS_TRIGGER_NETWORK_ACT
+extern void ledtrig_network_activity(void);
+#else
+#define ledtrig_network_activity() do {} while(0)
+#endif
+
#endif /* __LINUX_LEDS_H_INCLUDED */
diff --git a/net/core/dev.c b/net/core/dev.c
index 4317c1b..9423b26 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -116,6 +116,7 @@
#include linux/dmaengine.h
#include linux/err.h
#include linux/ctype.h
+#include linux/leds.h
/*
* The list of packet types we will receive (as opposed to discard)
@@ -1451,6 +1452,8 @@ int dev_queue_xmit(struct sk_buff *skb)
gso:
spin_lock_prefetch(dev-queue_lock);
+ ledtrig_network_activity();
+
/* Disable soft irqs for various locks below. Also
* stops preemption for RCU.
*/
pgpnSLPCKnCn3.pgp
Description: PGP signature
[PATCH] Fix kernel unaligned access with r8169 on sparc64
Hi all,
When using the r8169 gigabit ethernet network driver under a Sun Entreprise
450, you will encounter a lot of kernel unaligned access on ip_rcv and
ip_fast_csum. The full report is available here :
http://www.mail-archive.com/debian-bugs-dist%40lists.debian.org/msg363433.htm
The following patch against 2.6.22-rc6 will fix this problem.
Signed-off-by: Florian Fainelli [EMAIL PROTECTED]
--
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 5ec7752..5095dbe 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -69,6 +69,7 @@ VERSION 2.2LK 2005/01/25
#include asm/system.h
#include asm/io.h
#include asm/irq.h
+#include asm/unaligned.h
#ifdef CONFIG_R8169_NAPI
#define NAPI_SUFFIX-NAPI
@@ -224,7 +225,9 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl);
+#if !defined(__sparc__)
static int rx_copybreak = 200;
+#endif
static int use_dac;
static struct {
u32 msg_enable;
@@ -465,8 +468,10 @@ MODULE_AUTHOR(Realtek and the Linux r8169 crew
netdev@vger.kernel.org);
MODULE_DESCRIPTION(RealTek RTL-8169 Gigabit Ethernet driver);
module_param_array(media, int, num_media, 0);
MODULE_PARM_DESC(media, force phy operation. Deprecated by ethtool (8).);
+#if !defined(__sparc__)
module_param(rx_copybreak, int, 0);
MODULE_PARM_DESC(rx_copybreak, Copy breakpoint for copy-only-tiny-frames);
+#endif
module_param(use_dac, int, 0);
MODULE_PARM_DESC(use_dac, Enable PCI DAC. Unsafe on 32 bit PCI slot.);
module_param_named(debug, debug.msg_enable, int, 0);
@@ -2486,10 +2491,25 @@ static inline int rtl8169_try_rx_copy(struct sk_buff
**sk_buff, int pkt_size,
{
int ret = -1;
- if (pkt_size rx_copybreak) {
+#if defined(__sparc__)
+ if (pkt_size) {
struct sk_buff *skb;
+ int i;
+
+ skb = dev_alloc_skb(pkt_size + 4);
+
+ /* align the data to the ip header - should be faster than
copying the entire packet to the stack */
+ for (i = pkt_size - (pkt_size % 4); i = 0; i -= 4) {
+ put_unaligned(*((u32 *) (skb-data + i)), (u32 *)
(skb-data + i + 2));
+ }
+ skb-data += 2;
+ skb-tail += 2;
+#else
+ if (pkt_size rx_copybreak) {
+struct sk_buff *skb;
skb = dev_alloc_skb(pkt_size + align);
+#endif
if (skb) {
skb_reserve(skb, (align - 1) (unsigned
long)skb-data);
eth_copy_and_sum(skb, sk_buff[0]-data, pkt_size, 0);
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] Fix kernel unaligned access with r8169 on sparc64
Few things about this patch. It's pretty quick and dirty, more experienced people with a better knowledge of the ip stack would certainly do better. Though the problem was reported with Debian's 2.6.18 kernel, it is also present in the 2.6.22-rc6 version. Without the patch, I can hardly achieve 130Mbits between two sparcs on a dedicated r8169 link, with it we can achieve 300 Mbits, though it's not purely GigE, it's still three times better. Measures were made using iperf. signature.asc Description: This is a digitally signed message part.
Re: Network activity LED trigger
Hi all,
Here comes a basic patch that adds a network led activity. It is not
configurable yet, but is enough to make a LED configured with
the network-activity trigger to blink on network activity.
Netdev people can probably comment on the place of ledtrig_network_activity(),
which is probably not adequate. Also the ledtrig_network_activity can be
network device specific for instance.
Signed-off-by: Florian Fainelli [EMAIL PROTECTED]
--
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 80acd08..25d2b58 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -127,5 +127,12 @@ config LEDS_TRIGGER_HEARTBEAT
load average.
If unsure, say Y.
+config LEDS_TRIGGER_NETWORK_ACT
+ tristate LED Network Activity Trigger
+ depends on LEDS_TRIGGER NET
+ help
+ This allow LEDs to be controlled by network activity at layer-3
networking.
+ If unsure, say Y.
+
endmenu
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..bc899d3 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+obj-$(CONFIG_LEDS_TRIGGER_NETWORK_ACT) += ledtrig-network-activity.o
diff --git a/drivers/leds/ledtrig-network-activity.c
b/drivers/leds/ledtrig-network-activity.c
new file mode 100644
index 000..88d17bb
--- /dev/null
+++ b/drivers/leds/ledtrig-network-activity.c
@@ -0,0 +1,61 @@
+/*
+ * LED Network Activity Trigger
+ * based on ledtrig-ide-disk by Richard Purdie
+ *
+ * Copyright 2007 Florian Fainelli [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/module.h
+#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/timer.h
+#include linux/leds.h
+
+static void ledtrig_network_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_network);
+static DEFINE_TIMER(ledtrig_network_timer, ledtrig_network_timerfunc, 0, 0);
+static int network_activity, network_lastactivity;
+
+void ledtrig_network_activity(void)
+{
+ network_activity++;
+ if (!timer_pending(ledtrig_network_timer))
+ mod_timer(ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_network_activity);
+
+static void ledtrig_network_timerfunc(unsigned long data)
+{
+ if (network_lastactivity != network_activity) {
+ network_lastactivity = network_activity;
+ led_trigger_event(ledtrig_network, LED_FULL);
+ mod_timer(ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+ } else {
+ led_trigger_event(ledtrig_network, LED_OFF);
+ }
+}
+
+static int __init ledtrig_network_init(void)
+{
+ led_trigger_register_simple(network-activity, ledtrig_network);
+ return 0;
+}
+
+static void __exit ledtrig_network_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_network);
+}
+
+module_init(ledtrig_network_init);
+module_exit(ledtrig_network_exit);
+
+MODULE_AUTHOR(Florian Fainelli [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(LED Network Activity trigger);
+MODULE_LICENSE(GPL);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 88afcef..ed3774e 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -110,4 +110,10 @@ extern void ledtrig_ide_activity(void);
#define ledtrig_ide_activity() do {} while(0)
#endif
+#ifdef CONFIG_LEDS_TRIGGER_NETWORK_ACT
+extern void ledtrig_network_activity(void);
+#else
+#define ledtrig_network_activity() do {} while(0)
+#endif
+
#endif /* __LINUX_LEDS_H_INCLUDED */
diff --git a/net/core/dev.c b/net/core/dev.c
index 4317c1b..9423b26 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -116,6 +116,7 @@
#include linux/dmaengine.h
#include linux/err.h
#include linux/ctype.h
+#include linux/leds.h
/*
* The list of packet types we will receive (as opposed to discard)
@@ -1451,6 +1452,8 @@ int dev_queue_xmit(struct sk_buff *skb)
gso:
spin_lock_prefetch(dev-queue_lock);
+ ledtrig_network_activity();
+
/* Disable soft irqs for various locks below. Also
* stops preemption for RCU.
*/
pgpJH7KHRnzRF.pgp
Description: PGP signature
Network activity LED trigger
Hi All, I have been talking a bit with Richard, who is the LED API maintainer, and a LED trigger based on network activity would be something great. There are somethings that concern the network stack : - should we specify if the network driver is allowed to contribute to the LED activity, just like it is done for random generation, at compile time - I would like to trigger the LED based on one or several network interfaces, maybe specify via sysfs which interface triggers which LED, and also maybe differentiate the layer-2 activity from the layer-3 activity for instance - A led driver could by default be bound to a network driver, or an interface name As it could be very intrusive in the network stack, you might want to specify a bit more how you imagine a network activity trigger. Thanks -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network activity LED trigger
Hi All, Some more thoughts. The IDE activity LED trigger is currently triggered when a function is called in the IDE writing/reading routines. In a similar way, we could call the trigger function in net/core/dev.c in netif_receive_skb and netif_rx ? I was also thinking that some network NIC already have LEDs, so it is not necessary for those models to overload the user with lights everywhere. Regars, Florian Le jeudi 1 mars 2007, Florian Fainelli a écrit : Hi All, I have been talking a bit with Richard, who is the LED API maintainer, and a LED trigger based on network activity would be something great. There are somethings that concern the network stack : - should we specify if the network driver is allowed to contribute to the LED activity, just like it is done for random generation, at compile time - I would like to trigger the LED based on one or several network interfaces, maybe specify via sysfs which interface triggers which LED, and also maybe differentiate the layer-2 activity from the layer-3 activity for instance - A led driver could by default be bound to a network driver, or an interface name As it could be very intrusive in the network stack, you might want to specify a bit more how you imagine a network activity trigger. Thanks - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network activity LED trigger
Hi, Le vendredi 2 mars 2007, jamal a écrit : Where are these LEDs typically located? Are you talking about LEDs on a network card for example? can you light them up in different colors? Those LEDS are typically controlled by GPIO lines visible in front of the device. It is mostly targeted to embedded devices for which you do not necessarily want to assign a LED to a given network interface cheers, jamal On Fri, 2007-02-03 at 13:58 +0100, Florian Fainelli wrote: Hi All, Some more thoughts. The IDE activity LED trigger is currently triggered when a function is called in the IDE writing/reading routines. In a similar way, we could call the trigger function in net/core/dev.c in netif_receive_skb and netif_rx ? I was also thinking that some network NIC already have LEDs, so it is not necessary for those models to overload the user with lights everywhere. R - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cordialement, Florian Fainelli - 5, rue Charles Fourier Chambre 1202 91011 Evry http://www.alphacore.net (+33) 01 60 76 64 21 (+33) 06 09 02 64 95 - Association MiNET http://www.minet.net - Institut National des Télécommunication http://www.int-evry.fr/telecomint - - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add a network activity LED trigger
Hi all,
This patch adds a new LED trigger, based on network activity. It gathers
activity from net/core/dev.c and can be used as a LED trigger by
specifying network-activity. Further version should allow the user to
specify the network interface to bind a LED to. This trigger is a simple
trigger as defined by the LED subsystem.
Signed-off-by: Florian Fainelli [EMAIL PROTECTED]
--
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 87d2046..fdc5a8a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -128,5 +128,12 @@ config LEDS_TRIGGER_HEARTBEAT
load average.
If unsure, say Y.
+config LEDS_TRIGGER_NETWORK_ACT
+ tristate LED Network Activity Trigger
+ depends on LEDS_TRIGGERS NET
+ help
+ This allow LEDs to be controlled by network activity at layer-3
networking.
+ If unsure, say Y.
+
endmenu
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..bc899d3 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+obj-$(CONFIG_LEDS_TRIGGER_NETWORK_ACT) += ledtrig-network-activity.o
diff --git a/drivers/leds/ledtrig-network-activity.c
b/drivers/leds/ledtrig-network-activity.c
new file mode 100644
index 000..5c2e051
--- /dev/null
+++ b/drivers/leds/ledtrig-network-activity.c
@@ -0,0 +1,63 @@
+/*
+ * LED Network Activity Trigger
+ *
+ * based on ledtrig-ide-disk by Richard Purdie
+ *
+ * Copyright 2007 Florian Fainelli [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/module.h
+#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/timer.h
+#include linux/leds.h
+
+static void ledtrig_network_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_network);
+static DEFINE_TIMER(ledtrig_network_timer, ledtrig_network_timerfunc, 0, 0);
+static int network_activity;
+static int network_lastactivity;
+
+void ledtrig_network_activity(void)
+{
+ network_activity++;
+ if (!timer_pending(ledtrig_network_timer))
+ mod_timer(ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_network_activity);
+
+static void ledtrig_network_timerfunc(unsigned long data)
+{
+ if (network_lastactivity != network_activity) {
+ network_lastactivity = network_activity;
+ led_trigger_event(ledtrig_network, LED_FULL);
+ mod_timer(ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+ } else {
+ led_trigger_event(ledtrig_network, LED_OFF);
+ }
+}
+
+static int __init ledtrig_network_init(void)
+{
+ led_trigger_register_simple(network-activity, ledtrig_network);
+ return 0;
+}
+
+static void __exit ledtrig_network_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_network);
+}
+
+module_init(ledtrig_network_init);
+module_exit(ledtrig_network_exit);
+
+MODULE_AUTHOR(Florian Fainelli [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(LED Network Activity trigger);
+MODULE_LICENSE(GPL);
diff --git a/net/core/dev.c b/net/core/dev.c
index ee051bb..a3a4115 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -117,6 +117,7 @@
#include linux/err.h
#include linux/ctype.h
#include linux/if_arp.h
+#include linux/leds.h
/*
* The list of packet types we will receive (as opposed to discard)
@@ -1523,6 +1524,7 @@ gso:
* stops preemption for RCU.
*/
rcu_read_lock_bh();
+ ledtrig_network_activity();
/* Updates of qdisc are serialized by queue_lock.
* The struct Qdisc which is pointed to by qdisc is now a
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] Add a network activity LED trigger
Hello Patrick, Le mercredi 18 juillet 2007, Patrick McHardy a écrit : Module isn't possible, you call the led trigger from net/core/dev.c. You are right, it just occured to me. Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. Could you suggest me a better way to do so ? The code was highly inspired from what is done with the IDE trigger. The declaration is done in linux/leds.h, which is included in dev.c for that purpose. Thank you very much for your answer. signature.asc Description: This is a digitally signed message part.
[PATCH] Au1000 eth : fix ioctl handling
Hi all,
This patch fixes the handling of unsupported ioctls with the au1000_eth
driver.
Signed-off-by: Florian Fainelli [EMAIL PROTECTED]
--
diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
index c27cfce..99a1c61 100644
--- a/drivers/net/au1000_eth.c
+++ b/drivers/net/au1000_eth.c
@@ -1316,12 +1316,20 @@ static void set_rx_mode(struct net_device *dev)
static int au1000_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct au1000_private *aup = (struct au1000_private *)dev-priv;
+ struct mii_ioctl_data *data = if_mii(rq);
+ int rc = -EOPNOTSUPP;
if (!netif_running(dev)) return -EINVAL;
if (!aup-phy_dev) return -EINVAL; // PHY not controllable
- return phy_mii_ioctl(aup-phy_dev, if_mii(rq), cmd);
+ switch (cmd) {
+ default:
+ rc = phy_mii_ioctl(aup-phy_dev, data, cmd);
+ break;
+ }
+
+ return rc;
}
static struct net_device_stats *au1000_get_stats(struct net_device *dev)
signature.asc
Description: This is a digitally signed message part.
[PATCH][RFC] Add support for the RDC R6040 Fast Ethernet controller
This patch adds support for the RDC R6040 MAC we can find in the RDC R-321x System-on-chips. This driver really needs improvements especially on the NAPI part which probably does not fully use the new NAPI structure. You will need the RDC PCI identifiers if you want to test this driver which are the following ones : RDC_PCI_VENDOR_ID = 0x17f3 RDC_PCI_DEVICE_ID_RDC_R6040 = 0x6040 Thank you very much in advance for your comments. Signed-off-by: Sten Wang [EMAIL PROTECTED] Signed-off-by: Daniel Gimpelevich [EMAIL PROTECTED] Signed-off-by: Florian Fainelli [EMAIL PROTECTED] --- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index ce34b53..c8a5eef 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1643,6 +1643,24 @@ config 8139_OLD_RX_RESET experience problems, you can enable this option to restore the old RX-reset behavior. If unsure, say N. +config R6040 + tristate RDC R6040 Fast Ethernet Adapter support (EXPERIMENTAL) + depends on NET_PCI PCI EXPERIMENTAL + select MII + help + This is a driver for the R6040 Fast Ethernet MACs found in the + the RDC R-321x System-on-chips. + + To compile this driver as a module, choose M here: the module + will be called r6040. This is recommended. + +config R6040_NAPI + bool NAPI support for R6040 + depends on R6040 + default y + help + Enable the NAPI polling for the R6040 driver. + config SIS900 tristate SiS 900/7016 PCI Fast Ethernet Adapter support depends on NET_PCI PCI diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 22f78cb..5fb95ca 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_VIA_RHINE) += via-rhine.o obj-$(CONFIG_VIA_VELOCITY) += via-velocity.o obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o obj-$(CONFIG_RIONET) += rionet.o +obj-$(CONFIG_R6040) += r6040.o # # end link order section diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c new file mode 100644 index 000..ada1b7f --- /dev/null +++ b/drivers/net/r6040.c @@ -0,0 +1,970 @@ +/* + * RDC R6040 Fast Ethernet MAC support + * + * Copyright (C) 2004 Sten Wang [EMAIL PROTECTED] + * Copyright (C) 2007 Daniel Gimpelevich [EMAIL PROTECTED] + * Florian Fainelli [EMAIL PROTECTED] + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the + * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, + * Boston, MA 02110-1301, USA. + * + * Changelog : + * -- + * 10-07-2007 Clean up the driver using checkpatch + * 08-24-2006 Support at linux 2.6.10 above + * 03-24-2006 Support NAPI + * 03-21-2006 change spin_lock_irqsave(lp-lock, flags) + * to spin_lock_irqsave(lp-lock, flags) + * in set_multicast_list + * 03-15-2006 Modify the set_multicast_list ,due to when re-plug the ethernet, + * it will forget the previous setting + * 07-12-2005 modify the set_multicast_list + * 03-28-2005 modify some error mac register offset in + * function set_multicast_list + * 03-27-2005 Add the internal state machine reset + * If multicast address more than 4, enter PROM mode + * Changed rdc to r6040 + * 12-22-2004 Sten Init MAC MBCR register=0x012A + * PHY_CAP = 0x01E1 + * + * Need to Do LIst: + * 1. If multicast address more than 4, use the multicast address hash +*/ + +#include linux/kernel.h +#include linux/module.h +#include linux/version.h +#include linux/moduleparam.h +#include linux/string.h +#include linux/timer.h +#include linux/errno.h +#include linux/ioport.h +#include linux/slab.h +#include linux/interrupt.h +#include linux/pci.h +#include linux/netdevice.h +#include linux/etherdevice.h +#include linux/skbuff.h +#include linux/init.h +#include linux/delay.h +#include linux/mii.h +#include linux/ethtool.h +#include linux/crc32.h +#include linux/spinlock.h + +#include asm/processor.h +#include asm/bitops.h +#include asm/io.h +#include asm/irq.h +#include asm/uaccess.h + +#define DRV_NAME r6040 +#define DRV_VERSION0.14 +#define DRV_RELDATE29Oct2007 + +/* PHY CHIP Address */ +#define PHY1_ADDR 1
[PATCH][RFC take 2] Add support for the RDC R6040 Fast Ethernet controller
This patch adds support for the RDC R6040 MAC we can find in the RDC R-321x System-on-chips and some other devices. You will need the RDC PCI identifiers if you want to test this driver : RDC_PCI_VENDOR_ID = 0x17f3 RDC_PCI_DEVICE_ID_RDC_R6040 = 0x6040 Changes from first patch : - use ioread/iowrite - cleaned up NAPI - suppressed wrong use of local_irq_enable/disable - handle multicast cases - notify when the carrier changes - add ethtool routines - rewrite IRQ handling with - cleaned up PCI table - make checkpatch happy - documented registers - (I do not mention everything you have been saying in your mails, but I have fixed them as well). Thanks to Jeff and Stephen for their detailed comments. Signed-off-by: Sten Wang [EMAIL PROTECTED] Signed-off-by: Daniel Gimpelevich [EMAIL PROTECTED] Signed-off-by: Florian Fainelli [EMAIL PROTECTED] -- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index cb581eb..ab84303 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1645,6 +1645,18 @@ config 8139_OLD_RX_RESET experience problems, you can enable this option to restore the old RX-reset behavior. If unsure, say N. +config R6040 + tristate RDC R6040 Fast Ethernet Adapter support (EXPERIMENTAL) + depends on NET_PCI PCI + select CRC32 + select MII + help + This is a driver for the R6040 Fast Ethernet MACs found in the + the RDC R-321x System-on-chips. + + To compile this driver as a module, choose M here: the module + will be called r6040. This is recommended. + config SIS900 tristate SiS 900/7016 PCI Fast Ethernet Adapter support depends on NET_PCI PCI diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 0e5fde4..afc60df 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_TLAN) += tlan.o obj-$(CONFIG_EPIC100) += epic100.o obj-$(CONFIG_SIS190) += sis190.o obj-$(CONFIG_SIS900) += sis900.o +obj-$(CONFIG_R6040) += r6040.o obj-$(CONFIG_YELLOWFIN) += yellowfin.o obj-$(CONFIG_ACENIC) += acenic.o obj-$(CONFIG_ISERIES_VETH) += iseries_veth.o diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c new file mode 100644 index 000..0cc47a6 --- /dev/null +++ b/drivers/net/r6040.c @@ -0,0 +1,1110 @@ +/* + * RDC R6040 Fast Ethernet MAC support + * + * Copyright (C) 2004 Sten Wang [EMAIL PROTECTED] + * Copyright (C) 2007 + * Daniel Gimpelevich [EMAIL PROTECTED] + * Florian Fainelli [EMAIL PROTECTED] + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the + * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, + * Boston, MA 02110-1301, USA. +*/ + +#include linux/kernel.h +#include linux/module.h +#include linux/version.h +#include linux/moduleparam.h +#include linux/string.h +#include linux/timer.h +#include linux/errno.h +#include linux/ioport.h +#include linux/slab.h +#include linux/interrupt.h +#include linux/pci.h +#include linux/netdevice.h +#include linux/etherdevice.h +#include linux/skbuff.h +#include linux/init.h +#include linux/delay.h +#include linux/mii.h +#include linux/ethtool.h +#include linux/crc32.h +#include linux/spinlock.h + +#include asm/processor.h +#include asm/bitops.h +#include asm/io.h +#include asm/irq.h +#include asm/uaccess.h + +#define DRV_NAME r6040 +#define DRV_VERSION0.16 +#define DRV_RELDATE10Nov2007 + +/* PHY CHIP Address */ +#define PHY1_ADDR 1 /* For MAC1 */ +#define PHY2_ADDR 2 /* For MAC2 */ +#define PHY_MODE 0x3100 /* PHY CHIP Register 0 */ +#define PHY_CAP0x01E1 /* PHY CHIP Register 4 */ + +/* Time in jiffies before concluding the transmitter is hung. */ +#define TX_TIMEOUT (6000 * HZ / 1000) +#define TIMER_WUT (jiffies + HZ * 1)/* timer wakeup time : 1 second */ + +/* RDC MAC I/O Size */ +#define R6040_IO_SIZE 256 + +/* MAX RDC MAC */ +#define MAX_MAC2 + +/* MAC registers */ +#define MCR0 0x00/* Control register 0 */ +#define MCR1 0x04/* Control register 1 */ +#define MAC_RST 0x0001 /* Reset the MAC */ +#define MBCR 0x08/* Bus control */ +#define MT_ICR 0x0C/* TX interrupt control */ +#define MR_ICR 0x10/* RX interrupt control */ +#define MTPR 0x14/* TX poll command register */ +#define MR_BSR 0x18/* RX buffer size
[PATCH] Add support for the RDC R6040 Fast Ethernet controller
This patch adds support for the RDC R6040 MAC we can find in the RDC R-321x System-on-chips. Signed-off-by: Sten Wang [EMAIL PROTECTED] Signed-off-by: Daniel Gimpelevich [EMAIL PROTECTED] Signed-off-by: Florian Fainelli [EMAIL PROTECTED] -- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index cb581eb..ab84303 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1645,6 +1645,18 @@ config 8139_OLD_RX_RESET experience problems, you can enable this option to restore the old RX-reset behavior. If unsure, say N. +config R6040 + tristate RDC R6040 Fast Ethernet Adapter support (EXPERIMENTAL) + depends on NET_PCI PCI + select CRC32 + select MII + help + This is a driver for the R6040 Fast Ethernet MACs found in the + the RDC R-321x System-on-chips. + + To compile this driver as a module, choose M here: the module + will be called r6040. This is recommended. + config SIS900 tristate SiS 900/7016 PCI Fast Ethernet Adapter support depends on NET_PCI PCI diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 0e5fde4..afc60df 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_TLAN) += tlan.o obj-$(CONFIG_EPIC100) += epic100.o obj-$(CONFIG_SIS190) += sis190.o obj-$(CONFIG_SIS900) += sis900.o +obj-$(CONFIG_R6040) += r6040.o obj-$(CONFIG_YELLOWFIN) += yellowfin.o obj-$(CONFIG_ACENIC) += acenic.o obj-$(CONFIG_ISERIES_VETH) += iseries_veth.o diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c new file mode 100644 index 000..edce5a4 --- /dev/null +++ b/drivers/net/r6040.c @@ -0,0 +1,1109 @@ +/* + * RDC R6040 Fast Ethernet MAC support + * + * Copyright (C) 2004 Sten Wang [EMAIL PROTECTED] + * Copyright (C) 2007 + * Daniel Gimpelevich [EMAIL PROTECTED] + * Florian Fainelli [EMAIL PROTECTED] + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the + * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, + * Boston, MA 02110-1301, USA. +*/ + +#include linux/kernel.h +#include linux/module.h +#include linux/version.h +#include linux/moduleparam.h +#include linux/string.h +#include linux/timer.h +#include linux/errno.h +#include linux/ioport.h +#include linux/slab.h +#include linux/interrupt.h +#include linux/pci.h +#include linux/netdevice.h +#include linux/etherdevice.h +#include linux/skbuff.h +#include linux/init.h +#include linux/delay.h +#include linux/mii.h +#include linux/ethtool.h +#include linux/crc32.h +#include linux/spinlock.h + +#include asm/processor.h +#include asm/bitops.h +#include asm/io.h +#include asm/irq.h +#include asm/uaccess.h + +#define DRV_NAME r6040 +#define DRV_VERSION0.16 +#define DRV_RELDATE10Nov2007 + +/* PHY CHIP Address */ +#define PHY1_ADDR 1 /* For MAC1 */ +#define PHY2_ADDR 2 /* For MAC2 */ +#define PHY_MODE 0x3100 /* PHY CHIP Register 0 */ +#define PHY_CAP0x01E1 /* PHY CHIP Register 4 */ + +/* Time in jiffies before concluding the transmitter is hung. */ +#define TX_TIMEOUT (6000 * HZ / 1000) +#define TIMER_WUT (jiffies + HZ * 1)/* timer wakeup time : 1 second */ + +/* RDC MAC I/O Size */ +#define R6040_IO_SIZE 256 + +/* MAX RDC MAC */ +#define MAX_MAC2 + +/* MAC registers */ +#define MCR0 0x00/* Control register 0 */ +#define MCR1 0x04/* Control register 1 */ +#define MAC_RST 0x0001 /* Reset the MAC */ +#define MBCR 0x08/* Bus control */ +#define MT_ICR 0x0C/* TX interrupt control */ +#define MR_ICR 0x10/* RX interrupt control */ +#define MTPR 0x14/* TX poll command register */ +#define MR_BSR 0x18/* RX buffer size */ +#define MR_DCR 0x1A/* RX descriptor control */ +#define MLSR 0x1C/* Last status */ +#define MMDIO 0x20/* MDIO control register */ +#define MDIO_WRITE0x4000 /* MDIO write */ +#define MDIO_READ 0x2000 /* MDIO read */ +#define MMRD 0x24/* MDIO read data register */ +#define MMWD 0x28/* MDIO write data register */ +#define MTD_SA00x2C/* TX descriptor start address 0 */ +#define MTD_SA10x30/* TX descriptor start address 1 */ +#define MRD_SA00x34/* RX descriptor start address 0
Re: [PATCH] Add support for the RDC R6040 Fast Ethernet controller
Le Tuesday 13 November 2007 06:31:32 David Miller, vous avez écrit : I've added this to my netdev-2.6 tree, thanks! Thanks David ! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] r6040 various bugfixes
Hello Stephen,
Le jeudi 15 novembre 2007, Stephen Hemminger a écrit :
Looks good, thanks:
There is a function to make this easier:
@@ -756,10 +803,8 @@ r6040_open(struct net_device *dev)
if (lp-switch_sig != ICPLUS_PHY_ID) {
/* set and active a timer process */
init_timer(lp-timer);
- lp-timer.expires = TIMER_WUT;
lp-timer.data = (unsigned long)dev;
lp-timer.function = r6040_timer;
- add_timer(lp-timer);
Could be:
setup_timer(lp-timer, r6040_timer, dev);
if (lp-switch_sig != ICPLUS_PHY_ID)
mod_timer(lp-timer, jiffies + HZ);
I will send a fix later when I have tested your suggestion to use slightly
larger buffer and skb_reserve(skb, NET_IP_ALIGN).
Thank you.
--
Florian
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] r6040 various bugfixes
This patch fixes various bugfixes spotted by Stephen, thanks !
- add functions to allocate/free TX and RX buffers
- recover from transmit timeout and use the 4 helpers defined below
- use netdev_alloc_skb instead of dev_alloc_skb
- do not use a private stats structure to store statistics
- break each TX/RX error to a separate line for better reading
- suppress volatiles and make checkpatch happy
- better control of the timer
- fix spin_unlock_irq typo in netdev_get_settings
- fix various typos and spelling in the driver
Signed-off-by: Florian Fainelli [EMAIL PROTECTED]
--
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index edce5a4..529c903 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -172,7 +172,6 @@ struct r6040_private {
struct net_device *dev;
struct mii_if_info mii_if;
struct napi_struct napi;
- struct net_device_stats stats;
u16 napi_rx_running;
void __iomem *base;
};
@@ -233,18 +232,121 @@ static void mdio_write(struct net_device *dev, int
mii_id, int reg, int val)
phy_write(ioaddr, lp-phy_addr, reg, val);
}
+static void r6040_free_txbufs(struct net_device *dev)
+{
+ struct r6040_private *lp = netdev_priv(dev);
+ int i;
+
+ for (i = 0; i TX_DCNT; i++) {
+ if (lp-tx_insert_ptr-skb_ptr) {
+ pci_unmap_single(lp-pdev, lp-tx_insert_ptr-buf,
+ MAX_BUF_SIZE, PCI_DMA_TODEVICE);
+ dev_kfree_skb(lp-tx_insert_ptr-skb_ptr);
+ lp-rx_insert_ptr-skb_ptr = NULL;
+ }
+ lp-tx_insert_ptr = lp-tx_insert_ptr-vndescp;
+ }
+}
+
+static void r6040_free_rxbufs(struct net_device *dev)
+{
+ struct r6040_private *lp = netdev_priv(dev);
+ int i;
+
+ for (i = 0; i RX_DCNT; i++) {
+ if (lp-rx_insert_ptr-skb_ptr) {
+ pci_unmap_single(lp-pdev, lp-rx_insert_ptr-buf,
+ MAX_BUF_SIZE, PCI_DMA_FROMDEVICE);
+ dev_kfree_skb(lp-rx_insert_ptr-skb_ptr);
+ lp-rx_insert_ptr-skb_ptr = NULL;
+ }
+ lp-rx_insert_ptr = lp-rx_insert_ptr-vndescp;
+ }
+}
+
+static void r6040_alloc_txbufs(struct net_device *dev)
+{
+ struct r6040_private *lp = netdev_priv(dev);
+ struct r6040_descriptor *descptr;
+ int i;
+ dma_addr_t desc_dma, start_dma;
+
+ lp-tx_free_desc = TX_DCNT;
+ /* Zero all descriptors */
+ memset(lp-desc_pool, 0, ALLOC_DESC_SIZE);
+ lp-tx_insert_ptr = (struct r6040_descriptor *)lp-desc_pool;
+ lp-tx_remove_ptr = lp-tx_insert_ptr;
+
+ /* Init TX descriptor */
+ descptr = lp-tx_insert_ptr;
+ desc_dma = lp-desc_dma;
+ start_dma = desc_dma;
+ for (i = 0; i TX_DCNT; i++) {
+ descptr-ndesc = cpu_to_le32(desc_dma +
+ sizeof(struct r6040_descriptor));
+ descptr-vndescp = (descptr + 1);
+ descptr = (descptr + 1);
+ desc_dma += sizeof(struct r6040_descriptor);
+ }
+ (descptr - 1)-ndesc = cpu_to_le32(start_dma);
+ (descptr - 1)-vndescp = lp-tx_insert_ptr;
+}
+
+static void r6040_alloc_rxbufs(struct net_device *dev)
+{
+ struct r6040_private *lp = netdev_priv(dev);
+ struct r6040_descriptor *descptr;
+ int i;
+ dma_addr_t desc_dma, start_dma;
+
+ lp-rx_free_desc = 0;
+ /* Zero all descriptors */
+ memset(lp-desc_pool, 0, ALLOC_DESC_SIZE);
+ lp-rx_insert_ptr = (struct r6040_descriptor *)lp-tx_insert_ptr +
+ TX_DCNT;
+ lp-rx_remove_ptr = lp-rx_insert_ptr;
+
+ /* Init RX descriptor */
+ start_dma = desc_dma;
+ descptr = lp-rx_insert_ptr;
+ for (i = 0; i RX_DCNT; i++) {
+ descptr-ndesc = cpu_to_le32(desc_dma +
+ sizeof(struct r6040_descriptor));
+ descptr-vndescp = (descptr + 1);
+ descptr = (descptr + 1);
+ desc_dma += sizeof(struct r6040_descriptor);
+ }
+ (descptr - 1)-ndesc = cpu_to_le32(start_dma);
+ (descptr - 1)-vndescp = lp-rx_insert_ptr;
+}
+
static void
r6040_tx_timeout(struct net_device *dev)
{
struct r6040_private *priv = netdev_priv(dev);
+ void __iomem *ioaddr = priv-base;
+ printk(KERN_WARNING %s: transmit timed out, status %4.4x, PHY status
+ %4.4x\n,
+ dev-name, ioread16(ioaddr + MIER),
+ mdio_read(dev, priv-mii_if.phy_id, MII_BMSR));
disable_irq(dev-irq);
napi_disable(priv-napi);
+
spin_lock(priv-lock);
- dev-stats.tx_errors++;
+ /* Clear all descriptors */
+ r6040_free_txbufs(dev);
+ r6040_free_rxbufs(dev);
+ r6040_alloc_txbufs(dev);
+ r6040_alloc_rxbufs(dev);
+
+ /* Reset MAC */
+ iowrite16(MAC_RST, ioaddr + MCR1
Re: [PATCH] r6040 various cleanups
Hi Francois, Francois Romieu a écrit : Thanks, I have split it in parts. The serie should be available shortly at: git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git r6040 You are welcome, thank you for taking care of this driver ! Please note that: 1. TIMER_WUT has been removed as it was not used any more 2. I have kept the difference below. Was the patch really supposed to update the same error counter twice ? You are right, I did not pay attention to this, thanks for fixing ! -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add me as maintainer of the RDC r6040 driver
This patch adds me as maintainer of the RDC R6040 Fast Ethernet driver. Signed-off-by: Florian Fainelli [EMAIL PROTECTED] -- diff --git a/MAINTAINERS b/MAINTAINERS index 9507b42..6038bfb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3162,6 +3162,12 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Maintained +RDC R6040 FAST ETHERNET DRIVER +P: Florian Fainelli +M: [EMAIL PROTECTED] +L: netdev@vger.kernel.org +S: Maintained + READ-COPY UPDATE (RCU) P: Dipankar Sarma M: [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add me as maintainer of the RDC r6040 driver
Hi Jeff, Le samedi 12 janvier 2008, Jeff Garzik a écrit : applied Thank you. I think you will get this change twice when you pull Francoi's netdev-2.6 repository which has the r6040 patches I sent already. -- Cordialement, Florian Fainelli -- -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull request for 'r6040' branch
Hi Francois, Jeff, Le mardi 5 février 2008, Francois Romieu a écrit : Please pull from branch 'r6040' in repository git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git r6040 to get the changes below. I have simply rebased the r6040 branch from december on top of Linus's latest head and given each patch a compile test. The content is identical to Florian's initial work (minus the removal of the unused TIMER_WUT and a duplicate update of an error counter). Thank you very much Francois. Jeff, any news on this ? -- Cordialement, Florian Fainelli -- -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.
On 21/04/15 10:39, Andrew Lunn wrote: I would however say that sysfs is the wrong API. The linux network stack uses netlink for most configuration activities. So i would suggest adding a netlink binding to DSA, and place the code in net/dsa/, not within an MDIO driver. I suppose we could do that, but that sounds like a pretty radical change in how DSA is currently configured (that is statically at boot time), part in order to allow booting from DSA-enabled network devices (e.g: nfsroot). We would keep both DT and platform device. But statically at boot does not work for a USB hotpluggable switch! Is the switch really hotpluggable, or it is the USB-Ethernet adapter connecting to it? If the former, then I agree, if not, I would imagine that there is nothing that prevents creating the switch device first, and wait for its master_netdev to show up later before it starts doing anything useful? -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.
On 21/04/15 05:47, Andrew Lunn wrote: Hi Jan Interesting work, but i think the architecture is wrong. DSA needs an Ethernet device, an MDIO bus, and information about ports on the switch. That requirement is completely artificial as it is today, and just comes from arbitrary limitations imposed in the initial DSA design, something that I am still trying to get away from. The MDIO bus and the Ethernet need no knowledge of DSA. So putting your DSA configuration code in the MDIO driver is wrong. I agree with that. The problem you have is where the put the configuration data. There are the currently two choices, using a platform driver, which you can find some examples of in arch/arm/mach-orion5x, or via device tree. Or you need a new method. Part of your problem is hotplug, since you have a USB device, and no stable names for the ethernet device nor the MDIO device. Your hardware is not fixed, you could hang any switch off the USB device. So it does sound like you need a user space API. I would however say that sysfs is the wrong API. The linux network stack uses netlink for most configuration activities. So i would suggest adding a netlink binding to DSA, and place the code in net/dsa/, not within an MDIO driver. I suppose we could do that, but that sounds like a pretty radical change in how DSA is currently configured (that is statically at boot time), part in order to allow booting from DSA-enabled network devices (e.g: nfsroot). Device tree overlays might be a solution, if you can dynamically load a blob as part of a USB hotplug event. What makes it easier is that both the Ethernet device and MDIO bus are on the same USB device, so all your phandles are within the blob. What is your long term goal? Is this just a development tool? Are you thinking of making a product which integrates both the switch and the USB ethernet onto a USB dongle? This could also change the architecture, since it makes the configuration more fixed. My goal in reworking this weird DSA device/driver model is that you could just register your switch devices as an enhanced phy_driver/spi_driver/pci_driver etc..., such that libphy-ready drivers could just take advantage of that when they scan/detect their MDIO buses and find a switch. We are not quite there yet, but some help could be welcome, here are the WIP patches (tested with platform_driver only so far): https://github.com/ffainelli/linux/tree/dsa-model-b53 -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.
On 21/04/15 10:30, Andrew Lunn wrote: My goal in reworking this weird DSA device/driver model is that you could just register your switch devices as an enhanced phy_driver/spi_driver/pci_driver etc..., such that libphy-ready drivers could just take advantage of that when they scan/detect their MDIO buses and find a switch. We are not quite there yet, but some help could be welcome, here are the WIP patches (tested with platform_driver only so far): We are hijacking another thread, but... I don't understand you here. Who calls dsa_switch_register()? Any driver which is backing the underlying device, if this is a PCI(e) switch, a pci_driver's probe function gets called, and then registers with DSA a switch device, very much like this: https://github.com/ffainelli/linux/commit/f94efc3d7b489955351c01efeafcc89939df388e I know of a board coming soon which has three switch chips on it. There is one MDIO device in the Soc, but there is an external MDIO multiplexor controlled via gpio lines, such that each switch has its own MDIO bus. The DT binding does not support this currently, but the underlying data structures do. How do you envisage dsa_switch_register() to work in such a setup? I would envision something where we can scan all of these switches individually using their respective device drivers, with the help of Device Tree or platform_data, figure out which position in a dsa_switch_tree they should have, and make sure that we create a dsa_switch_tree which reflects that, taking probe ordering into account. All of these switches would be phy_driver instances, like this: https://github.com/ffainelli/linux/commit/4a5c6b17de36377f6a71423b91f80bc1c7fee7be We can keep discussing the details in a separate thread, I think that would be useful. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Resource usages in Linux drivers
On 23/04/15 16:19, Francois Romieu wrote: Sergei Shtylyov sergei.shtyl...@cogentembedded.com : On 4/23/2015 1:08 PM, Jia-Ju Bai wrote: [...] I also find many drivers do not use these managed APIs, especially in ethernet card drivers (like e100, r8169). Is it possible to change them? Patches welcome. :-) I respectfully disagree. Me too, most of the device managed conversions we have seen were bogus because they were done in a semi-automated way without understanding the peculiarities of the network devices, that is the separation between init/open/close that most other device drivers do not have. A typical example is this: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6892b41d9701283085b655c6086fb57a5d63fa47 If someone believes basic resouce management to be too hard or error-prone to handle, he should imvho seriously rise the bar and reconsider the way he wants to contribute to the kernel. Well, for one, we could have a device managed register_netdev() which cleans up resources in case of failures and calls free_netdev() automatically, but is that adding much value? I may hope he who reads e100.c to think about DMA api, bql or rx ring holes avoidance to quote a few ones. Managed API ? Mildly... -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/phy: refactor RTL8211F initialization
On 22/04/15 03:22, Shengzhou Liu wrote:
RTL8211F needs to enalbe TXDLY for RGMII during
phy initialization, so move it to rtl8211f_config
for early initialization.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
cc: Joe Hershberger joe.hershber...@gmail.com
---
drivers/net/phy/realtek.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 3917c82..d48095b 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -43,6 +43,22 @@ static int rtl8211x_config(struct phy_device *phydev)
return 0;
}
+static int rtl8211f_config(struct phy_device *phydev)
+{
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
That part of the change is not documented but has to be, and you should
use genphy_soft_reset() which also takes care of waiting the required
amount of time before BMCR_RESET is cleared.
+
+ if (phydev-interface == PHY_INTERFACE_MODE_RGMII) {
+ /* enable TXDLY */
+ phy_write(phydev, MDIO_DEVAD_NONE,
+ MIIM_RTL8211F_PAGE_SELECT, 0xd08);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x11, 0x109);
Do you need to reset the page selector somehow after this write?
+ }
+
+ genphy_config_aneg(phydev);
+
+ return 0;
+}
+
static int rtl8211x_parse_status(struct phy_device *phydev)
{
unsigned int speed;
@@ -142,13 +158,6 @@ static int rtl8211f_parse_status(struct phy_device
*phydev)
phydev-speed = SPEED_10;
}
- if (phydev-interface == PHY_INTERFACE_MODE_RGMII) {
- /* enable TXDLY */
- phy_write(phydev, MDIO_DEVAD_NONE,
- MIIM_RTL8211F_PAGE_SELECT, 0xd08);
- phy_write(phydev, MDIO_DEVAD_NONE, 0x11, 0x109);
- }
-
return 0;
}
@@ -209,7 +218,7 @@ static struct phy_driver RTL8211F_driver = {
.uid = 0x1cc916,
.mask = 0xff,
.features = PHY_GBIT_FEATURES,
- .config = rtl8211x_config,
+ .config = rtl8211f_config,
.startup = rtl8211f_startup,
.shutdown = genphy_shutdown,
};
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: mdio-gpio: support access that may sleep
On 24/04/15 08:04, David Miller wrote: From: Vivien Didelot vivien.dide...@savoirfairelinux.com Date: Wed, 22 Apr 2015 13:06:54 -0400 Some systems using mdio-gpio may use gpio on message based busses, which require sleeping (e.g. gpio from an I2C I/O expander). Since this driver does not use IRQ handler, it is safe to use the _cansleep suffixed gpio accessors. Signed-off-by: Vivien Didelot vivien.dide...@savoirfairelinux.com Since this is down underneath the layer of an MII bus, you cannot universally say that these routines are always called in a sleepable context. The PHY layer, and the driver itself above that, might call these routines from timers, interruptes etc. The PHY library calls these routines from its state machine workqueue for that reason, or from process context (when invoked via ethtool ioctl). The only special case is phy_mac_interrupt() which is callable from interrupt context, but schedules the state machine workqueue anyway to circumvent the in-interrupt context. If we were not doing that, there would be a number of things broken, for instance the per-MDIO bus mutex would not protect us from anything. In fact, since the whole point of this driver is to provide a specific implementation for programming registers over an MII bus, it's quite rediculuous to say that just because interrupts are not used in this implementation it means that sleeping is always valid. You have to look at all of the (real and potential) users, all the way up into the specific ethernet drivers. It seems to me like this patch in itself is ok, but if there are particular drivers you believe are at risk, then yes, we definitively need to audit those. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: mdio-gpio: support access that may sleep
On 24/04/15 09:01, David Miller wrote: From: Florian Fainelli f.faine...@gmail.com Date: Fri, 24 Apr 2015 08:56:34 -0700 On 24/04/15 08:04, David Miller wrote: From: Vivien Didelot vivien.dide...@savoirfairelinux.com Date: Wed, 22 Apr 2015 13:06:54 -0400 Some systems using mdio-gpio may use gpio on message based busses, which require sleeping (e.g. gpio from an I2C I/O expander). Since this driver does not use IRQ handler, it is safe to use the _cansleep suffixed gpio accessors. Signed-off-by: Vivien Didelot vivien.dide...@savoirfairelinux.com Since this is down underneath the layer of an MII bus, you cannot universally say that these routines are always called in a sleepable context. The PHY layer, and the driver itself above that, might call these routines from timers, interruptes etc. The PHY library calls these routines from its state machine workqueue for that reason, or from process context (when invoked via ethtool ioctl). The only special case is phy_mac_interrupt() which is callable from interrupt context, but schedules the state machine workqueue anyway to circumvent the in-interrupt context. If we were not doing that, there would be a number of things broken, for instance the per-MDIO bus mutex would not protect us from anything. Does the link state polling timer use a workqueue in this manner as well? Yes, the state machine re-schedules its own delayed workqueue at the end of its state processing, no timer/hrtimer is used. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: mdio-gpio: support access that may sleep
On 24/04/15 10:25, Sergei Shtylyov wrote: On 04/24/2015 06:56 PM, Florian Fainelli wrote: Some systems using mdio-gpio may use gpio on message based busses, which require sleeping (e.g. gpio from an I2C I/O expander). Since this driver does not use IRQ handler, it is safe to use the _cansleep suffixed gpio accessors. Signed-off-by: Vivien Didelot vivien.dide...@savoirfairelinux.com Since this is down underneath the layer of an MII bus, you cannot universally say that these routines are always called in a sleepable context. The PHY layer, and the driver itself above that, might call these routines from timers, interruptes etc. The PHY library calls these routines from its state machine workqueue for that reason, or from process context (when invoked via ethtool ioctl). The only special case is phy_mac_interrupt() which is callable from interrupt context, It is not (as we have discussed recently) -- cancel_work_sync() may sleep. True, but that does not invalidate my comment, I meant to write that this is the only function that you *might* potentially want to call from interrupt context, and yet it does not trigger low-level I/O accesses to the underlying MDIO bus, but instead uses the PHY library state machine workqueue to do that. Thanks for the reminder though, that needs fixing ;) -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] Renesas Ethernet AVB driver
On 14/04/15 14:37, Sergei Shtylyov wrote:
+/* Wait for stopping the hardware TX process */
+ravb_wait(ndev, TCCR, TCCR_TSRQ0 | TCCR_TSRQ1 | TCCR_TSRQ2 |
TCCR_TSRQ3,
+ 0);
+
+ravb_wait(ndev, CSR, CSR_TPO0 | CSR_TPO1 | CSR_TPO2 | CSR_TPO3, 0);
+
+/* Stop the E-MAC's RX processes. */
+ravb_write(ndev, ravb_read(ndev, ECMR) ~ECMR_RE, ECMR);
[snip]
+/* Transmited network control queue */
+if (tis TIS_FTF1) {
+ravb_tx_free(ndev, RAVB_NC);
+netif_wake_queue(ndev);
This would be better moved to the NAPI handler.
Maybe, not sure...
+result = IRQ_HANDLED;
+}
[snip]
+if (ecmd-duplex == DUPLEX_FULL)
+priv-duplex = 1;
+else
+priv-duplex = 0;
Why not use what priv-phydev-duplex has cached for you?
Because we compare 'priv-duplex' with 'priv-phydev-duplex' in
ravb_adjust_link(). Or what did you mean?
Oh I see how you are using this now, but it does not look like it is
necessary, since you use phy_ethtool_sset() using phydev-duplex
directly ought to be enough anywhere in your driver? Unless there is a
mode where you are running PHY-less, and not using a fixed PHY to
emulate a PHY...
[...]
+static int ravb_nway_reset(struct net_device *ndev)
+{
+struct ravb_private *priv = netdev_priv(ndev);
+int error = -ENODEV;
+unsigned long flags;
+
+if (priv-phydev) {
Is checking against priv-phydev really necessary, it does not look like
the driver will work or accept an invalid PHY device at all anyway?
You still can run 'ethtool' on a closed network device.
Sure, but that does not mean that priv-phydev becomes NULL, even if you
have called phy_disconnect() in your ndo_close() function, you should
still have a correct priv-phydev reference to the PHY device, no?
[...]
+/* Network device open function for Ethernet AVB */
+static int ravb_open(struct net_device *ndev)
+{
+struct ravb_private *priv = netdev_priv(ndev);
+int error;
+
+napi_enable(priv-napi);
+
+error = request_irq(ndev-irq, ravb_interrupt, IRQF_SHARED,
ndev-name,
+ndev);
+if (error) {
+netdev_err(ndev, cannot request IRQ\n);
+goto out_napi_off;
+}
+
+/* Descriptor set */
+/* +26 gets the maximum ethernet encapsulation, +7 ~7 because the
+ * card needs room to do 8 byte alignment, +2 so we can reserve
+ * the first 2 bytes, and +16 gets room for the status word from
the
+ * card.
+ */
+priv-rx_buffer_size = (ndev-mtu = 1492 ? PKT_BUF_SZ :
+(((ndev-mtu + 26 + 7) ~7) + 2 + 16));
Is not that something that should be moved to a local ndo_change_mtu()
That was copied from sh_eth.c verbatim, I even doubt that the formula
is correct for EtherAVB...
function? What happens if I change the MTU of an interface running, does
not that completely break this RX buffer estimation?
Well, not completely, I think. eth_change_mtu() doesn't allow MTU
1500 bytes, so it looks like we just need to change 1492 to 1500 here.
[...]
+static int ravb_start_xmit(struct sk_buff *skb, struct net_device
*ndev)
+{
+struct ravb_private *priv = netdev_priv(ndev);
+struct ravb_tstamp_skb *ts_skb = NULL;
+struct ravb_tx_desc *desc;
+unsigned long flags;
+void *buffer;
+u32 entry;
+u32 tccr;
+int q;
+
+/* If skb needs TX timestamp, it is handled in network control
queue */
+q = (skb_shinfo(skb)-tx_flags SKBTX_HW_TSTAMP) ? RAVB_NC :
RAVB_BE;
+
+spin_lock_irqsave(priv-lock, flags);
+if (priv-cur_tx[q] - priv-dirty_tx[q] = priv-num_tx_ring[q]
- 4) {
What's so special about 4 here, you don't seem to be using 4 descriptors
Not sure, this was clearly copied from sh_eth.c. Perhaps it's just a
threshold for calling ravb_tx_free()...
Then 1 inclusive or 0 exclusive is probably what you should be comparing
to, otherwise you may just stop the tx queue earlier than needed.
+if (!ravb_tx_free(ndev, q)) {
+netif_warn(priv, tx_queued, ndev, TX FD exhausted.\n);
+netif_stop_queue(ndev);
+spin_unlock_irqrestore(priv-lock, flags);
+return NETDEV_TX_BUSY;
+}
+}
+entry = priv-cur_tx[q] % priv-num_tx_ring[q];
+priv-cur_tx[q]++;
+spin_unlock_irqrestore(priv-lock, flags);
+
+if (skb_put_padto(skb, ETH_ZLEN))
+return NETDEV_TX_OK;
+
+priv-tx_skb[q][entry] = skb;
+buffer = PTR_ALIGN(priv-tx_buffers[q][entry], RAVB_ALIGN);
+memcpy(buffer, skb-data, skb-len);
~1500 bytes memcpy(), not good...
I'm looking in the manual and not finding the hard requirement to
have the buffer address aligned to 128 bytes (RAVB_ALIGN), sigh...
Kimura-san?
+desc = priv-tx_ring[q][entry];
Since we have released the spinlock few lines above, is there something
protecting
Re: [PATCH] net/phy: refactor RTL8211F initialization
Le 22/04/2015 20:53, shengzhou@freescale.com a écrit :
-Original Message-
From: Florian Fainelli [mailto:f.faine...@gmail.com]
Sent: Thursday, April 23, 2015 12:57 AM
To: Liu Shengzhou-B36685; netdev@vger.kernel.org; joe.hershber...@gmail.com
Subject: Re: [PATCH] net/phy: refactor RTL8211F initialization
On 22/04/15 03:22, Shengzhou Liu wrote:
RTL8211F needs to enalbe TXDLY for RGMII during phy initialization, so
move it to rtl8211f_config for early initialization.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
cc: Joe Hershberger joe.hershber...@gmail.com
---
drivers/net/phy/realtek.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 3917c82..d48095b 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -43,6 +43,22 @@ static int rtl8211x_config(struct phy_device *phydev)
return 0;
}
+static int rtl8211f_config(struct phy_device *phydev) {
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
That part of the change is not documented but has to be, and you should use
genphy_soft_reset() which also takes care of waiting the required amount of
time before BMCR_RESET is cleared.
There is no genphy_soft_reset() in current u-boot tree.
Did you mean to submit that against u-boot or Linux? If the latter,
there is absolutely no need to have the same file compile under u-boot
and Linux without changes, that is too restrictive. There is a
genphy_soft_reset() which takes care of waiting for BMCR_RESET to clear,
please use it, there is no guarantee otherwise that a PHY has completed
a reset.
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/3] net/dsa: Refactor dsa_probe()
On 21/04/15 06:26, Jan Kaisrlik wrote: From: Jan Kaisrlik ja.kaisr...@gmail.com This patch refactors dsa_probe in order to simplify code in the patch 2/3. It does not look like you are working on the latest net-next tree, that part of the code has already been refactored to have separate helper functions such as dsa_setup_dst(), dsa_switch_setup() and dsa_switch_setup_one(). -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH iproute2] Use PATH_MAX instead of MAXPATHLEN
On 27/04/15 09:13, Stephen Hemminger wrote: On Sat, 25 Apr 2015 22:33:28 +0200 Felix Janda felix.ja...@posteo.de wrote: They are equivalent but the former is more common. PATH_MAX is specified by POSIX and needs limits.h while MAXPATHLEN has BSD origin and needs sys/param.h. PATH_MAX has already been in use in misc/lnstat.h. Signed-off-by: Felix Janda felix.ja...@posteo.de Iproute2 is intended for use on Linux. It makes more sense to align with Posix than using leftover BSD stuff. Therefore I don't see any point in doing this. My reading from Felix's commit message is that he is attempting to do exactly that: conform to POSIX rather than BSD, which seems to be the direction you are also suggesting here. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH net-next 0/8] net: dsa: New registration API
Hi all, This patch series is the long promised API rework to allow registering DSA switch as PCI, platform, SPI, or PHY drivers, and this is pretty much the grand plan described here: http://permalink.gmane.org/gmane.linux.network/329848 Note that unless appropriate Device Tree or platform_data configuration is changed, this is not conflicting with the current approach of registering DSA switches using the special dsa platform device/driver. Rather this introduces a parallel API which allows drivers to be converted and tested one by one. This has been tested on the following two systems: - Linksys/Cisco EA4500 which has a MV88E6171 at MDIO address 16 - BCM7445 reference board with the on-chip Starfighter 2 switch (MMIO) Note that there are currenlty no incompatibles changes made to existing Device Tree sources, rather, depending on the bus we are probed for, e.g: MDIO the dsa,mii-bus and dsa,ethernet phandles and first cell of the reg property will become obsolete, everything else remains entirely compatible. This is all appearing in patches. Known issues: - the new API probably does not work with multiple switches in a tree since I don't have such a system, I would welcome testing on these particular setups and would help take care of the problems, this is currently the biggest limitation I see - there is a bit of duplication and special casing now, but that is mostly due to having to maintain two different ways of registering DSA drivers, this will eventually go away - on my EA4500, doing PHY-driver registration slows things down dramatically iperf switches from ~700Mbits/sec to ~200Mbits/sec, not sure what's wrong here, could be some sort of RGMII setting going wrong These changes can be pulled from my tree here: https://github.com/ffainelli/linux/tree/dsa-model-proposal Happy testing! Florian Fainelli (8): net: dsa: Move dsa_switch_tree final setup in separate function net: phy: Check fixup lists in get_phy_device() net: phy: Allow PHY devices to identify themselves as Ethernet switches net: mv643xx_eth: Handle Ethernet switches as PHY devices net: dsa: add new API to register switch devices net: dsa: bcm_sf2: make it a real platform driver net: dsa: mv88e6060: make it a proper PHY driver net: dsa: mv88e6xxx: Allow them to be proper PHY drivers drivers/net/dsa/bcm_sf2.c | 239 +++-- drivers/net/dsa/mv88e6060.c| 114 +- drivers/net/dsa/mv88e6123_61_65.c | 116 ++ drivers/net/dsa/mv88e6131.c| 107 + drivers/net/dsa/mv88e6171.c| 95 drivers/net/dsa/mv88e6352.c| 102 drivers/net/dsa/mv88e6xxx.c| 40 - drivers/net/dsa/mv88e6xxx.h| 12 ++ drivers/net/ethernet/marvell/mv643xx_eth.c | 4 +- drivers/net/phy/phy_device.c | 9 +- include/linux/phy.h| 12 ++ include/net/dsa.h | 15 ++ net/dsa/dsa.c | 219 -- 13 files changed, 917 insertions(+), 167 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 0/2] net: systemport: interrupt coalescing support
Hi David, This patch series adds support for RX TX interrupt coalescing in the systemport driver. Florian Fainelli (2): net: systemport: Implement TX coalescing control knobs net: systemport: Implement RX coalescing control knobs drivers/net/ethernet/broadcom/bcmsysport.c | 63 ++ drivers/net/ethernet/broadcom/bcmsysport.h | 2 +- 2 files changed, 64 insertions(+), 1 deletion(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 3/3] net: phy: mdio-gpio: Handle phy_ignore_ta_mask
Update mdiobb_read() to read whether the PHY has a broken turn-around,
and if it does, ignore it to make the read succeeed.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/phy/mdio-bitbang.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mdio-bitbang.c b/drivers/net/phy/mdio-bitbang.c
index daec9b05d168..61a543c788cc 100644
--- a/drivers/net/phy/mdio-bitbang.c
+++ b/drivers/net/phy/mdio-bitbang.c
@@ -165,8 +165,11 @@ static int mdiobb_read(struct mii_bus *bus, int phy, int
reg)
ctrl-ops-set_mdio_dir(ctrl, 0);
- /* check the turnaround bit: the PHY should be driving it to zero */
- if (mdiobb_get_bit(ctrl) != 0) {
+ /* check the turnaround bit: the PHY should be driving it to zero, if
this
+* PHY is listed in phy_ignore_ta_mask as having broken TA, skip that
+*/
+ if (mdiobb_get_bit(ctrl) != 0
+ !(bus-phy_ignore_ta_mask (1 phy))) {
/* PHY didn't drive TA low -- flush any bits it
* may be trying to send.
*/
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the net-next tree with the net tree
2015-05-20 19:59 GMT-07:00 Stephen Rothwell s...@canb.auug.org.au: Hi all, Today's linux-next merge of the net-next tree got a conflict in drivers/net/phy/phy.c between commit c15e10e71ce3 (net: phy: Make sure phy_start() always re-enables the phy interrupts) from the net tree and commit 3e2186e02112 (net: phy: Add state machine state transitions debug prints) from the net-next tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). Looks correct to me, thanks Stephen! -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc drivers/net/phy/phy.c index 47cd578052fc,1457ecf75dcc.. --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@@ -783,7 -794,8 +808,8 @@@ void phy_state_machine(struct work_stru struct delayed_work *dwork = to_delayed_work(work); struct phy_device *phydev = container_of(dwork, struct phy_device, state_queue); - bool needs_aneg = false, do_suspend = false, do_resume = false; + bool needs_aneg = false, do_suspend = false; + enum phy_state old_state; int err = 0; mutex_lock(phydev-lock); -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] net: bcmgenet: improve TX timeout
Dump useful ring statistics along with interrupt status, software
maintained pointers and hardware registers to help troubleshoot TX queue
stalls.
When a timeout occurs, disable TX NAPI for the rings, dump their states
while interrupts are disabled, re-enable interrupts, NAPI and queue flow
control to help with the recovery.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 67 ++
1 file changed, 67 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 6043734ea613..b43b2cb9b830 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2770,12 +2770,79 @@ static int bcmgenet_close(struct net_device *dev)
return ret;
}
+static void bcmgenet_dump_tx_queue(struct bcmgenet_tx_ring *ring)
+{
+ struct bcmgenet_priv *priv = ring-priv;
+ u32 p_index, c_index, intsts, intmsk;
+ struct netdev_queue *txq;
+ unsigned int free_bds;
+ unsigned long flags;
+ bool txq_stopped;
+
+ if (!netif_msg_tx_err(priv))
+ return;
+
+ txq = netdev_get_tx_queue(priv-dev, ring-queue);
+
+ spin_lock_irqsave(ring-lock, flags);
+ if (ring-index == DESC_INDEX) {
+ intsts = ~bcmgenet_intrl2_0_readl(priv, INTRL2_CPU_MASK_STATUS);
+ intmsk = UMAC_IRQ_TXDMA_DONE | UMAC_IRQ_TXDMA_MBDONE;
+ } else {
+ intsts = ~bcmgenet_intrl2_1_readl(priv, INTRL2_CPU_MASK_STATUS);
+ intmsk = 1 ring-index;
+ }
+ c_index = bcmgenet_tdma_ring_readl(priv, ring-index, TDMA_CONS_INDEX);
+ p_index = bcmgenet_tdma_ring_readl(priv, ring-index, TDMA_PROD_INDEX);
+ txq_stopped = netif_tx_queue_stopped(txq);
+ free_bds = ring-free_bds;
+ spin_unlock_irqrestore(ring-lock, flags);
+
+ netif_err(priv, tx_err, priv-dev, Ring %d queue %d status summary\n
+ TX queue status: %s, interrupts: %s\n
+ (sw)free_bds: %d (sw)size: %d\n
+ (sw)p_index: %d (hw)p_index: %d\n
+ (sw)c_index: %d (hw)c_index: %d\n
+ (sw)clean_p: %d (sw)write_p: %d\n
+ (sw)cb_ptr: %d (sw)end_ptr: %d\n,
+ ring-index, ring-queue,
+ txq_stopped ? stopped : active,
+ intsts intmsk ? enabled : disabled,
+ free_bds, ring-size,
+ ring-prod_index, p_index DMA_P_INDEX_MASK,
+ ring-c_index, c_index DMA_C_INDEX_MASK,
+ ring-clean_ptr, ring-write_ptr,
+ ring-cb_ptr, ring-end_ptr);
+}
+
static void bcmgenet_timeout(struct net_device *dev)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
+ u32 int0_enable = 0;
+ u32 int1_enable = 0;
+ unsigned int q;
netif_dbg(priv, tx_err, dev, bcmgenet_timeout\n);
+ bcmgenet_disable_tx_napi(priv);
+
+ for (q = 0; q priv-hw_params-tx_queues; q++)
+ bcmgenet_dump_tx_queue(priv-tx_rings[q]);
+ bcmgenet_dump_tx_queue(priv-tx_rings[DESC_INDEX]);
+
+ bcmgenet_tx_reclaim_all(dev);
+
+ for (q = 0; q priv-hw_params-tx_queues; q++)
+ int1_enable |= (1 q);
+
+ int0_enable = UMAC_IRQ_TXDMA_DONE;
+
+ /* Re-enable TX interrupts if disabled */
+ bcmgenet_intrl2_0_writel(priv, int0_enable, INTRL2_CPU_MASK_CLEAR);
+ bcmgenet_intrl2_1_writel(priv, int1_enable, INTRL2_CPU_MASK_CLEAR);
+
+ bcmgenet_enable_tx_napi(priv);
+
dev-trans_start = jiffies;
dev-stats.tx_errors++;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] net: phy: bcm7xxx: update workaround to fix 100BaseT corner cases
Update the AFE_TX_CONFIG value to solve marginal rise/fall issues observed when the link is operating in 100BaseT. This workaround applies to GPHY revisions D0, E0 and newer. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- drivers/net/phy/bcm7xxx.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c index b5dc59de094e..4dea85bfc545 100644 --- a/drivers/net/phy/bcm7xxx.c +++ b/drivers/net/phy/bcm7xxx.c @@ -136,8 +136,8 @@ static int bcm7xxx_28nm_d0_afe_config_init(struct phy_device *phydev) /* AFE_RX_LP_COUNTER, set RX bandwidth to maximum */ phy_write_misc(phydev, AFE_RX_LP_COUNTER, 0x7fc0); - /* AFE_TX_CONFIG, set 1000BT Cfeed=110 for all ports */ - phy_write_misc(phydev, AFE_TX_CONFIG, 0x0061); + /* AFE_TX_CONFIG, set 100BT Cfeed=011 to improve rise/fall time */ + phy_write_misc(phydev, AFE_TX_CONFIG, 0x431); /* AFE_VDCA_ICTRL_0, set Iq=1101 instead of 0111 for AB symmetry */ phy_write_misc(phydev, AFE_VDCA_ICTRL_0, 0xa7da); @@ -167,6 +167,9 @@ static int bcm7xxx_28nm_e0_plus_afe_config_init(struct phy_device *phydev) /* AFE_RXCONFIG_1, provide more margin for INL/DNL measurement */ phy_write_misc(phydev, AFE_RXCONFIG_1, 0x9b2f); + /* AFE_TX_CONFIG, set 100BT Cfeed=011 to improve rise/fall time */ + phy_write_misc(phydev, AFE_TX_CONFIG, 0x431); + /* AFE_VDCA_ICTRL_0, set Iq=1101 instead of 0111 for AB symmetry */ phy_write_misc(phydev, AFE_VDCA_ICTRL_0, 0xa7da); -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] net: phy: dp83867: Add TI dp83867 phy
On 08/06/15 07:04, Dan Murphy wrote:
Florian
Thanks for the re-review
On 06/03/2015 09:47 PM, Florian Fainelli wrote:
Le 06/02/15 07:34, Dan Murphy a écrit :
Add support for the TI dp83867 Gigabit ethernet phy
device.
The DP83867 is a robust, low power, fully featured
Physical Layer transceiver with integrated PMD
sublayers to support 10BASE-T, 100BASE-TX and
1000BASE-T Ethernet protocols.
Sorry for the late feedback, since this is a new driver, things outline
below can still be submitted as incremental fixes.
[snip]
+Required properties:
+ - reg - The ID number for the phy, usually a small integer
+ - ti,rx_int_delay - RGMII Recieve Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,tx_int_delay - RGMII Transmit Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,fifo_depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
+ for applicable values
We typically use - to separate words in DT properties, not _. I am
not sure about the required nature of these 3 proprietary/specific
properties, cannot there be good reset defaults from the HW in any case?
Yes you are correct I will modify as an incremental fix.
The hardware is defaulted to an internal delay of 2 ns. This value needs to
be adjusted
per product based on trace length. I would anticipate the DT properties to
grow a little as the
part gets used more.
Ok, that makes sense then.
You might want to add a reference to net/phy.txt for the remaiming DT
properties.
[snip]
+
+ if (phy_interface_is_rgmii(phydev)) {
+ ret = phy_write(phydev, MII_DP83867_PHYCTRL,
+ (dp83867-fifo_depth
DP83867_PHYCR_FIFO_DEPTH_SHIFT));
+ if (ret)
+ return ret;
+ }
+
+ if ((phydev-interface = PHY_INTERFACE_MODE_RGMII_ID) ||
+ (phydev-interface = PHY_INTERFACE_MODE_RGMII_RXID)) {
This one has not been converted to use the phy_interface_is_rgmii()
helper, but in fact, once you do that, you could probably just add an
early check for this condition, return, and reduce the indentation for
the normal case/RGMII, and eliminate two redundant condition checks.
This check is different then the generic RGMII check. I am checking to see
if the interface has the internal
delay flag set. The RGMII check is to broad. Maybe I can add a helper for
this
if it makes sense thoughts? Maybe a phy_interface_has_rgmii_int_delay API
just to enter this check.
Oh, I misread the range check. I do not think this deserves a helper
function for now, since that seems to be pretty unique and localized to
your driver for now, but if we have more than one users, factoring
things out would definitively make sense then.
Thanks.
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] net: bcmgenet: power on MII block for all MII modes
The RGMII block is currently only powered on when using RGMII or
RGMII_NO_ID, which is not correct when using the GENET interface in MII
or Reverse MII modes. We always need to power on the RGMII interface for
this block to properly work, regardless of the MII mode in which we
operate.
Fixes: aa09677cba423 (net: bcmgenet: add MDIO routines)
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
David,
I am targetting net here since this is a bug fix, however, we have few
people using MII or Reverse MII with GENET, such that there is no need to
queue this for -stable unless you want to.
Thanks!
drivers/net/ethernet/broadcom/genet/bcmmii.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index e7651b3c6c57..420949cc55aa 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -299,9 +299,6 @@ int bcmgenet_mii_config(struct net_device *dev, bool init)
phy_name = external RGMII (no delay);
else
phy_name = external RGMII (TX delay);
- reg = bcmgenet_ext_readl(priv, EXT_RGMII_OOB_CTRL);
- reg |= RGMII_MODE_EN | id_mode_dis;
- bcmgenet_ext_writel(priv, reg, EXT_RGMII_OOB_CTRL);
bcmgenet_sys_writel(priv,
PORT_MODE_EXT_GPHY, SYS_PORT_CTRL);
break;
@@ -310,6 +307,15 @@ int bcmgenet_mii_config(struct net_device *dev, bool init)
return -EINVAL;
}
+ /* This is an external PHY (xMII), so we need to enable the RGMII
+* block for the interface to work
+*/
+ if (priv-ext_phy) {
+ reg = bcmgenet_ext_readl(priv, EXT_RGMII_OOB_CTRL);
+ reg |= RGMII_MODE_EN | id_mode_dis;
+ bcmgenet_ext_writel(priv, reg, EXT_RGMII_OOB_CTRL);
+ }
+
if (init)
dev_info(kdev, configuring instance for %s\n, phy_name);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: phy: dp83867: Fix device tree entries
On 08/06/15 12:30, Dan Murphy wrote: Fix the device tree entries to modify the '_' to '-'. Also changes the names of the internal delay properties from -int- to -internal- as the -int- appeared as a keyword. Signed-off-by: Dan Murphy dmur...@ti.com Reviewed-by: Florian Fainelli f.faine...@gmail.com -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] net/phy: micrel: Center FLP timing at 16ms
On 05/06/15 15:40, Jaeden Amero wrote:
Link failures have been observed when using the KSZ9031 with HP 1810-8G
and HP 1910-8G network switches. Center the FLP timing at 16ms to help
avoid intermittent link failures.
From the KSZ9031RNX and KSZ9031MNX data sheets revision 2.2, section
Auto-Negotiation Timing:
The KSZ9031[RNX or MNX] Fast Link Pulse (FLP) burst-to-burst
transmit timing for Auto-Negotiation defaults to 8ms. IEEE 802.3
Standard specifies this timing to be 16ms +/-8ms. Some PHY link
partners need to receive the FLP with 16ms centered timing;
otherwise, there can be intermittent link failures and long
link-up times.
After KSZ9031[RNX or MNX] power-up/reset, program the following
register sequence to set the FLP timing to 16ms
Write Register Dh = 0x // Set up register address for MMD – Device
Address 0h
Write Register Eh = 0x0004 // Select Register 4h of MMD – Device
Address 0h
Write Register Dh = 0x4000 // Select register data for MMD – Device
Address 0h, Register 4h
Write Register Eh = 0x0006 // Write value 0x0006 to MMD – Device
Address 0h, Register 4h
Write Register Dh = 0x // Set up register address for MMD – Device
Address 0h
Write Register Eh = 0x0003 // Select Register 3h of MMD – Device
Address 0h
Write Register Dh = 0x4000 // Select register data for MMD – Device
Address 0h, Register 3h
Write Register Eh = 0x1A80 // Write value 0x1A80 to MMD – Device
Address 0h, Register 3h
Write Register 0h, Bit [9] = 1 // Restart Auto-Negotiation
Quoting a portion of the data-sheet on how to do this programming is
very strange considering that the code is going to be the reference, not
the commit message.
Other than that, this looks reasonable.
Signed-off-by: Jaeden Amero jaeden.am...@ni.com
---
drivers/net/phy/micrel.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f23765e..499185e 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -366,6 +366,10 @@ static int ksz9021_config_init(struct phy_device *phydev)
#define KSZ9031_PS_TO_REG60
/* Extended registers */
+/* MMD Address 0x0 */
+#define MII_KSZ9031RN_FLP_BURST_TX_LO3
+#define MII_KSZ9031RN_FLP_BURST_TX_HI4
+
/* MMD Address 0x2 */
#define MII_KSZ9031RN_CONTROL_PAD_SKEW 4
#define MII_KSZ9031RN_RX_DATA_PAD_SKEW 5
@@ -427,6 +431,22 @@ static int ksz9031_of_load_skew_values(struct phy_device
*phydev,
return ksz9031_extended_write(phydev, OP_DATA, 2, reg, newval);
}
+static int ksz9031_center_flp_timing(struct phy_device *phydev)
+{
+ int result;
+
+ /* Center KSZ9031RNX FLP timing at 16ms. */
+ result = ksz9031_extended_write(phydev, OP_DATA, 0,
+ MII_KSZ9031RN_FLP_BURST_TX_HI, 0x0006);
+ result = ksz9031_extended_write(phydev, OP_DATA, 0,
+ MII_KSZ9031RN_FLP_BURST_TX_LO, 0x1A80);
+
+ if (result)
+ return result;
+
+ return genphy_restart_aneg(phydev);
+}
+
static int ksz9031_config_init(struct phy_device *phydev)
{
const struct device *dev = phydev-dev;
@@ -462,7 +482,8 @@ static int ksz9031_config_init(struct phy_device *phydev)
MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
tx_data_skews, 4);
}
- return 0;
+
+ return ksz9031_center_flp_timing(phydev);
}
#define KSZ8873MLL_GLOBAL_CONTROL_4 0x06
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] net/phy: micrel: Center FLP timing at 16ms
On 05/06/15 15:40, Jaeden Amero wrote: In v2, we add an additional cleanup commit to make an array of strings static const and to improve const correctness generally. We also no longer unnecessarily initialize the result variable in ksz9031_center_flp_timing(). In v3, we remove the unnecessary result variable from ksz9031_config_init() introduced by a previous version of net/phy: micrel: Center FLP timing at 16ms. Reviewed-by: Florian Fainelli f.faine...@gmail.com Jaeden Amero (3): net/phy: micrel: Be more const correct net/phy: micrel: Comment MMD address of extended registers net/phy: micrel: Center FLP timing at 16ms drivers/net/phy/micrel.c | 53 ++-- 1 file changed, 38 insertions(+), 15 deletions(-) -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Weird DHCP related problems with net-next
Hi, I am observing a strange problem on net-next (not observed with net, bisection in progress) where the initial DHCP configuration using busybox's udhcpc is able to configure the local interface address and DNS serer, but not the default gateway. Restarting udhcpc a second time does not exhibit this problem. This is a system using SYSTEMPORT and the DSA SF2 switch but I could also observe it on systems using the BCMGENET and Asix USB 2.0 network drivers (all in tree). Are there any netlink/packet/rhashtable changes in net-next, but not in net that could explain that? Note that this is a system with very low entropy on boot? Making the DHCP client more verbose or stracing it did not expose the issue as frequently, so this might be some sort of race condition. Any hints appreciated! -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] net: phy: dp83867: Add TI dp83867 phy
Le 06/02/15 07:34, Dan Murphy a écrit :
Add support for the TI dp83867 Gigabit ethernet phy
device.
The DP83867 is a robust, low power, fully featured
Physical Layer transceiver with integrated PMD
sublayers to support 10BASE-T, 100BASE-TX and
1000BASE-T Ethernet protocols.
Sorry for the late feedback, since this is a new driver, things outline
below can still be submitted as incremental fixes.
[snip]
+Required properties:
+ - reg - The ID number for the phy, usually a small integer
+ - ti,rx_int_delay - RGMII Recieve Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,tx_int_delay - RGMII Transmit Clock Delay - see
dt-bindings/net/ti-dp83867.h
+ for applicable values
+ - ti,fifo_depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
+ for applicable values
We typically use - to separate words in DT properties, not _. I am
not sure about the required nature of these 3 proprietary/specific
properties, cannot there be good reset defaults from the HW in any case?
You might want to add a reference to net/phy.txt for the remaiming DT
properties.
[snip]
+
+ if (phy_interface_is_rgmii(phydev)) {
+ ret = phy_write(phydev, MII_DP83867_PHYCTRL,
+ (dp83867-fifo_depth
DP83867_PHYCR_FIFO_DEPTH_SHIFT));
+ if (ret)
+ return ret;
+ }
+
+ if ((phydev-interface = PHY_INTERFACE_MODE_RGMII_ID) ||
+ (phydev-interface = PHY_INTERFACE_MODE_RGMII_RXID)) {
This one has not been converted to use the phy_interface_is_rgmii()
helper, but in fact, once you do that, you could probably just add an
early check for this condition, return, and reduce the indentation for
the normal case/RGMII, and eliminate two redundant condition checks.
Thanks!
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops
On 02/06/15 23:53, Scott Feldman wrote: On Tue, Jun 2, 2015 at 3:31 PM, nolan no...@cumulusnetworks.com wrote: On 06/02/2015 12:44 AM, Scott Feldman wrote: That brings up an interesting point about having multiple bridges with the same vlan configured. I struggled with that problem with rocker also and I don't have an answer other than don't do that. Or, better put, if you have multiple bridge on the same vlan, just use one bridge for that vlan. Otherwise, I don't know how at the device level to partition the vlan between the bridges. Maybe that's what Vivien is facing also? I can see how this works for software-only bridges, because they should be isolated from each other and independent. But when offloading to a device which sees VLAN XXX global across the entire switch, I don't see how we can preserve the bridge boundaries. Scott, I'm confused by this. I think you're saying this config is problematic: br0: eth0.100, eth1.100 br1: eth2.100, eth3.100 But this works fine today. Ya, this is going to work because br0 and br1 are bridging untagged traffic, but br0 and br1 have different internal VLAN ids for untagged traffic, so there is no crosstalk between bridges. (I'm assuming since you used the ethX.100 format, you've vconfig created a vlan interface on ethX and added the vlan interface to brY). The vlan interface eats the vlan tag and the bridge sees untagged traffic. Could you clarify the issue you're referring to? I'm talking about bridging tagged traffic. E.g.: ip link add name br0 type bridge ip link add name br1 type bridge ip link set dev sw1p1 master br0 ip link set dev sw1p2 master br0 ip link set dev sw1p3 master br1 ip link set dev sw1p4 master br1 bridge vlan add vid 100 dev sw1p1 bridge vlan add vid 100 dev sw1p2 bridge vlan add vid 100 dev sw1p3 bridge vlan add vid 100 dev sw1p4 Now the ports are trunking vlan 100 and the bridge/device see tagged traffic. If the device used floods vlan 100 pkt to all ports in vlan 100, it'll flood to a port outside the bridge. Oops! For the device I'm using (rocker w/ OF-DPA) the bridging table matches on vlan ID and mac_dst. There is no prevision to isolate vlans per bridge. How do you solve the above case with your hardware? For switches that support double-tagging, I suppose you could utilize the fact that packets need to be normalized to include an internal outer tag as well (for both tagged and untagged packets), and utilize that to make sure there is no cross-talk. That way, you can have the same inner VLAN tags on both of your bridges but the internal outer tag can be different. There might be a better solution, like having proper partitioning based on whatever the switch is capable of? -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Weird DHCP related problems with net-next
Hi Andrew, On 09/06/15 12:22, Andrew Lunn wrote: On Tue, Jun 09, 2015 at 11:54:50AM -0700, Florian Fainelli wrote: Hi, I am observing a strange problem on net-next (not observed with net, bisection in progress) where the initial DHCP configuration using busybox's udhcpc is able to configure the local interface address and DNS serer, but not the default gateway. Restarting udhcpc a second time does not exhibit this problem. Hi Florian I've seen something similar, but different, again with DSA involved, on a WiFi Access point. I have debian, and i'm using isc dhcp. It gets an address, sets the address on the interface, but does not add the interface route to the routing table. Not sure about default route, i would have to go check that. Interesting, did you also observe this with 'net', or just with 'net-next'? Contrary to what I reported above, this is only an issue with SYSTEMPORT/DSA/SF2, I could not reproduce this GENET or the Asix driver, I was just conflating two different systems here. My bisection seems to point at this commit: 58c2cb16b116d7feace621bd6b647bbabacfa225 (switchdev: convert fib_ipv4_add/del over to switchdev_port_obj_add/del) And indeed, hacking a bit the kernel to remove the SWITCHDEV/DSA dependencies to leave just DSA makes thing work again. Scott, Jiri, any clues? I can instrument the kernel a bit more to help find what is the problem here. Note that I am observing this on ARM (Andrew probably is as well), where uninitialized stack variables are potentially garbage. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Weird DHCP related problems with net-next
On 09/06/15 13:31, Florian Fainelli wrote: Hi Andrew, On 09/06/15 12:22, Andrew Lunn wrote: On Tue, Jun 09, 2015 at 11:54:50AM -0700, Florian Fainelli wrote: Hi, I am observing a strange problem on net-next (not observed with net, bisection in progress) where the initial DHCP configuration using busybox's udhcpc is able to configure the local interface address and DNS serer, but not the default gateway. Restarting udhcpc a second time does not exhibit this problem. Hi Florian I've seen something similar, but different, again with DSA involved, on a WiFi Access point. I have debian, and i'm using isc dhcp. It gets an address, sets the address on the interface, but does not add the interface route to the routing table. Not sure about default route, i would have to go check that. Interesting, did you also observe this with 'net', or just with 'net-next'? Contrary to what I reported above, this is only an issue with SYSTEMPORT/DSA/SF2, I could not reproduce this GENET or the Asix driver, I was just conflating two different systems here. My bisection seems to point at this commit: 58c2cb16b116d7feace621bd6b647bbabacfa225 (switchdev: convert fib_ipv4_add/del over to switchdev_port_obj_add/del) And indeed, hacking a bit the kernel to remove the SWITCHDEV/DSA dependencies to leave just DSA makes thing work again. Scott, Jiri, any clues? I can instrument the kernel a bit more to help find what is the problem here. Note that I am observing this on ARM (Andrew probably is as well), where uninitialized stack variables are potentially garbage. I see the problem now, DSA does not implement a port_obj_add callback, so when net/ipv4/fib_trie.c::switchdev_fib_ipv4_add() gets to call switchdev_port_obj_add, we return -EOPNOTSUPP, and take the error path in fib_table_insert thus not inserting the route for this interface. Now when I restart the DHCP client, we end-up inserting the default route which is correct, still figuring out what is different here, probably the deletion of the routes by the DHCP client script first is the different condition. At any rate, since switchdev_fib_ipv4_add() returns something that make us take an error path in the fib_trie, something like this seems to fix it for me but I am not well versed enough into the IPv4 routing code to be 100% confident this is the right fix. Also, there are other callers of switchdev_port_obj_add() but a quick look seems to make them safe as they are only called for offloading capable hardware. It still looks not being able to differentiate a hard failure from -EOPNOTSUPP has side effects all over the place diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c index e008057dab46..b683e89b4caa 100644 --- a/net/switchdev/switchdev.c +++ b/net/switchdev/switchdev.c @@ -853,7 +853,7 @@ int switchdev_fib_ipv4_add(u32 dst, int dst_len, struct fib_info *fi, if (!err) fi-fib_flags |= RTNH_F_OFFLOAD; - return err; + return err == -EOPNOTSUPP ? 0 : err; } EXPORT_SYMBOL_GPL(switchdev_fib_ipv4_add); @@ -898,7 +898,7 @@ int switchdev_fib_ipv4_del(u32 dst, int dst_len, struct fib_info *fi, if (!err) fi-fib_flags = ~RTNH_F_OFFLOAD; - return err; + return err == -EOPNOTSUPP ? 0 : err; } EXPORT_SYMBOL_GPL(switchdev_fib_ipv4_del); -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] net: phy: Introduced the PHY_AN_PENDING state
Le 06/09/15 21:36, Keng Soon Cheah a écrit :
The PHY_AN_PENDING state is put as a gate to enter the PHY_AN state
where it will wait for any uncomplete auto-negotiation session to
finish before starting a new one.
This extra state could be used to workaround some auto-negotation
issues from certain vendors.
The typical way to work around these problems are to fix them at the PHY
driver level, see below.
an_pending_timeout module parameter is used to enable the AN_PENDING
transition state. Set it to 0 to disable AN_PENDING state transition,
set it to any non-zero value to specify the timeout period for
PHY_AN_PENDING state in second. The default value is 0.
an_pending_guard module parameter serves as a guard band to delay
the auto-negotiation firing after the previous auto-negotiation
finish.
Signed-off-by: Keng Soon Cheah keng.soon.ch...@ni.com
Conflicts:
drivers/net/phy/phy.c
---
We observed failure in the ethernet link operation when our board pairs
with some network switch model. The problem happens when an
auto-negotiation is started around the time the previous auto-negotiation
complete. We believe this might be an interoperatibility issue between
the PHYs but we need a short-term solution in software to workaround the
issue.
We found that we are able to avoid from hitting the problem by waiting any
pending auto-negotiation to complete before starting a new one and this
patch is designed to serve the purpose.
That sounds like a bug in the PHY state machine and/or the PHY driver if
you are allowed to restart auto-negotiation while one is pending. Now
that the PHY state machine has debug prints built-in, could you capture
a trace of this failing case?
Is this observed with the generic PHY driver or a custom PHY driver?
A PHY_AN_PENDING state is introduced and it will act as a gate to enter
the PHY_AN state. This state will check for auto-negotiation completion
or timeout after an_pending_timeout period, then it will wait for
an_pending_guard before triggering another auto-negotiation.
The following diagram shows the timing diagram
an_pending_timeout an_pending_guard
V V auto-nego
|-||
^
auto-negotiation complete/timeout
We do not have plan to submit this patch upstream (unless the community
feels this patch is useful in general) but we would like to seek for
feedback or advice if this patch could introduce new problems.
As usual with state machines, introducing a new state needs to be
carefully done in order to make sure that all transitions are correct,
so far I would rather work on finding the root cause/extending the
timeout and/or making it configurable on a PHY-driver basis rather than
having this additional state which is more error prone.
Thanks!
---
drivers/net/phy/phy.c | 44 +++-
include/linux/phy.h |3 ++-
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index b2197b5..35e6484 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -38,6 +38,16 @@
#include asm/irq.h
+static unsigned int an_pending_timeout;
+module_param(an_pending_timeout, uint, 0644);
+MODULE_PARM_DESC(an_pending_timeout,
+ Timeout period for PHY_AN_PENDING state in second. 0 to disable
PHY_AN_PENDING state (default));
+
+static unsigned int an_pending_guard;
+module_param(an_pending_guard, uint, 0644);
+MODULE_PARM_DESC(an_pending_guard,
+ Guard band period before firing auto-negotiation from PHY_AN_PENDING
state in second. Default to 0);
+
static const char *phy_speed_to_str(int speed)
{
switch (speed) {
@@ -82,7 +92,6 @@ static const char *phy_state_to_str(enum phy_state st)
return NULL;
}
-
/**
* phy_print_status - Convenience function to print out the current phy
status
* @phydev: the phy_device struct
@@ -485,6 +494,18 @@ int phy_start_aneg(struct phy_device *phydev)
/* Invalidate LP advertising flags */
phydev-lp_advertising = 0;
+ if (an_pending_timeout) {
+ switch (phydev-state) {
+ case PHY_AN_PENDING:
+ case PHY_HALTED:
+ break;
+ default:
+ phydev-state = PHY_AN_PENDING;
+ phydev-link_timeout = an_pending_timeout;
+ goto out_unlock;
+ }
+
+ }
err = phydev-drv-config_aneg(phydev);
if (err 0)
@@ -831,6 +852,27 @@ void phy_state_machine(struct work_struct *work)
phydev-link_timeout = PHY_AN_TIMEOUT;
break;
+ case PHY_AN_PENDING:
+ /* Check if negotiation is done. Break if there's an error */
+ err =
Re: [net PATCH 1/1] net: phy: fix phy link up when limiting speed via device tree
2015-06-25 9:51 GMT-07:00 Mugunthan V N mugunthan...@ti.com:
When limiting phy link speed using max-speed to 100mbps or less on a
giga bit phy, phy never completes auto negotiation and phy state
machine is held in PHY_AN. Fixing this issue by comparing the giga
bit advertise though phydev-supported doesn't have it but phy has
BMSR_ESTATEN set. So that auto negotiation is restarted as old and
new advertise are different and link comes up fine.
This looks valid, however, I am curious why this part of the code:
oldadv = adv;
adv = ~(ADVERTISE_ALL | ADVERTISE_100BASE4 | ADVERTISE_PAUSE_CAP |
ADVERTISE_PAUSE_ASYM);
adv |= ethtool_adv_to_mii_adv_t(advertise);
if (adv != oldadv) {
err = phy_write(phydev, MII_ADVERTISE, adv);
if (err 0)
return err;
changed = 1;
}
Is not flagging this as a change already?
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/phy/phy_device.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index bdfe51f..d551df6 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -796,10 +796,11 @@ static int genphy_config_advert(struct phy_device
*phydev)
if (phydev-supported (SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full)) {
adv |= ethtool_adv_to_mii_ctrl1000_t(advertise);
- if (adv != oldadv)
- changed = 1;
}
+ if (adv != oldadv)
+ changed = 1;
+
err = phy_write(phydev, MII_CTRL1000, adv);
if (err 0)
return err;
--
2.4.4.409.g5b1d901
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net PATCH 1/1] net: phy: fix phy link up when limiting speed via device tree
Le 06/25/15 09:51, Mugunthan V N a écrit :
When limiting phy link speed using max-speed to 100mbps or less on a
giga bit phy, phy never completes auto negotiation and phy state
machine is held in PHY_AN. Fixing this issue by comparing the giga
bit advertise though phydev-supported doesn't have it but phy has
BMSR_ESTATEN set. So that auto negotiation is restarted as old and
new advertise are different and link comes up fine.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Reviewed-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/phy/phy_device.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index bdfe51f..d551df6 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -796,10 +796,11 @@ static int genphy_config_advert(struct phy_device
*phydev)
if (phydev-supported (SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full)) {
adv |= ethtool_adv_to_mii_ctrl1000_t(advertise);
- if (adv != oldadv)
- changed = 1;
}
+ if (adv != oldadv)
+ changed = 1;
+
err = phy_write(phydev, MII_CTRL1000, adv);
if (err 0)
return err;
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 net-next] net: fec: Ensure clocks are enabled while using mdio bus
2015-06-22 19:52 GMT-07:00 Andrew Lunn and...@lunn.ch:
int mii_id, int regnum) {
struct fec_enet_private *fep = bus-priv;
unsigned long time_left;
+ int ret;
+
+ ret = clk_prepare_enable(fep-clk_ipg);
+ if (ret)
+ return ret;
fep-mii_timeout = 0;
init_completion(fep-mdio_done);
@@ -1779,11 +1785,14 @@ static int fec_enet_mdio_read(struct mii_bus *bus,
int mii_id, int regnum)
if (time_left == 0) {
fep-mii_timeout = 1;
netdev_err(fep-netdev, MDIO read timeout\n);
+ clk_disable_unprepare(fep-clk_ipg);
return -ETIMEDOUT;
}
- /* return value */
- return FEC_MMFR_DATA(readl(fep-hwp + FEC_MII_DATA));
+ ret = FEC_MMFR_DATA(readl(fep-hwp + FEC_MII_DATA));
+ clk_disable_unprepare(fep-clk_ipg);
+
+ return ret;
}
I suggest you use runtime pm to enable/disable clock for performance
consideration. Not every time for mdio bus access needs to
enable/disable clock.
Can you explain that some more. When are you suggesting doing a
runtime enable/disable? Given the current DSA architecture, i would
probably do a runtime enable as soon as i lookup the mdio bus, and
never do a runtime disable. Also, how would you include this runtime
pm into the phy state machine which is going to be polling your mdio
bus around once per second for normal phys?
I believe the sh_eth driver is an in-tree example of a driver doing
runtime PM for its MDIO bus controller implementation.
Florian, as Maintainer of the phy state machine, what do you think
about adding runtime PM to it?
I have no objection to adding runtime PM awareness into the PHY
library, runtime PM should work well here since we are doing host
initiated reads, at least for polled PHYs. For interrupt driven PHYs,
I suppose we could also get something to work, although one needs to
be more careful. One potential issue is that runtime PM does not seem
to have some sort of latency built-in into it, so you do not really
know how long it takes to transition from low-power to functional
state where you can issue a MDIO read/write with success.
You could argue that as long as the sum of the times needed to
wake-up, perform the operation and go back to sleep is below the
polling frequency, you are safe, but a) this does not work for all
device if we ever lower the poll frequency and b) this starts putting
near real-time requirements on doing all of these operations.
I would suspect that unless the clock feeding the MDIO bus controller
feeds over power hungry digital logic, you would get most power
savings from enabling link power management features such as EEE.
Anything else dealing with digital logic might just be noise compared
to doing this. Technically, even between an Ethernet switch and the
CPU port you should be able to do it, provided that the switch
supports it.
My 2 cents.
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
[PATCH net 3/3] net: phy: mdio-bcm-unimac: workaround initial read failures for integrated PHYs
All BCM7xxx integrated Gigabit PHYs have an issue in their MDIO
management controller which will make the initial read or write to them
to fail and return 0x. This is a real issue as the typical first
thing we do is read from MII_PHYSID1 and MII_PHYSID2 from get_phy_id()
to register a driver for these PHYs.
Coupled with the workaround in drivers/net/phy/bcm7xxx.c, this
workaround for the MDIO bus controller consists in scanning the list of
PHYs to do this initial read workaround for as part of the MDIO bus
reset routine which is invoked prior to mdiobus_scan().
Once we have a proper PHY driver/device registered, all workarounds are
located there (e.g: power management suspend/resume calls).
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/phy/mdio-bcm-unimac.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/net/phy/mdio-bcm-unimac.c
b/drivers/net/phy/mdio-bcm-unimac.c
index fc7abc50b4f1..6a52a7f0fa0d 100644
--- a/drivers/net/phy/mdio-bcm-unimac.c
+++ b/drivers/net/phy/mdio-bcm-unimac.c
@@ -120,6 +120,48 @@ static int unimac_mdio_write(struct mii_bus *bus, int
phy_id,
return 0;
}
+/* Workaround for integrated BCM7xxx Gigabit PHYs which have a problem with
+ * their internal MDIO management controller making them fail to successfully
+ * be read from or written to for the first transaction. We insert a dummy
+ * BMSR read here to make sure that phy_get_device() and get_phy_id() can
+ * correctly read the PHY MII_PHYSID1/2 registers and successfully register a
+ * PHY device for this peripheral.
+ *
+ * Once the PHY driver is registered, we can workaround subsequent reads from
+ * there (e.g: during system-wide power management).
+ *
+ * bus-reset is invoked before mdiobus_scan during mdiobus_register and is
+ * therefore the right location to stick that workaround. Since we do not want
+ * to read from non-existing PHYs, we either use bus-phy_mask or do a manual
+ * Device Tree scan to limit the search area.
+ */
+static int unimac_mdio_reset(struct mii_bus *bus)
+{
+ struct device_node *np = bus-dev.of_node;
+ struct device_node *child;
+ u32 read_mask = 0;
+ int addr;
+
+ if (!np) {
+ read_mask = ~bus-phy_mask;
+ } else {
+ for_each_available_child_of_node(np, child) {
+ addr = of_mdio_parse_addr(bus-dev, child);
+ if (addr 0)
+ continue;
+
+ read_mask |= 1 addr;
+ }
+ }
+
+ for (addr = 0; addr PHY_MAX_ADDR; addr++) {
+ if (read_mask 1 addr)
+ mdiobus_read(bus, addr, MII_BMSR);
+ }
+
+ return 0;
+}
+
static int unimac_mdio_probe(struct platform_device *pdev)
{
struct unimac_mdio_priv *priv;
@@ -155,6 +197,7 @@ static int unimac_mdio_probe(struct platform_device *pdev)
bus-parent = pdev-dev;
bus-read = unimac_mdio_read;
bus-write = unimac_mdio_write;
+ bus-reset = unimac_mdio_reset;
snprintf(bus-id, MII_BUS_ID_SIZE, %s, pdev-name);
bus-irq = kcalloc(PHY_MAX_ADDR, sizeof(int), GFP_KERNEL);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 2/3] net: bcmgenet: workaround initial read failures for integrated PHYs
All BCM7xxx integrated Gigabit PHYs have an issue in their MDIO
management controller which will make the initial read or write to them
to fail and return 0x. This is a real issue as the typical first
thing we do is read from MII_PHYSID1 and MII_PHYSID2 from get_phy_id()
to register a driver for these PHYs.
Coupled with the workaround in drivers/net/phy/bcm7xxx.c, this
workaround for the MDIO bus controller consists in scanning the list of
PHYs to do this initial read workaround for as part of the MDIO bus
reset routine which is invoked prior to mdiobus_scan().
Once we have a proper PHY driver/device registered, all workarounds are
located there (e.g: power management suspend/resume calls).
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 1 +
drivers/net/ethernet/broadcom/genet/bcmmii.c | 54 --
2 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index 6f2887a5e0be..6159deab8c98 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -594,6 +594,7 @@ struct bcmgenet_priv {
wait_queue_head_t wq;
struct phy_device *phydev;
struct device_node *phy_dn;
+ struct device_node *mdio_dn;
struct mii_bus *mii_bus;
u16 gphy_rev;
struct clk *clk_eee;
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 6bef04e2f735..adf23d2ac488 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -408,6 +408,52 @@ static int bcmgenet_mii_probe(struct net_device *dev)
return 0;
}
+/* Workaround for integrated BCM7xxx Gigabit PHYs which have a problem with
+ * their internal MDIO management controller making them fail to successfully
+ * be read from or written to for the first transaction. We insert a dummy
+ * BMSR read here to make sure that phy_get_device() and get_phy_id() can
+ * correctly read the PHY MII_PHYSID1/2 registers and successfully register a
+ * PHY device for this peripheral.
+ *
+ * Once the PHY driver is registered, we can workaround subsequent reads from
+ * there (e.g: during system-wide power management).
+ *
+ * bus-reset is invoked before mdiobus_scan during mdiobus_register and is
+ * therefore the right location to stick that workaround. Since we do not want
+ * to read from non-existing PHYs, we either use bus-phy_mask or do a manual
+ * Device Tree scan to limit the search area.
+ */
+static int bcmgenet_mii_bus_reset(struct mii_bus *bus)
+{
+ struct net_device *dev = bus-priv;
+ struct bcmgenet_priv *priv = netdev_priv(dev);
+ struct device_node *np = priv-mdio_dn;
+ struct device_node *child = NULL;
+ u32 read_mask = 0;
+ int addr = 0;
+
+ if (!np) {
+ read_mask = 1 priv-phy_addr;
+ } else {
+ for_each_available_child_of_node(np, child) {
+ addr = of_mdio_parse_addr(dev-dev, child);
+ if (addr 0)
+ continue;
+
+ read_mask |= 1 addr;
+ }
+ }
+
+ for (addr = 0; addr PHY_MAX_ADDR; addr++) {
+ if (read_mask 1 addr) {
+ dev_dbg(dev-dev, Workaround for PHY @ %d\n, addr);
+ mdiobus_read(bus, addr, MII_BMSR);
+ }
+ }
+
+ return 0;
+}
+
static int bcmgenet_mii_alloc(struct bcmgenet_priv *priv)
{
struct mii_bus *bus;
@@ -427,6 +473,7 @@ static int bcmgenet_mii_alloc(struct bcmgenet_priv *priv)
bus-parent = priv-pdev-dev;
bus-read = bcmgenet_mii_read;
bus-write = bcmgenet_mii_write;
+ bus-reset = bcmgenet_mii_bus_reset;
snprintf(bus-id, MII_BUS_ID_SIZE, %s-%d,
priv-pdev-name, priv-pdev-id);
@@ -443,7 +490,6 @@ static int bcmgenet_mii_of_init(struct bcmgenet_priv *priv)
{
struct device_node *dn = priv-pdev-dev.of_node;
struct device *kdev = priv-pdev-dev;
- struct device_node *mdio_dn;
char *compat;
int ret;
@@ -451,14 +497,14 @@ static int bcmgenet_mii_of_init(struct bcmgenet_priv
*priv)
if (!compat)
return -ENOMEM;
- mdio_dn = of_find_compatible_node(dn, NULL, compat);
+ priv-mdio_dn = of_find_compatible_node(dn, NULL, compat);
kfree(compat);
- if (!mdio_dn) {
+ if (!priv-mdio_dn) {
dev_err(kdev, unable to find MDIO bus node\n);
return -ENODEV;
}
- ret = of_mdiobus_register(priv-mii_bus, mdio_dn);
+ ret = of_mdiobus_register(priv-mii_bus, priv-mdio_dn);
if (ret) {
dev_err(kdev, failed to register MDIO bus\n);
return ret;
--
2.1.0
[PATCH net 0/3] net: phy: bcm7xxx initial read/write workaround
Hi David, This patch series fixes occasional BCM7xxx PHY driver binding failure due to a harware bug where the first read or write does not come out of the PHY MDIO management controller. Since we have two different MDIO controllers using this PHY, a similar need to be replicated in GENET and UniMAC MDIO. Thanks! Florian Fainelli (3): net: phy: bcm7xxx: workaround MDIO management controller initial read net: bcmgenet: workaround initial read failures for integrated PHYs net: phy: mdio-bcm-unimac: workaround initial read failures for integrated PHYs drivers/net/ethernet/broadcom/genet/bcmgenet.h | 1 + drivers/net/ethernet/broadcom/genet/bcmmii.c | 54 -- drivers/net/phy/bcm7xxx.c | 7 drivers/net/phy/mdio-bcm-unimac.c | 43 4 files changed, 101 insertions(+), 4 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 1/3] net: phy: bcm7xxx: workaround MDIO management controller initial read
The initial MDIO read or write towards the BCM7xxx integrated PHY may
fail, workaround this by inserting a dummy MII_BMSR read to force the
MDIO management controller to see at least one valid transaction and get
out of stuck state out of reset.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/phy/bcm7xxx.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index 4dea85bfc545..6b701b3ded74 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -246,6 +246,13 @@ static int bcm7xxx_28nm_config_init(struct phy_device
*phydev)
pr_info_once(%s: %s PHY revision: 0x%02x, patch: %d\n,
dev_name(phydev-dev), phydev-drv-name, rev, patch);
+ /* Dummy read to a register to workaround an issue upon reset where the
+* internal inverter may not allow the first MDIO transaction to pass
+* the MDIO management controller and make us return 0x for such
+* reads.
+*/
+ phy_read(phydev, MII_BMSR);
+
switch (rev) {
case 0xb0:
ret = bcm7xxx_28nm_b0_afe_config_init(phydev);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 2/3] net: bcmgenet: workaround initial read failures for integrated PHYs
All BCM7xxx integrated Gigabit PHYs have an issue in their MDIO
management controller which will make the initial read or write to them
to fail and return 0x. This is a real issue as the typical first
thing we do is read from MII_PHYSID1 and MII_PHYSID2 from get_phy_id()
to register a driver for these PHYs.
Coupled with the workaround in drivers/net/phy/bcm7xxx.c, this
workaround for the MDIO bus controller consists in scanning the list of
PHYs to do this initial read workaround for as part of the MDIO bus
reset routine which is invoked prior to mdiobus_scan().
Once we have a proper PHY driver/device registered, all workarounds are
located there (e.g: power management suspend/resume calls).
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 1 +
drivers/net/ethernet/broadcom/genet/bcmmii.c | 54 --
2 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index 6f2887a5e0be..6159deab8c98 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -594,6 +594,7 @@ struct bcmgenet_priv {
wait_queue_head_t wq;
struct phy_device *phydev;
struct device_node *phy_dn;
+ struct device_node *mdio_dn;
struct mii_bus *mii_bus;
u16 gphy_rev;
struct clk *clk_eee;
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 6bef04e2f735..adf23d2ac488 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -408,6 +408,52 @@ static int bcmgenet_mii_probe(struct net_device *dev)
return 0;
}
+/* Workaround for integrated BCM7xxx Gigabit PHYs which have a problem with
+ * their internal MDIO management controller making them fail to successfully
+ * be read from or written to for the first transaction. We insert a dummy
+ * BMSR read here to make sure that phy_get_device() and get_phy_id() can
+ * correctly read the PHY MII_PHYSID1/2 registers and successfully register a
+ * PHY device for this peripheral.
+ *
+ * Once the PHY driver is registered, we can workaround subsequent reads from
+ * there (e.g: during system-wide power management).
+ *
+ * bus-reset is invoked before mdiobus_scan during mdiobus_register and is
+ * therefore the right location to stick that workaround. Since we do not want
+ * to read from non-existing PHYs, we either use bus-phy_mask or do a manual
+ * Device Tree scan to limit the search area.
+ */
+static int bcmgenet_mii_bus_reset(struct mii_bus *bus)
+{
+ struct net_device *dev = bus-priv;
+ struct bcmgenet_priv *priv = netdev_priv(dev);
+ struct device_node *np = priv-mdio_dn;
+ struct device_node *child = NULL;
+ u32 read_mask = 0;
+ int addr = 0;
+
+ if (!np) {
+ read_mask = 1 priv-phy_addr;
+ } else {
+ for_each_available_child_of_node(np, child) {
+ addr = of_mdio_parse_addr(dev-dev, child);
+ if (addr 0)
+ continue;
+
+ read_mask |= 1 addr;
+ }
+ }
+
+ for (addr = 0; addr PHY_MAX_ADDR; addr++) {
+ if (read_mask 1 addr) {
+ dev_dbg(dev-dev, Workaround for PHY @ %d\n, addr);
+ mdiobus_read(bus, addr, MII_BMSR);
+ }
+ }
+
+ return 0;
+}
+
static int bcmgenet_mii_alloc(struct bcmgenet_priv *priv)
{
struct mii_bus *bus;
@@ -427,6 +473,7 @@ static int bcmgenet_mii_alloc(struct bcmgenet_priv *priv)
bus-parent = priv-pdev-dev;
bus-read = bcmgenet_mii_read;
bus-write = bcmgenet_mii_write;
+ bus-reset = bcmgenet_mii_bus_reset;
snprintf(bus-id, MII_BUS_ID_SIZE, %s-%d,
priv-pdev-name, priv-pdev-id);
@@ -443,7 +490,6 @@ static int bcmgenet_mii_of_init(struct bcmgenet_priv *priv)
{
struct device_node *dn = priv-pdev-dev.of_node;
struct device *kdev = priv-pdev-dev;
- struct device_node *mdio_dn;
char *compat;
int ret;
@@ -451,14 +497,14 @@ static int bcmgenet_mii_of_init(struct bcmgenet_priv
*priv)
if (!compat)
return -ENOMEM;
- mdio_dn = of_find_compatible_node(dn, NULL, compat);
+ priv-mdio_dn = of_find_compatible_node(dn, NULL, compat);
kfree(compat);
- if (!mdio_dn) {
+ if (!priv-mdio_dn) {
dev_err(kdev, unable to find MDIO bus node\n);
return -ENODEV;
}
- ret = of_mdiobus_register(priv-mii_bus, mdio_dn);
+ ret = of_mdiobus_register(priv-mii_bus, priv-mdio_dn);
if (ret) {
dev_err(kdev, failed to register MDIO bus\n);
return ret;
--
2.1.0
Re: [PATCH net 0/3] net: phy: bcm7xxx initial read/write workaround
On 26/06/15 10:38, Florian Fainelli wrote: Hi David, This patch series fixes occasional BCM7xxx PHY driver binding failure due to a harware bug where the first read or write does not come out of the PHY MDIO management controller. Since we have two different MDIO controllers using this PHY, a similar need to be replicated in GENET and UniMAC MDIO. Mistankely sent a previous patch as part of this series, the latest submission is correct. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] net/phy: tune get_phy_c45_ids to support more c45 phy
On 26/06/15 02:58, Shengzhou Liu wrote:
As some C45 10G PHYs(e.g. Cortina CS4315/CS4340 PHY) have
zero Devices In package, current driver can't get correct
devices_in_package value by non-zero Devices In package.
so let's probe more with zero Devices In package to support
more C45 PHYs.
This looks better to me now:
Reviewed-by: Florian Fainelli f.faine...@gmail.com
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v3: restructure the loop to probe naturally.
v2: use MDIO_DEVS1 and MDIO_DEVS2 instead of constant '6', '5'
drivers/net/phy/phy_device.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index bdfe51f..3e90037 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -230,7 +230,7 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr,
u32 *phy_id,
for (i = 1;
i num_ids c45_ids-devices_in_package == 0;
i++) {
- reg_addr = MII_ADDR_C45 | i 16 | MDIO_DEVS2;
+retry: reg_addr = MII_ADDR_C45 | i 16 | MDIO_DEVS2;
phy_reg = mdiobus_read(bus, addr, reg_addr);
if (phy_reg 0)
return -EIO;
@@ -242,12 +242,20 @@ static int get_phy_c45_ids(struct mii_bus *bus, int
addr, u32 *phy_id,
return -EIO;
c45_ids-devices_in_package |= (phy_reg 0x);
- /* If mostly Fs, there is no device there,
- * let's get out of here.
- */
if ((c45_ids-devices_in_package 0x1fff) == 0x1fff) {
- *phy_id = 0x;
- return 0;
+ if (i) {
+ /* If mostly Fs, there is no device there,
+ * then let's continue to probe more, as some
+ * 10G PHYs have zero Devices In package,
+ * e.g. Cortina CS4315/CS4340 PHY.
+ */
+ i = 0;
+ goto retry;
+ } else {
+ /* no device there, let's get out of here */
+ *phy_id = 0x;
+ return 0;
+ }
}
}
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] net: bcmgenet: power on MII block for all MII modes
The RGMII block is currently only powered on when using RGMII or
RGMII_NO_ID, which is not correct when using the GENET interface in MII
or Reverse MII modes. We always need to power on the RGMII interface for
this block to properly work, regardless of the MII mode in which we
operate.
Fixes: aa09677cba423 (net: bcmgenet: add MDIO routines)
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
David,
I am targetting net here since this is a bug fix, however, we have few
people using MII or Reverse MII with GENET, such that there is no need to
queue this for -stable unless you want to.
Thanks!
drivers/net/ethernet/broadcom/genet/bcmmii.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index e7651b3c6c57..420949cc55aa 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -299,9 +299,6 @@ int bcmgenet_mii_config(struct net_device *dev, bool init)
phy_name = external RGMII (no delay);
else
phy_name = external RGMII (TX delay);
- reg = bcmgenet_ext_readl(priv, EXT_RGMII_OOB_CTRL);
- reg |= RGMII_MODE_EN | id_mode_dis;
- bcmgenet_ext_writel(priv, reg, EXT_RGMII_OOB_CTRL);
bcmgenet_sys_writel(priv,
PORT_MODE_EXT_GPHY, SYS_PORT_CTRL);
break;
@@ -310,6 +307,15 @@ int bcmgenet_mii_config(struct net_device *dev, bool init)
return -EINVAL;
}
+ /* This is an external PHY (xMII), so we need to enable the RGMII
+* block for the interface to work
+*/
+ if (priv-ext_phy) {
+ reg = bcmgenet_ext_readl(priv, EXT_RGMII_OOB_CTRL);
+ reg |= RGMII_MODE_EN | id_mode_dis;
+ bcmgenet_ext_writel(priv, reg, EXT_RGMII_OOB_CTRL);
+ }
+
if (init)
dev_info(kdev, configuring instance for %s\n, phy_name);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 0/3] net: phy: bcm7xxx initial read/write workaround
Hi David, This patch series fixes occasional BCM7xxx PHY driver binding failure due to a harware bug where the first read or write does not come out of the PHY MDIO management controller. Since we have two different MDIO controllers using this PHY, a similar need to be replicated in GENET and UniMAC MDIO. Thanks! Florian Fainelli (3): net: phy: bcm7xxx: workaround MDIO management controller initial read net: bcmgenet: workaround initial read failures for integrated PHYs net: phy: mdio-bcm-unimac: workaround initial read failures for integrated PHYs drivers/net/ethernet/broadcom/genet/bcmgenet.h | 1 + drivers/net/ethernet/broadcom/genet/bcmmii.c | 54 -- drivers/net/phy/bcm7xxx.c | 7 drivers/net/phy/mdio-bcm-unimac.c | 43 4 files changed, 101 insertions(+), 4 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 1/3] net: phy: bcm7xxx: workaround MDIO management controller initial read
The initial MDIO read or write towards the BCM7xxx integrated PHY may
fail, workaround this by inserting a dummy MII_BMSR read to force the
MDIO management controller to see at least one valid transaction and get
out of stuck state out of reset.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/phy/bcm7xxx.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index 4dea85bfc545..6b701b3ded74 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -246,6 +246,13 @@ static int bcm7xxx_28nm_config_init(struct phy_device
*phydev)
pr_info_once(%s: %s PHY revision: 0x%02x, patch: %d\n,
dev_name(phydev-dev), phydev-drv-name, rev, patch);
+ /* Dummy read to a register to workaround an issue upon reset where the
+* internal inverter may not allow the first MDIO transaction to pass
+* the MDIO management controller and make us return 0x for such
+* reads.
+*/
+ phy_read(phydev, MII_BMSR);
+
switch (rev) {
case 0xb0:
ret = bcm7xxx_28nm_b0_afe_config_init(phydev);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] dsa: fix promiscuity leak on slave dev open error
On 25/06/15 06:50, gil...@ezchip.com wrote: From: Gilad Ben-Yossef gi...@benyossef.com DSA master netdev promiscuity counter was not being properly decremented on slave device open error path. Signed-off-by: Gilad Ben-Yossef gi...@benyossef.com CC: Gilad Ben-Yossef gil...@ezchip.com CC: David S. Miller da...@davemloft.net CC: Florian Fainelli f.faine...@gmail.com CC: Guenter Roeck li...@roeck-us.net CC: Andrew Lunn and...@lunn.ch CC: Scott Feldman sfel...@gmail.com Acked-by: Florian Fainelli f.faine...@gmail.com --- net/dsa/slave.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/dsa/slave.c b/net/dsa/slave.c index 04ffad3..0917123 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -112,7 +112,7 @@ static int dsa_slave_open(struct net_device *dev) clear_promisc: if (dev-flags IFF_PROMISC) - dev_set_promiscuity(master, 0); + dev_set_promiscuity(master, -1); clear_allmulti: if (dev-flags IFF_ALLMULTI) dev_set_allmulti(master, -1); -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 net-next] net: fec: Ensure clocks are enabled while using mdio bus
Le 06/20/15 09:15, Andrew Lunn a écrit : When a switch is attached to the mdio bus, the mdio bus can be used while the interface is not open. If the IPG clock are not enabled, MDIO reads/writes will simply time out. So enable the clock before starting a transaction, and disable it afterwards. The CCF performs reference counting so the clock will only be disabled if there are no other users. Signed-off-by: Andrew Lunn and...@lunn.ch --- v2: Only enable/disable the IPG clock. drivers/net/ethernet/freescale/fec_main.c | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index bf4cf3fbb5f2..2b8a043a573c 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -65,6 +65,7 @@ static void set_multicast_list(struct net_device *ndev); static void fec_enet_itr_coal_init(struct net_device *ndev); +static int fec_enet_clk_enable(struct net_device *ndev, bool enable); You do not seem to be using this, unrelated change? -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in
Re: [PATCH net-next 2/2] net: phy: mdio-bcm-unimac: handle broken turn-around for specific PHYs
On 10/06/15 12:14, Florian Fainelli wrote: Some Ethernet PHYs/switches such as Broadcom's BCM53125 have a hardware bug which makes them not release the MDIO line during turn-around time. This gets flagged by the UniMAC MDIO controller as a read failure, and we fail the read transaction. Check the MDIO bus phy_ignore_ta_mask bitmask for the PHY we are reading from and if it is listed in this bitmask, ignore the read failure and proceed with returning the data we read out of the controller. Scratch that version, it contains an unnecessary include and does not have the same comment as the GENET version, let me resubmit that. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- drivers/net/phy/mdio-bcm-unimac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/mdio-bcm-unimac.c b/drivers/net/phy/mdio-bcm-unimac.c index 414fdf1f343f..2237d5554e02 100644 --- a/drivers/net/phy/mdio-bcm-unimac.c +++ b/drivers/net/phy/mdio-bcm-unimac.c @@ -16,6 +16,7 @@ #include linux/module.h #include linux/io.h #include linux/delay.h +#include linux/brcmphy.h #include linux/of.h #include linux/of_platform.h @@ -81,7 +82,7 @@ static int unimac_mdio_read(struct mii_bus *bus, int phy_id, int reg) return -ETIMEDOUT; cmd = __raw_readl(priv-base + MDIO_CMD); - if (cmd MDIO_READ_FAIL) + if (!(bus-phy_ignore_ta_mask 1 phy_id) (cmd MDIO_READ_FAIL)) return -EIO; return cmd 0x; -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 2/2] net: phy: mdio-bcm-unimac: handle broken turn-around for specific PHYs
Some Ethernet PHYs/switches such as Broadcom's BCM53125 have a hardware bug which makes them not release the MDIO line during turn-around time. This gets flagged by the UniMAC MDIO controller as a read failure, and we fail the read transaction. Check the MDIO bus phy_ignore_ta_mask bitmask for the PHY we are reading from and if it is listed in this bitmask, ignore the read failure and proceed with returning the data we read out of the controller. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- drivers/net/phy/mdio-bcm-unimac.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/mdio-bcm-unimac.c b/drivers/net/phy/mdio-bcm-unimac.c index 414fdf1f343f..fc7abc50b4f1 100644 --- a/drivers/net/phy/mdio-bcm-unimac.c +++ b/drivers/net/phy/mdio-bcm-unimac.c @@ -81,7 +81,13 @@ static int unimac_mdio_read(struct mii_bus *bus, int phy_id, int reg) return -ETIMEDOUT; cmd = __raw_readl(priv-base + MDIO_CMD); - if (cmd MDIO_READ_FAIL) + + /* Some broken devices are known not to release the line during +* turn-around, e.g: Broadcom BCM53125 external switches, so check for +* that condition here and ignore the MDIO controller read failure +* indication. +*/ + if (!(bus-phy_ignore_ta_mask 1 phy_id) (cmd MDIO_READ_FAIL)) return -EIO; return cmd 0x; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 0/2] net: broadcom MDIO support for broken turn-around
Hi David, These two patches update the GENET and UniMAC MDIO controllers to deal with PHYs that are known to have a broken turn-around bug (e.g: BCM53125 and others) This utilizes the infrastructure that code recently added to do that in 'net-next'. Note that the changes look nearly identical and I will try to address the MDIO code duplication between GENET and UniMAC in a future patch series. Thanks! Changes in v2: - remove brcmphy.h include in mdio-bcm-unimac.c - use the same comment as with GENET's MDIO read function Florian Fainelli (2): net: bcmgenet: handle broken turn-around for specific PHYs net: phy: mdio-bcm-unimac: handle broken turn-around for specific PHYs drivers/net/ethernet/broadcom/genet/bcmmii.c | 7 ++- drivers/net/phy/mdio-bcm-unimac.c| 8 +++- 2 files changed, 13 insertions(+), 2 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/2] net: bcmgenet: handle broken turn-around for specific PHYs
Some Ethernet PHYs/switches such as Broadcom's BCM53125 have a hardware bug which makes them not release the MDIO line during turn-around time. This gets flagged by the GENET MDIO controller as a read failure, and we fail the read transaction. Check the MDIO bus phy_ignore_ta_mask bitmask for the PHY we are reading from and if it is listed in this bitmask, ignore the read failure and proceed with returning the data we read out of the controller. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- drivers/net/ethernet/broadcom/genet/bcmmii.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c index 420949cc55aa..6bef04e2f735 100644 --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c @@ -47,7 +47,12 @@ static int bcmgenet_mii_read(struct mii_bus *bus, int phy_id, int location) HZ / 100); ret = bcmgenet_umac_readl(priv, UMAC_MDIO_CMD); - if (ret MDIO_READ_FAIL) + /* Some broken devices are known not to release the line during +* turn-around, e.g: Broadcom BCM53125 external switches, so check for +* that condition here and ignore the MDIO controller read failure +* indication. +*/ + if (!(bus-phy_ignore_ta_mask 1 phy_id) (ret MDIO_READ_FAIL)) return -EIO; return ret 0x; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 0/2] net: broadcom MDIO support for broken turn-around
Hi David, These two patches update the GENET and UniMAC MDIO controllers to deal with PHYs that are known to have a broken turn-around bug (e.g: BCM53125 and others) This utilizes the infrastructure that code recently added to do that in 'net-next'. Note that the changes look nearly identical and I will try to address the MDIO code duplication between GENET and UniMAC in a future patch series. Thanks! Florian Fainelli (2): net: bcmgenet: handle broken turn-around for specific PHYs net: phy: mdio-bcm-unimac: handle broken turn-around for specific PHYs drivers/net/ethernet/broadcom/genet/bcmmii.c | 7 ++- drivers/net/phy/mdio-bcm-unimac.c| 3 ++- 2 files changed, 8 insertions(+), 2 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 1/2] net: bcmgenet: handle broken turn-around for specific PHYs
Some Ethernet PHYs/switches such as Broadcom's BCM53125 have a hardware bug which makes them not release the MDIO line during turn-around time. This gets flagged by the GENET MDIO controller as a read failure, and we fail the read transaction. Check the MDIO bus phy_ignore_ta_mask bitmask for the PHY we are reading from and if it is listed in this bitmask, ignore the read failure and proceed with returning the data we read out of the controller. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- drivers/net/ethernet/broadcom/genet/bcmmii.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c index 420949cc55aa..6bef04e2f735 100644 --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c @@ -47,7 +47,12 @@ static int bcmgenet_mii_read(struct mii_bus *bus, int phy_id, int location) HZ / 100); ret = bcmgenet_umac_readl(priv, UMAC_MDIO_CMD); - if (ret MDIO_READ_FAIL) + /* Some broken devices are known not to release the line during +* turn-around, e.g: Broadcom BCM53125 external switches, so check for +* that condition here and ignore the MDIO controller read failure +* indication. +*/ + if (!(bus-phy_ignore_ta_mask 1 phy_id) (ret MDIO_READ_FAIL)) return -EIO; return ret 0x; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 2/2] net: phy: mdio-bcm-unimac: handle broken turn-around for specific PHYs
Some Ethernet PHYs/switches such as Broadcom's BCM53125 have a hardware bug which makes them not release the MDIO line during turn-around time. This gets flagged by the UniMAC MDIO controller as a read failure, and we fail the read transaction. Check the MDIO bus phy_ignore_ta_mask bitmask for the PHY we are reading from and if it is listed in this bitmask, ignore the read failure and proceed with returning the data we read out of the controller. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- drivers/net/phy/mdio-bcm-unimac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/mdio-bcm-unimac.c b/drivers/net/phy/mdio-bcm-unimac.c index 414fdf1f343f..2237d5554e02 100644 --- a/drivers/net/phy/mdio-bcm-unimac.c +++ b/drivers/net/phy/mdio-bcm-unimac.c @@ -16,6 +16,7 @@ #include linux/module.h #include linux/io.h #include linux/delay.h +#include linux/brcmphy.h #include linux/of.h #include linux/of_platform.h @@ -81,7 +82,7 @@ static int unimac_mdio_read(struct mii_bus *bus, int phy_id, int reg) return -ETIMEDOUT; cmd = __raw_readl(priv-base + MDIO_CMD); - if (cmd MDIO_READ_FAIL) + if (!(bus-phy_ignore_ta_mask 1 phy_id) (cmd MDIO_READ_FAIL)) return -EIO; return cmd 0x; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Weird DHCP related problems with net-next
On 10/06/15 14:44, Scott Feldman wrote: On Tue, Jun 9, 2015 at 5:12 PM, Florian Fainelli f.faine...@gmail.com wrote: I see the problem now, DSA does not implement a port_obj_add callback, so when net/ipv4/fib_trie.c::switchdev_fib_ipv4_add() gets to call switchdev_port_obj_add, we return -EOPNOTSUPP, and take the error path in fib_table_insert thus not inserting the route for this interface. Yup, that's the problem. Now when I restart the DHCP client, we end-up inserting the default route which is correct, still figuring out what is different here, probably the deletion of the routes by the DHCP client script first is the different condition. After the first failure, ipv4.fib_offload_disabled is set, so the next time switchdev_fib_ipv4_add() just returns 0 and the route is installed. That explains the one-off behavior. At any rate, since switchdev_fib_ipv4_add() returns something that make us take an error path in the fib_trie, something like this seems to fix it for me but I am not well versed enough into the IPv4 routing code to be 100% confident this is the right fix. Also, there are other callers of switchdev_port_obj_add() but a quick look seems to make them safe as they are only called for offloading capable hardware. Your fix looks good to me. The other users of switchdev_port_obj_add() want to return -EOPNOTSUPP to user, so it's just this one case for IPv4 fib insert/del where we'll want to treat no support silently. Are you going to resend as patch for net-next, or should I? I would prefer if you submitted it since you explained how things are working and now everything makes sense. I will be happy to test it and provide the magic tags ;) -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: fec: Ensure clocks are enabled while using mdio bus
Le 06/14/15 07:41, Andrew Lunn a écrit : On Sun, Jun 14, 2015 at 08:07:12AM +, Duan Andy wrote: From: Andrew Lunn and...@lunn.ch Sent: Friday, June 12, 2015 11:39 PM To: David Miller Cc: Duan Fugang-B38611; Cory Tusar; netdev; Andrew Lunn Subject: [PATCH] net: fec: Ensure clocks are enabled while using mdio bus When a switch is attached to the mdio bus, the mdio bus can be used while the interface is not open. If the clocks are not enabled, MDIO reads/writes will simply time out. So enable the clocks before starting a transaction, and disable them afterwards. The CCF performs reference counting so the clocks will only be disabled if there are no other users. Signed-off-by: Andrew Lunn and...@lunn.ch --- NAK the patch. i.MX series MDIO bus is a part of ENET controller. If the eth interface is not open, all clocks including MDIO bus clock are not enabled for power saving. Which is fine, but is an assumption you can only make when your ENET controller is connected to an Ethernet PHY, with a switch, things get a little different see below. Where do you see a power saving regression in this code? It is not as if i just unconditionally turn the clocks on. As the comment says, at the start of an MDIO transaction, the clocks are enabled. At the end of a transaction, they are disabled again. If you don't have a switch connected, there will be no transactions, hence no change to power savings. In general, if you want to use mdio bus net interface must be running status. This is not true for a number of Ethernet devices. All those currently used with DSA allow MDIO transactions at any time. Right, the typical sequence looks like this: - ethernet device is probed and registered first, for power savings purposes, the probe function might turn off clocks since we do not know whether the interface will be used at all, so until ndo_open is called, such clocks can be disabled - DSA is probed second, and probes the switches using MDIO bus accesses, and if a switch is found, will configure it via MDIO bus reads/writes, by then, the network interface is guaranteed to be down - last, you could disable the parent network device, but still issue MDIO reads/writes towards the switch to collect statistics, make it run in an unmanaged mode with the CPU interface down/powered off Since clocks are reference counted, I really do not see much problem with Andrew's approach here. If you are running without a switch and just a PHY, you will get an occasional clock reference count 1 during MDIO reads/writes, and past your ndo_close() if the clock reference count is 1, aka still turned on, then that means you are not using the PHY library properly and you have dangling MDIO accesses. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DSA: Exposing CPU port [Was: Re: [PATCH 3/3] net: dsa: Allow configuration of CPU DSA port speeds/duplex]
2015-06-17 11:09 GMT-07:00 Vivien Didelot vivien.dide...@savoirfairelinux.com: Hi Andrew, All, On 12/06/15 10:18, Andrew Lunn wrote: By default, DSA and CPU ports are configured to the maximum speed the switch supports. However there can be use cases where the peer device port is slower. Allow a fixed-link property to be used with the DSA and CPU port in the device tree, and use this information to configure the port. Would it be a good idea for DSA to expose the cpu port to userspace as well? That way, it'd be possible to use ethtool to set the port speed and duplex mode, or dump registers (this would have saved me quite some time in dev). My problem with that approach would be that we would expose a cpu net_device in a way that it is not usable beyond statistics and control knobs. In terms of data-path, you would not really want to have it usable (sending data from the CPU to other ports, that's already what other net_devices do), as it would be a duplicate interface with respect to how the master net_device in DSA (aka unmodified Ethernet driver) works. Having e.g: eth0 send DSA-tagged packets today is already very confusing to users (they do not necessarily understand why this interface does or how it works), so having a cpu interface would cause more trouble here. Also, in my RFC for 802.1Q support [1], I assume the CPU port to be a tagged member of each VLAN. But someone may want to add a VLAN with swp3 and swp4 only, and another VLAN with swp0, swp1 and the CPU port. Am I correct? This is currently not possible, but with an exposed cpu interface, the user could explicitly add the CPU port to a VLAN. If we do put, say swp0 and swp1 in VLAN1, and CPU port is not in this VLAN1, we cannot learn any traffic from it, this might be an acceptable use-case, but I am not sure if there is much we get from not adding the CPU to this VLAN membership, am I missing something? -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: macb napi strange behavior
2015-06-17 12:00 GMT-07:00 Nicolae Rosia nicolae.ro...@gmail.com: Hi, On Wed, Jun 17, 2015 at 9:54 PM, Jaeden Amero jaeden.am...@ni.com wrote: On 06/17/2015 11:09 AM, Nicolae Rosia wrote: The times we've seen tons of interrupts on Ethernet with interrupts routed through the PL was when the FPGA was unprogrammed (or in the process of being reprogrammed), or was configured with the interrupt line tied to asserted. In the latter case, Linux would eventually stop handling any more interrupts for that port due to the interrupt storm. This isn't the case. The FPGA is programmed, and indeed I'm using the second MAC routed through PL to SFP. The interesting thing is that I'm seeing the exact behavior on the other side (another Zynq7 board), with eth0 having lots of interrupts. It seems that the interface receiving packets doesn't have a high IRQ activity in contrast to the one sending packets. Typically, NAPI is used at the receive side of the Ethernet NIC/driver to lower the hard/soft interrupt context switch, although there is nothing that prevent you to implement a similar scheme for the transmit side. Usually, for transmit you will be submitting one packet for transmission and get a completion interrupt, so without interrupt coalescing (software or hardware) you can end-up with 1 interrupt per packet transmitted. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] switchdev: fix handling for drivers not supporting IPv4 fib add/del ops
On 10/06/15 17:04, sfel...@gmail.com wrote: From: Scott Feldman sfel...@gmail.com If CONFIG_NET_SWITCHDEV is enabled, but port driver does not implement support for IPv4 FIB add/del ops, don't fail route add/del offload operations. Route adds will not be marked as OFFLOAD. Routes will be installed in the kernel FIB, as usual. This was report/fixed by Florian when testing DSA driver with net-next on devices with L2 offload support but no L3 offload support. What he reported was an initial route installed from DHCP client would fail (route not installed to kernel FIB). This was triggering the setting of ipv4.fib_offload_disabled, which would disable route offloading after the first failure. So subsequent attempts to install the route would succeed. There is follow-on work/discussion to address the handling of route install failures, but for now, let's differentiate between no support and failed support. Reported-by: Florian Fainelli f.faine...@gmail.com Signed-off-by: Scott Feldman sfel...@gmail.com Signed-off-by: Florian Fainelli f.faine...@gmail.com --- net/switchdev/switchdev.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c index 99bced4..28637e9 100644 --- a/net/switchdev/switchdev.c +++ b/net/switchdev/switchdev.c @@ -853,7 +853,7 @@ int switchdev_fib_ipv4_add(u32 dst, int dst_len, struct fib_info *fi, if (!err) fi-fib_flags |= RTNH_F_OFFLOAD; - return err; + return err == -EOPNOTSUPP ? 0 : err; } EXPORT_SYMBOL_GPL(switchdev_fib_ipv4_add); @@ -898,7 +898,7 @@ int switchdev_fib_ipv4_del(u32 dst, int dst_len, struct fib_info *fi, if (!err) fi-fib_flags = ~RTNH_F_OFFLOAD; - return err; + return err == -EOPNOTSUPP ? 0 : err; } EXPORT_SYMBOL_GPL(switchdev_fib_ipv4_del); -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 0/5] net: phy: broadcom: define pseudo-PHY address
Hi David, This patch series converts existing in-tree users of the Broadcom pseudo-PHY address (30) used to configure MDIO-connected switches to share a constant in a shared header files. Thanks! Florian Fainelli (5): net: phy: broadcom: include phy.h for brcmphy.h net: phy: broadcom: define Broadcom pseudo-PHY address in brcmphy.h b44: Utilize BRCM_PSEUDO_PHY_ADDR bgmac: Utilize BRCM_PSEUDO_PHY_ADDR net: dsa: bcm_sf2: Utilize BRCM_PSEUDO_PHY_ADDR drivers/net/dsa/bcm_sf2.c | 7 --- drivers/net/ethernet/broadcom/b44.h | 8 ++-- drivers/net/ethernet/broadcom/bgmac.h | 3 ++- include/linux/brcmphy.h | 7 +++ 4 files changed, 19 insertions(+), 6 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 2/5] net: phy: broadcom: define Broadcom pseudo-PHY address in brcmphy.h
Define the pseudo-PHY address (30) which is used by all Broadcom Ethernet switches in a shared header file. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- include/linux/brcmphy.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h index abb6106f839d..697ca7795bd9 100644 --- a/include/linux/brcmphy.h +++ b/include/linux/brcmphy.h @@ -3,6 +3,11 @@ #include linux/phy.h +/* All Broadcom Ethernet switches have a pseudo-PHY at address 30 which is used + * to configure the switch internal registers via MDIO accesses. + */ +#define BRCM_PSEUDO_PHY_ADDR 30 + #define PHY_ID_BCM506100x0143bd60 #define PHY_ID_BCM50610M 0x0143bd70 #define PHY_ID_BCM5241 0x0143bc30 -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/5] net: phy: broadcom: include phy.h for brcmphy.h
We utilize inline functions from the PHY library, make sure that we do include phy.h in brcmphy.h in order for the code including brcmphy.h not to have to resolve this inclusion dependency. Fixes: 705314797b8b (net: phy: broadcom: move shadow 0x1C register accessors to brcmphy.h) Signed-off-by: Florian Fainelli f.faine...@gmail.com --- include/linux/brcmphy.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h index 656da2a12ffe..abb6106f839d 100644 --- a/include/linux/brcmphy.h +++ b/include/linux/brcmphy.h @@ -1,6 +1,8 @@ #ifndef _LINUX_BRCMPHY_H #define _LINUX_BRCMPHY_H +#include linux/phy.h + #define PHY_ID_BCM506100x0143bd60 #define PHY_ID_BCM50610M 0x0143bd70 #define PHY_ID_BCM5241 0x0143bc30 -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 4/5] bgmac: Utilize BRCM_PSEUDO_PHY_ADDR
What BGMAC defines as BGMAC_PHY_NOREGS is in fact the Broadcom Ethernet switches' pseudo-PHY address (30), utilize the newly introduced constant from brcmphy.h Signed-off-by: Florian Fainelli f.faine...@gmail.com --- drivers/net/ethernet/broadcom/bgmac.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h index db27febbb215..4fbb093e0d84 100644 --- a/drivers/net/ethernet/broadcom/bgmac.h +++ b/drivers/net/ethernet/broadcom/bgmac.h @@ -13,6 +13,7 @@ dev_dbg((bgmac)-core-dev, fmt, ##__VA_ARGS__) #include linux/bcma/bcma.h +#include linux/brcmphy.h #include linux/netdevice.h #define BGMAC_DEV_CTL 0x000 @@ -349,7 +350,7 @@ #define BGMAC_DESC_CTL0_SOF0x8000 /* Start of frame */ #define BGMAC_DESC_CTL1_LEN0x1FFF -#define BGMAC_PHY_NOREGS 0x1E +#define BGMAC_PHY_NOREGS BRCM_PSEUDO_PHY_ADDR #define BGMAC_PHY_MASK 0x1F #define BGMAC_MAX_TX_RINGS 4 -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 3/5] b44: Utilize BRCM_PSEUDO_PHY_ADDR
What B44 has been locally using as B44_PHY_ADDR_NO_LOCAL_PHY is in fact
the Broadcom Ethernet switches pseudo-PHY address (30). Update the
header to use the newly introduced constant and update comments so they
are within 80 columns and consistent.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/b44.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/b44.h
b/drivers/net/ethernet/broadcom/b44.h
index 3e9c3fc7591b..65d88d7c5581 100644
--- a/drivers/net/ethernet/broadcom/b44.h
+++ b/drivers/net/ethernet/broadcom/b44.h
@@ -1,6 +1,8 @@
#ifndef _B44_H
#define _B44_H
+#include linux/brcmphy.h
+
/* Register layout. (These correspond to struct _bcmenettregs in bcm4400.) */
#defineB44_DEVCTRL 0xUL /* Device Control */
#define DEVCTRL_MPM 0x0040 /* Magic Packet PME Enable (B0 only)
*/
@@ -281,8 +283,10 @@ struct ring_info {
};
#define B44_MCAST_TABLE_SIZE 32
-#define B44_PHY_ADDR_NO_LOCAL_PHY 30 /* no local phy regs */
-#define B44_PHY_ADDR_NO_PHY31 /* no phy present at all */
+/* no local phy regs, e.g: Broadcom switches pseudo-PHY */
+#define B44_PHY_ADDR_NO_LOCAL_PHY BRCM_PSEUDO_PHY_ADDR
+/* no phy present at all */
+#define B44_PHY_ADDR_NO_PHY31
#define B44_MDC_RATIO 500
#defineB44_STAT_REG_DECLARE\
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 5/5] net: dsa: bcm_sf2: Utilize BRCM_PSEUDO_PHY_ADDR
Utilize the newly introduced BRCM_PSEUDO_PHY_ADDR constant from
brcmphy.h instead of open-coding the Broadcom Ethernet switches
pseudo-PHY address (30).
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/dsa/bcm_sf2.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 103fde3da476..972982f8bea7 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -24,6 +24,7 @@
#include net/dsa.h
#include linux/ethtool.h
#include linux/if_bridge.h
+#include linux/brcmphy.h
#include bcm_sf2.h
#include bcm_sf2_regs.h
@@ -697,7 +698,7 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds)
/* Include the pseudo-PHY address and the broadcast PHY address to
* divert reads towards our workaround
*/
- ds-phys_mii_mask |= ((1 30) | (1 0));
+ ds-phys_mii_mask |= ((1 BRCM_PSEUDO_PHY_ADDR) | (1 0));
rev = reg_readl(priv, REG_SWITCH_REVISION);
priv-hw_params.top_rev = (rev SWITCH_TOP_REV_SHIFT)
@@ -782,7 +783,7 @@ static int bcm_sf2_sw_phy_read(struct dsa_switch *ds, int
addr, int regnum)
*/
switch (addr) {
case 0:
- case 30:
+ case BRCM_PSEUDO_PHY_ADDR:
return bcm_sf2_sw_indir_rw(ds, 1, addr, regnum, 0);
default:
return 0x;
@@ -797,7 +798,7 @@ static int bcm_sf2_sw_phy_write(struct dsa_switch *ds, int
addr, int regnum,
*/
switch (addr) {
case 0:
- case 30:
+ case BRCM_PSEUDO_PHY_ADDR:
bcm_sf2_sw_indir_rw(ds, 0, addr, regnum, val);
break;
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] net: dsa: Allow configuration of CPU DSA port speeds/duplex
On 12/06/15 11:29, Guenter Roeck wrote:
[snip]
static int dsa_switch_setup_one(struct dsa_switch *ds, struct
device *parent)
{
struct dsa_switch_driver *drv = ds-drv;
@@ -204,6 +234,7 @@ static int dsa_switch_setup_one(struct dsa_switch
*ds, struct device *parent)
}
dst-cpu_switch = index;
dst-cpu_port = i;
+ds-cpu_port_mask |= 1 i;
Same question as Guenter here, I assume this is because you plan on
having multiple CPU ports connected to the switch and this makes it
easier to deal with, is that right?
If so, should that be done in a separate patch set ?
I think it would be clearer that way, yes.
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] net: dsa: Allow configuration of CPU DSA port speeds/duplex
On 12/06/15 10:18, Andrew Lunn wrote:
By default, DSA and CPU ports are configured to the maximum speed the
switch supports. However there can be use cases where the peer device
port is slower. Allow a fixed-link property to be used with the DSA
and CPU port in the device tree, and use this information to configure
the port.
Signed-off-by: Andrew Lunn and...@lunn.ch
---
include/net/dsa.h | 1 +
net/dsa/dsa.c | 39 +++
2 files changed, 40 insertions(+)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index fbca63ba8f73..24572f99224c 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -160,6 +160,7 @@ struct dsa_switch {
* Slave mii_bus and devices for the individual ports.
*/
u32 dsa_port_mask;
+ u32 cpu_port_mask;
u32 phys_port_mask;
u32 phys_mii_mask;
struct mii_bus *slave_mii_bus;
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 392e29a0227d..f9c8f4e7ebce 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -176,6 +176,36 @@ __ATTRIBUTE_GROUPS(dsa_hwmon);
#endif /* CONFIG_NET_DSA_HWMON */
/* basic switch operations
**/
+static int dsa_cpu_dsa_setup(struct dsa_switch *ds, struct net_device
*master)
+{
+ struct dsa_chip_data *cd = ds-pd;
+ struct device_node *port_dn;
+ struct phy_device *phydev;
+ int ret, port;
+
+ for (port = 0; port DSA_MAX_PORTS; port++) {
+ if (!((ds-cpu_port_mask | ds-dsa_port_mask) (1 port)))
+ continue;
+
+ port_dn = cd-port_dn[port];
+ if (of_phy_is_fixed_link(port_dn)) {
+ ret = of_phy_register_fixed_link(port_dn);
+ if (ret) {
+ netdev_err(master,
+failed to register fixed PHY\n);
+ return ret;
+ }
+ phydev = of_phy_find_device(port_dn);
+ phydev-is_pseudo_fixed_link = true;
I suppose this could be automatically set by the Generic PHY driver once
we bind it to the fixed MDIO bus implementation instead of having driver
have to do this, what do you think?
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] net: dsa: Allow configuration of CPU DSA port speeds/duplex
On 12/06/15 10:18, Andrew Lunn wrote:
By default, DSA and CPU ports are configured to the maximum speed the
switch supports. However there can be use cases where the peer device
port is slower. Allow a fixed-link property to be used with the DSA
and CPU port in the device tree, and use this information to configure
the port.
Humm, I suppose this means that we might end-up with two fixed PHY
devices, one for the Ethernet MAC, and another one for the switch? That
might duplicate the same information, though I cannot think of a better
solution than using phandles to resolve that.
Signed-off-by: Andrew Lunn and...@lunn.ch
---
include/net/dsa.h | 1 +
net/dsa/dsa.c | 39 +++
2 files changed, 40 insertions(+)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index fbca63ba8f73..24572f99224c 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -160,6 +160,7 @@ struct dsa_switch {
* Slave mii_bus and devices for the individual ports.
*/
u32 dsa_port_mask;
+ u32 cpu_port_mask;
u32 phys_port_mask;
u32 phys_mii_mask;
struct mii_bus *slave_mii_bus;
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 392e29a0227d..f9c8f4e7ebce 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -176,6 +176,36 @@ __ATTRIBUTE_GROUPS(dsa_hwmon);
#endif /* CONFIG_NET_DSA_HWMON */
/* basic switch operations
**/
+static int dsa_cpu_dsa_setup(struct dsa_switch *ds, struct net_device
*master)
+{
+ struct dsa_chip_data *cd = ds-pd;
+ struct device_node *port_dn;
+ struct phy_device *phydev;
+ int ret, port;
+
+ for (port = 0; port DSA_MAX_PORTS; port++) {
+ if (!((ds-cpu_port_mask | ds-dsa_port_mask) (1 port)))
+ continue;
+
+ port_dn = cd-port_dn[port];
+ if (of_phy_is_fixed_link(port_dn)) {
+ ret = of_phy_register_fixed_link(port_dn);
+ if (ret) {
+ netdev_err(master,
+failed to register fixed PHY\n);
+ return ret;
+ }
+ phydev = of_phy_find_device(port_dn);
+ phydev-is_pseudo_fixed_link = true;
+ genphy_config_init(phydev);
+ genphy_read_status(phydev);
I was curious as to why you were doing this at first, but I guess this
is because the PHY state machine is not started for this fixed PHY that
you just created, right?
+ if (ds-drv-adjust_link)
+ ds-drv-adjust_link(ds, port, phydev);
+ }
+ }
+ return 0;
+}
+
static int dsa_switch_setup_one(struct dsa_switch *ds, struct device *parent)
{
struct dsa_switch_driver *drv = ds-drv;
@@ -204,6 +234,7 @@ static int dsa_switch_setup_one(struct dsa_switch *ds,
struct device *parent)
}
dst-cpu_switch = index;
dst-cpu_port = i;
+ ds-cpu_port_mask |= 1 i;
Same question as Guenter here, I assume this is because you plan on
having multiple CPU ports connected to the switch and this makes it
easier to deal with, is that right?
} else if (!strcmp(name, dsa)) {
ds-dsa_port_mask |= 1 i;
} else {
@@ -297,6 +328,14 @@ static int dsa_switch_setup_one(struct dsa_switch *ds,
struct device *parent)
}
}
+ /* Perform configuration of the CPU and DSA ports */
+ ret = dsa_cpu_dsa_setup(ds, dst-master_netdev);
+ if (ret 0) {
+ netdev_err(dst-master_netdev, [%d] : can't configure CPU and
DSA ports\n,
+index);
+ ret = 0;
+ }
+
#ifdef CONFIG_NET_DSA_HWMON
/* If the switch provides a temperature sensor,
* register with hardware monitoring subsystem.
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] NET: Add ezchip ethernet driver
Le 06/13/15 23:26, Noam Camus a écrit :
From: Noam Camus no...@ezchip.com
Simple LAN device for debug or management purposes.
Device supports interrupts for RX and TX(completion).
Device does not have DMA ability.
Signed-off-by: Noam Camus no...@ezchip.com
Signed-off-by: Tal Zilcer t...@ezchip.com
Acked-by: Alexey Brodkin abrod...@synopsys.com
---
+ /* copy last bytes (if any) */
+ if (last) {
+ u32 buf = nps_enet_reg_get(priv, NPS_ENET_REG_RX_BUF);
+
+ memcpy(reg, buf, last);
memcpy_fromio() for this entire function?
+ }
+}
+
+static void nps_enet_rx_handler(struct net_device *ndev)
+{
+ struct nps_enet_priv *priv = netdev_priv(ndev);
+ struct sk_buff *skb = priv-irq_data.skb;
+ struct nps_enet_rx_ctl rx_ctrl;
+ u32 frame_len;
+
+ rx_ctrl.value = priv-irq_data.rx_ctrl.value;
+ frame_len = rx_ctrl.nr;
+ /* Check if we got RX */
+ if (!rx_ctrl.cr)
+ return;
+
+ ndev-stats.rx_packets++;
+ ndev-stats.rx_bytes += frame_len;
+
+ netif_receive_skb(skb);
Not sure why nps_enet_rx_handler here does not do most of the processing
of what nps_enet_rx_prep() does, but see below:
+}
+
+static s32 nps_enet_rx_prep(struct net_device *ndev)
+{
+ struct nps_enet_priv *priv = netdev_priv(ndev);
+ struct sk_buff *skb;
+ struct nps_enet_rx_ctl rx_ctrl;
+ u32 frame_len, err = 0;
+ s32 ret = 0;
You do not seem to be propagating anything different than 1 or 0, does
that need to be signed?
+
+ rx_ctrl.value = nps_enet_reg_get(priv, NPS_ENET_REG_RX_CTL);
+ frame_len = rx_ctrl.nr;
+
+ /* Check if we got RX */
+ if (!rx_ctrl.cr) {
+ priv-irq_data.rx_ctrl.value = 0;
+ return ret;
+ }
+
+ /* Check Rx error */
+ if (rx_ctrl.er) {
+ ndev-stats.rx_errors++;
+ err = 1;
+ }
+
+ /* Check Rx CRC error */
+ if (rx_ctrl.crc) {
+ ndev-stats.rx_crc_errors++;
+ ndev-stats.rx_dropped++;
+ err = 1;
+ }
+
+ /* Check Frame length Min 64b */
+ if (unlikely(frame_len ETH_ZLEN)) {
+ ndev-stats.rx_length_errors++;
+ ndev-stats.rx_dropped++;
+ err = 1;
+ }
+
+ if (err)
+ goto rx_irq_clean;
Ok, so ret = 0 means errors and ret = 1 means success, that is pretty
counter intuititive to what other parts of the kernel do.
+
+ /* Skb allocation */
+ skb = netdev_alloc_skb_ip_align(ndev, frame_len);
+ if (unlikely(!skb)) {
+ ndev-stats.rx_errors++;
+ ndev-stats.rx_dropped++;
+ goto rx_irq_clean;
+ }
+
+ /* Copy frame from Rx fifo into the skb */
+ nps_enet_read_rx_fifo(ndev, skb-data, frame_len);
+
+ skb_put(skb, frame_len);
+ skb-dev = ndev;
eth_type_trans does that assignement for you already.
+ skb-protocol = eth_type_trans(skb, ndev);
+ skb-ip_summed = CHECKSUM_UNNECESSARY;
+
+ priv-irq_data.skb = skb;
+ priv-irq_data.rx_ctrl.value = rx_ctrl.value;
So you are retaining the SKB here, called from hard interrupt context
and only processing it in nps_enet_rx_handler(), is there a particular
reason why you are not storing the rx_ctrl status word in top-half and
processing the SKB in bottom-half entirely instead? This needs to be
documented in your driver design.
+ ret = 1;
+ goto rx_irq_frame_done;
+
+rx_irq_clean:
+ /* Clean Rx fifo */
+ nps_enet_clean_rx_fifo(ndev, frame_len);
+ priv-irq_data.rx_ctrl.value = 0;
+
+rx_irq_frame_done:
+ /* Ack Rx ctrl register */
+ nps_enet_reg_set(priv, NPS_ENET_REG_RX_CTL, 0);
+
+ return ret;
+}
+
+static void nps_enet_tx_handler(struct net_device *ndev)
+{
+ struct nps_enet_priv *priv = netdev_priv(ndev);
+ struct nps_enet_tx_ctl tx_ctrl;
+
+ tx_ctrl.value = priv-irq_data.tx_ctrl.value;
+ /* Check if we got TX */
+ if (!priv-tx_packet_sent || tx_ctrl.ct)
+ return;
+
+ /* Check Tx transmit error */
+ if (unlikely(tx_ctrl.et)) {
+ ndev-stats.tx_errors++;
+ } else {
+ ndev-stats.tx_packets++;
+ ndev-stats.tx_bytes += tx_ctrl.nt;
+ }
+
+ /* In nps_enet_start_xmit we disabled sending frames*/
+ netif_wake_queue(ndev);
You might want to explain why this is safe to do here, presumably since
this seems to be a FIFO with a single entry (is that the case?) you can
do that as soon as you get the TX completion interrupt, but this needs
to be documented.
+
+ priv-tx_packet_sent = false;
+}
+
+static s32 nps_enet_tx_prep(struct net_device *ndev)
+{
+ struct nps_enet_priv *priv = netdev_priv(ndev);
+ struct nps_enet_tx_ctl tx_ctrl;
+ s32 ret = 0;
+
+ tx_ctrl.value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
+ if (!tx_ctrl.ct priv-tx_packet_sent) {
+
[PATCH net-next 0/3] net: systemport: misc improvements
Hi David, These patches are highly inspired by changes from Petri on bcmgenet, last patch is a misc fix that I had pending for a while, but is not a candidate for 'net' at this point. Thanks! Florian Fainelli (3): net: systemport: Pre-calculate and utilize cb-bd_addr net: systemport: rewrite bcm_sysport_rx_refill net: systemport: Add a check for oversized packets drivers/net/ethernet/broadcom/bcmsysport.c | 107 - drivers/net/ethernet/broadcom/bcmsysport.h | 2 - 2 files changed, 58 insertions(+), 51 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/3] net: systemport: Pre-calculate and utilize cb-bd_addr
There is a 1:1 mapping between the software maintained control block in
priv-rx_cbs and the buffer address in priv-rx_bds, such that there is
no need to keep computing the buffer address when refiling a control
block.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/bcmsysport.c | 18 +-
drivers/net/ethernet/broadcom/bcmsysport.h | 2 --
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
b/drivers/net/ethernet/broadcom/bcmsysport.c
index 084a50a555de..267330ccd595 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -549,12 +549,7 @@ static int bcm_sysport_rx_refill(struct bcm_sysport_priv
*priv,
}
dma_unmap_addr_set(cb, dma_addr, mapping);
- dma_desc_set_addr(priv, priv-rx_bd_assign_ptr, mapping);
-
- priv-rx_bd_assign_index++;
- priv-rx_bd_assign_index = (priv-num_rx_bds - 1);
- priv-rx_bd_assign_ptr = priv-rx_bds +
- (priv-rx_bd_assign_index * DESC_SIZE);
+ dma_desc_set_addr(priv, cb-bd_addr, mapping);
netif_dbg(priv, rx_status, ndev, RX refill\n);
@@ -568,7 +563,7 @@ static int bcm_sysport_alloc_rx_bufs(struct
bcm_sysport_priv *priv)
unsigned int i;
for (i = 0; i priv-num_rx_bds; i++) {
- cb = priv-rx_cbs[priv-rx_bd_assign_index];
+ cb = priv-rx_cbs[i];
if (cb-skb)
continue;
@@ -1330,14 +1325,14 @@ static inline int tdma_enable_set(struct
bcm_sysport_priv *priv,
static int bcm_sysport_init_rx_ring(struct bcm_sysport_priv *priv)
{
+ struct bcm_sysport_cb *cb;
u32 reg;
int ret;
+ int i;
/* Initialize SW view of the RX ring */
priv-num_rx_bds = NUM_RX_DESC;
priv-rx_bds = priv-base + SYS_PORT_RDMA_OFFSET;
- priv-rx_bd_assign_ptr = priv-rx_bds;
- priv-rx_bd_assign_index = 0;
priv-rx_c_index = 0;
priv-rx_read_ptr = 0;
priv-rx_cbs = kcalloc(priv-num_rx_bds, sizeof(struct bcm_sysport_cb),
@@ -1347,6 +1342,11 @@ static int bcm_sysport_init_rx_ring(struct
bcm_sysport_priv *priv)
return -ENOMEM;
}
+ for (i = 0; i priv-num_rx_bds; i++) {
+ cb = priv-rx_cbs + i;
+ cb-bd_addr = priv-rx_bds + i * DESC_SIZE;
+ }
+
ret = bcm_sysport_alloc_rx_bufs(priv);
if (ret) {
netif_err(priv, hw, priv-netdev, SKB allocation failed\n);
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.h
b/drivers/net/ethernet/broadcom/bcmsysport.h
index 42a4b4a0bc14..f28bf545d7f4 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.h
+++ b/drivers/net/ethernet/broadcom/bcmsysport.h
@@ -663,8 +663,6 @@ struct bcm_sysport_priv {
/* Receive queue */
void __iomem*rx_bds;
- void __iomem*rx_bd_assign_ptr;
- unsigned intrx_bd_assign_index;
struct bcm_sysport_cb *rx_cbs;
unsigned intnum_rx_bds;
unsigned intrx_read_ptr;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 2/3] net: systemport: rewrite bcm_sysport_rx_refill
Currently, bcm_sysport_desc_rx() calls bcm_sysport_rx_refill() at the end of Rx
packet processing loop, after the current Rx packet has already been passed to
napi_gro_receive(). However, bcm_sysport_rx_refill() might fail to allocate a
new
Rx skb, thus leaving a hole on the Rx queue where no valid Rx buffer exists.
To eliminate this situation:
1. Rewrite bcm_sysport_rx_refill() to retain the current Rx skb on the
Rx queue if a new replacement Rx skb can't be allocated and DMA-mapped.
In this case, the data on the current Rx skb is effectively dropped.
2. Modify bcm_sysport_desc_rx() to call bcm_sysport_rx_refill() at the
top of Rx packet processing loop, so that the new replacement Rx skb is
already in place before the current Rx skb is processed.
This is loosely inspired from d6707bec5986 (net: bcmgenet: rewrite
bcmgenet_rx_refill())
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/bcmsysport.c | 81 +++---
1 file changed, 41 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
b/drivers/net/ethernet/broadcom/bcmsysport.c
index 267330ccd595..d777b0db9e63 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -524,62 +524,70 @@ static void bcm_sysport_free_cb(struct bcm_sysport_cb *cb)
dma_unmap_addr_set(cb, dma_addr, 0);
}
-static int bcm_sysport_rx_refill(struct bcm_sysport_priv *priv,
-struct bcm_sysport_cb *cb)
+static struct sk_buff *bcm_sysport_rx_refill(struct bcm_sysport_priv *priv,
+struct bcm_sysport_cb *cb)
{
struct device *kdev = priv-pdev-dev;
struct net_device *ndev = priv-netdev;
+ struct sk_buff *skb, *rx_skb;
dma_addr_t mapping;
- int ret;
- cb-skb = netdev_alloc_skb(priv-netdev, RX_BUF_LENGTH);
- if (!cb-skb) {
+ /* Allocate a new SKB for a new packet */
+ skb = netdev_alloc_skb(priv-netdev, RX_BUF_LENGTH);
+ if (!skb) {
+ priv-mib.alloc_rx_buff_failed++;
netif_err(priv, rx_err, ndev, SKB alloc failed\n);
- return -ENOMEM;
+ return NULL;
}
- mapping = dma_map_single(kdev, cb-skb-data,
+ mapping = dma_map_single(kdev, skb-data,
RX_BUF_LENGTH, DMA_FROM_DEVICE);
- ret = dma_mapping_error(kdev, mapping);
- if (ret) {
+ if (dma_mapping_error(kdev, mapping)) {
priv-mib.rx_dma_failed++;
- bcm_sysport_free_cb(cb);
+ dev_kfree_skb_any(skb);
netif_err(priv, rx_err, ndev, DMA mapping failure\n);
- return ret;
+ return NULL;
}
+ /* Grab the current SKB on the ring */
+ rx_skb = cb-skb;
+ if (likely(rx_skb))
+ dma_unmap_single(kdev, dma_unmap_addr(cb, dma_addr),
+RX_BUF_LENGTH, DMA_FROM_DEVICE);
+
+ /* Put the new SKB on the ring */
+ cb-skb = skb;
dma_unmap_addr_set(cb, dma_addr, mapping);
dma_desc_set_addr(priv, cb-bd_addr, mapping);
netif_dbg(priv, rx_status, ndev, RX refill\n);
- return 0;
+ /* Return the current SKB to the caller */
+ return rx_skb;
}
static int bcm_sysport_alloc_rx_bufs(struct bcm_sysport_priv *priv)
{
struct bcm_sysport_cb *cb;
- int ret = 0;
+ struct sk_buff *skb;
unsigned int i;
for (i = 0; i priv-num_rx_bds; i++) {
cb = priv-rx_cbs[i];
- if (cb-skb)
- continue;
-
- ret = bcm_sysport_rx_refill(priv, cb);
- if (ret)
- break;
+ skb = bcm_sysport_rx_refill(priv, cb);
+ if (skb)
+ dev_kfree_skb(skb);
+ if (!cb-skb)
+ return -ENOMEM;
}
- return ret;
+ return 0;
}
/* Poll the hardware for up to budget packets to process */
static unsigned int bcm_sysport_desc_rx(struct bcm_sysport_priv *priv,
unsigned int budget)
{
- struct device *kdev = priv-pdev-dev;
struct net_device *ndev = priv-netdev;
unsigned int processed = 0, to_process;
struct bcm_sysport_cb *cb;
@@ -587,7 +595,6 @@ static unsigned int bcm_sysport_desc_rx(struct
bcm_sysport_priv *priv,
unsigned int p_index;
u16 len, status;
struct bcm_rsb *rsb;
- int ret;
/* Determine how much we should process since last call */
p_index = rdma_readl(priv, RDMA_PROD_INDEX);
@@ -605,13 +612,8 @@ static unsigned int bcm_sysport_desc_rx(struct
bcm_sysport_priv *priv,
while ((processed to_process) (processed budget)) {
cb = priv-rx_cbs[priv-rx_read_ptr];
- skb = cb-skb
[PATCH net-next 3/3] net: systemport: Add a check for oversized packets
Occasionnaly we may get oversized packets from the hardware which exceed
the nomimal 2KiB buffer size we allocate SKBs with. Add an early check
which drops the packet to avoid invoking skb_over_panic() and move on to
processing the next packet.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/bcmsysport.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
b/drivers/net/ethernet/broadcom/bcmsysport.c
index d777b0db9e63..909ad7a0d480 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -638,6 +638,14 @@ static unsigned int bcm_sysport_desc_rx(struct
bcm_sysport_priv *priv,
p_index, priv-rx_c_index, priv-rx_read_ptr,
len, status);
+ if (unlikely(len RX_BUF_LENGTH)) {
+ netif_err(priv, rx_status, ndev, oversized packet\n);
+ ndev-stats.rx_length_errors++;
+ ndev-stats.rx_errors++;
+ dev_kfree_skb_any(skb);
+ goto next;
+ }
+
if (unlikely(!(status DESC_EOP) || !(status DESC_SOP))) {
netif_err(priv, rx_status, ndev, fragmented
packet!\n);
ndev-stats.rx_dropped++;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] net: dsa: ar8xxx: add regmap support
Le 05/28/15 18:42, Mathieu Olivari a écrit : All switch registers can now be dumped using regmap/debugfs. \# cat /sys/kernel/debug/regmap/mdiobus/registers : 1302 0004: ... ... ethtool has a register dump command, which should already be supported by the current code in net/dsa/slave.c, is there a particular reason why you use debugfs here instead? -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] Documentation: devicetree: add ar8xxx binding
Le 05/28/15 18:42, Mathieu Olivari a écrit :
Add device-tree binding for ar8xxx switch families.
Signed-off-by: Mathieu Olivari math...@codeaurora.org
---
.../devicetree/bindings/net/dsa/qca-ar8xxx.txt | 70
++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dsa/qca-ar8xxx.txt
diff --git a/Documentation/devicetree/bindings/net/dsa/qca-ar8xxx.txt
b/Documentation/devicetree/bindings/net/dsa/qca-ar8xxx.txt
new file mode 100644
index 000..f4fd3f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/qca-ar8xxx.txt
@@ -0,0 +1,70 @@
+* Qualcomm Atheros AR8xxx switch family
+
+Required properties:
+
+- compatible: should be qca,ar8xxx
+- dsa,mii-bus: phandle to the MDIO bus controller, see dsa/dsa.txt
+- dsa,ethernet: phandle to the CPU network interface controller, see
dsa/dsa.txt
+- #size-cells: must be 0
+- #address-cells: must be 2, see dsa/dsa.txt
+
+Subnodes:
+
+The integrated switch subnode should be specified according to the binding
+described in dsa/dsa.txt.
+
+Optional properties:
+
+- qca,port6-phy-mode: if specified, the driver will configure Port 6 in the
+ given phy-mode. See Documentation/devicetree/bindings/net/ethernet.txt for
+ the list of valid phy-mode.
Is there a reason why this is a custom property and not a standard
phy-mode property here such that you could utilize of_get_phy_mode()
with this directly?
+
+- qca,port6-phy-id: if specified, the driver will connect Port 6 to the PHY
+ given as a parameter. In this case, Port6 and the corresponding PHY will be
+ isolated from the rest of the switch. From a system perspective, they will
+ act as a regular PHY.
Same here, is there a reason why this is not a phy-handle property to
a PHY node that sits on a (potentially different) MDIO bus?
+
+Example:
+
+ dsa@0 {
+ compatible = qca,ar8xxx;
+ #address-cells = 2;
+ #size-cells = 0;
+
+ dsa,ethernet = ethernet0;
+ dsa,mii-bus = mii_bus0;
+
+ switch@0 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0 0;/* MDIO address 0, switch 0 in tree */
+
+ qca,port6-phy-mode = sgmii;
+ qca,port6-phy-id = 4;
+
+ port@0 {
+ reg = 11;
+ label = cpu;
+ };
+
+ port@1 {
+ reg = 0;
+ label = lan1;
+ };
+
+ port@2 {
+ reg = 1;
+ label = lan2;
+ };
+
+ port@3 {
+ reg = 2;
+ label = lan3;
+ };
+
+ port@4 {
+ reg = 3;
+ label = lan4;
+ };
+ };
+ };
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/3] net: systemport: rewrite bcm_sysport_rx_refill
Le 05/28/15 20:58, Petri Gynther a écrit : [snip] /* We do not have a backing SKB, so we do not a corresponding Is this comment still valid? I removed it from bcmgenet. Not really, thanks, I will fix that in v2. [snip] + + if (priv-rx_read_ptr == priv-num_rx_bds) if (unlikely(priv-rx_read_ptr == priv-num_rx_bds)) Will fix that as well, thank you! -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 2/3] net: systemport: rewrite bcm_sysport_rx_refill
Currently, bcm_sysport_desc_rx() calls bcm_sysport_rx_refill() at the end of Rx
packet processing loop, after the current Rx packet has already been passed to
napi_gro_receive(). However, bcm_sysport_rx_refill() might fail to allocate a
new
Rx skb, thus leaving a hole on the Rx queue where no valid Rx buffer exists.
To eliminate this situation:
1. Rewrite bcm_sysport_rx_refill() to retain the current Rx skb on the
Rx queue if a new replacement Rx skb can't be allocated and DMA-mapped.
In this case, the data on the current Rx skb is effectively dropped.
2. Modify bcm_sysport_desc_rx() to call bcm_sysport_rx_refill() at the
top of Rx packet processing loop, so that the new replacement Rx skb is
already in place before the current Rx skb is processed.
This is loosely inspired from d6707bec5986 (net: bcmgenet: rewrite
bcmgenet_rx_refill())
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/bcmsysport.c | 87 ++
1 file changed, 41 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
b/drivers/net/ethernet/broadcom/bcmsysport.c
index 267330ccd595..62ea403e15b8 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -524,62 +524,70 @@ static void bcm_sysport_free_cb(struct bcm_sysport_cb *cb)
dma_unmap_addr_set(cb, dma_addr, 0);
}
-static int bcm_sysport_rx_refill(struct bcm_sysport_priv *priv,
-struct bcm_sysport_cb *cb)
+static struct sk_buff *bcm_sysport_rx_refill(struct bcm_sysport_priv *priv,
+struct bcm_sysport_cb *cb)
{
struct device *kdev = priv-pdev-dev;
struct net_device *ndev = priv-netdev;
+ struct sk_buff *skb, *rx_skb;
dma_addr_t mapping;
- int ret;
- cb-skb = netdev_alloc_skb(priv-netdev, RX_BUF_LENGTH);
- if (!cb-skb) {
+ /* Allocate a new SKB for a new packet */
+ skb = netdev_alloc_skb(priv-netdev, RX_BUF_LENGTH);
+ if (!skb) {
+ priv-mib.alloc_rx_buff_failed++;
netif_err(priv, rx_err, ndev, SKB alloc failed\n);
- return -ENOMEM;
+ return NULL;
}
- mapping = dma_map_single(kdev, cb-skb-data,
+ mapping = dma_map_single(kdev, skb-data,
RX_BUF_LENGTH, DMA_FROM_DEVICE);
- ret = dma_mapping_error(kdev, mapping);
- if (ret) {
+ if (dma_mapping_error(kdev, mapping)) {
priv-mib.rx_dma_failed++;
- bcm_sysport_free_cb(cb);
+ dev_kfree_skb_any(skb);
netif_err(priv, rx_err, ndev, DMA mapping failure\n);
- return ret;
+ return NULL;
}
+ /* Grab the current SKB on the ring */
+ rx_skb = cb-skb;
+ if (likely(rx_skb))
+ dma_unmap_single(kdev, dma_unmap_addr(cb, dma_addr),
+RX_BUF_LENGTH, DMA_FROM_DEVICE);
+
+ /* Put the new SKB on the ring */
+ cb-skb = skb;
dma_unmap_addr_set(cb, dma_addr, mapping);
dma_desc_set_addr(priv, cb-bd_addr, mapping);
netif_dbg(priv, rx_status, ndev, RX refill\n);
- return 0;
+ /* Return the current SKB to the caller */
+ return rx_skb;
}
static int bcm_sysport_alloc_rx_bufs(struct bcm_sysport_priv *priv)
{
struct bcm_sysport_cb *cb;
- int ret = 0;
+ struct sk_buff *skb;
unsigned int i;
for (i = 0; i priv-num_rx_bds; i++) {
cb = priv-rx_cbs[i];
- if (cb-skb)
- continue;
-
- ret = bcm_sysport_rx_refill(priv, cb);
- if (ret)
- break;
+ skb = bcm_sysport_rx_refill(priv, cb);
+ if (skb)
+ dev_kfree_skb(skb);
+ if (!cb-skb)
+ return -ENOMEM;
}
- return ret;
+ return 0;
}
/* Poll the hardware for up to budget packets to process */
static unsigned int bcm_sysport_desc_rx(struct bcm_sysport_priv *priv,
unsigned int budget)
{
- struct device *kdev = priv-pdev-dev;
struct net_device *ndev = priv-netdev;
unsigned int processed = 0, to_process;
struct bcm_sysport_cb *cb;
@@ -587,7 +595,6 @@ static unsigned int bcm_sysport_desc_rx(struct
bcm_sysport_priv *priv,
unsigned int p_index;
u16 len, status;
struct bcm_rsb *rsb;
- int ret;
/* Determine how much we should process since last call */
p_index = rdma_readl(priv, RDMA_PROD_INDEX);
@@ -605,29 +612,15 @@ static unsigned int bcm_sysport_desc_rx(struct
bcm_sysport_priv *priv,
while ((processed to_process) (processed budget)) {
cb = priv-rx_cbs[priv-rx_read_ptr];
- skb = cb-skb
[PATCH net-next v2 0/3] net: systemport: misc. improvements
Hi David, These patches are highly inspired by changes from Petri on bcmgenet, last patch is a misc fix that I had pending for a while, but is not a candidate for 'net' at this point. Changes in v2: - added Petri's reviewed-by tag for patches 1 and 2 - reworked patch 2 to remove a now stale comment and use an unlikely optimization Thanks! Florian Fainelli (3): net: systemport: Pre-calculate and utilize cb-bd_addr net: systemport: rewrite bcm_sysport_rx_refill net: systemport: Add a check for oversized packets drivers/net/ethernet/broadcom/bcmsysport.c | 113 +++-- drivers/net/ethernet/broadcom/bcmsysport.h | 2 - 2 files changed, 58 insertions(+), 57 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 1/3] net: systemport: Pre-calculate and utilize cb-bd_addr
There is a 1:1 mapping between the software maintained control block in
priv-rx_cbs and the buffer address in priv-rx_bds, such that there is
no need to keep computing the buffer address when refiling a control
block.
Reviewed-by: Petri Gynther pgynt...@google.com
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/bcmsysport.c | 18 +-
drivers/net/ethernet/broadcom/bcmsysport.h | 2 --
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
b/drivers/net/ethernet/broadcom/bcmsysport.c
index 084a50a555de..267330ccd595 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -549,12 +549,7 @@ static int bcm_sysport_rx_refill(struct bcm_sysport_priv
*priv,
}
dma_unmap_addr_set(cb, dma_addr, mapping);
- dma_desc_set_addr(priv, priv-rx_bd_assign_ptr, mapping);
-
- priv-rx_bd_assign_index++;
- priv-rx_bd_assign_index = (priv-num_rx_bds - 1);
- priv-rx_bd_assign_ptr = priv-rx_bds +
- (priv-rx_bd_assign_index * DESC_SIZE);
+ dma_desc_set_addr(priv, cb-bd_addr, mapping);
netif_dbg(priv, rx_status, ndev, RX refill\n);
@@ -568,7 +563,7 @@ static int bcm_sysport_alloc_rx_bufs(struct
bcm_sysport_priv *priv)
unsigned int i;
for (i = 0; i priv-num_rx_bds; i++) {
- cb = priv-rx_cbs[priv-rx_bd_assign_index];
+ cb = priv-rx_cbs[i];
if (cb-skb)
continue;
@@ -1330,14 +1325,14 @@ static inline int tdma_enable_set(struct
bcm_sysport_priv *priv,
static int bcm_sysport_init_rx_ring(struct bcm_sysport_priv *priv)
{
+ struct bcm_sysport_cb *cb;
u32 reg;
int ret;
+ int i;
/* Initialize SW view of the RX ring */
priv-num_rx_bds = NUM_RX_DESC;
priv-rx_bds = priv-base + SYS_PORT_RDMA_OFFSET;
- priv-rx_bd_assign_ptr = priv-rx_bds;
- priv-rx_bd_assign_index = 0;
priv-rx_c_index = 0;
priv-rx_read_ptr = 0;
priv-rx_cbs = kcalloc(priv-num_rx_bds, sizeof(struct bcm_sysport_cb),
@@ -1347,6 +1342,11 @@ static int bcm_sysport_init_rx_ring(struct
bcm_sysport_priv *priv)
return -ENOMEM;
}
+ for (i = 0; i priv-num_rx_bds; i++) {
+ cb = priv-rx_cbs + i;
+ cb-bd_addr = priv-rx_bds + i * DESC_SIZE;
+ }
+
ret = bcm_sysport_alloc_rx_bufs(priv);
if (ret) {
netif_err(priv, hw, priv-netdev, SKB allocation failed\n);
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.h
b/drivers/net/ethernet/broadcom/bcmsysport.h
index 42a4b4a0bc14..f28bf545d7f4 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.h
+++ b/drivers/net/ethernet/broadcom/bcmsysport.h
@@ -663,8 +663,6 @@ struct bcm_sysport_priv {
/* Receive queue */
void __iomem*rx_bds;
- void __iomem*rx_bd_assign_ptr;
- unsigned intrx_bd_assign_index;
struct bcm_sysport_cb *rx_cbs;
unsigned intnum_rx_bds;
unsigned intrx_read_ptr;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 3/3] net: systemport: Add a check for oversized packets
Occasionnaly we may get oversized packets from the hardware which exceed
the nomimal 2KiB buffer size we allocate SKBs with. Add an early check
which drops the packet to avoid invoking skb_over_panic() and move on to
processing the next packet.
Reviewed-by: Petri Gynther pgynt...@google.com
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
drivers/net/ethernet/broadcom/bcmsysport.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
b/drivers/net/ethernet/broadcom/bcmsysport.c
index 62ea403e15b8..bbd8676a9675 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -632,6 +632,14 @@ static unsigned int bcm_sysport_desc_rx(struct
bcm_sysport_priv *priv,
p_index, priv-rx_c_index, priv-rx_read_ptr,
len, status);
+ if (unlikely(len RX_BUF_LENGTH)) {
+ netif_err(priv, rx_status, ndev, oversized packet\n);
+ ndev-stats.rx_length_errors++;
+ ndev-stats.rx_errors++;
+ dev_kfree_skb_any(skb);
+ goto next;
+ }
+
if (unlikely(!(status DESC_EOP) || !(status DESC_SOP))) {
netif_err(priv, rx_status, ndev, fragmented
packet!\n);
ndev-stats.rx_dropped++;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] DSA and Marvell 88E6352 802.1q support
On 31/05/15 14:21, Scott Feldman wrote: Hi Scott, If I understand you correctly, that means we would expect users to use bridge commands even on non-bridged dsa ports. I don't think we can make this kind of assumption. Users will expect configure VLANs on non-bridge ports as they would normally configure VLANs, using the 8021q module. So I guess we'll have to support the ndo ops for dsa. I think that's fine. There is flexibility here. Using the bridge command for non-bridged ports is a little weird. You'll still need setlink to get the PVID/untagged flags, for the bridged-port cases, as was done in the original RFC patch. I wonder if a new command vlan for the iproute2 pkg would be useful? It would absorb the vconfig command options, making vconfig obsolete. Some of vconfig functionality is already in iproute2, for example ip link add link ... type vlan ... I would definitively like to see that. Right now, this is a little confusing for users to realize that using bridge + VLAN filtering is a lot more powerful to configure a switch rather than using vconfig/iproute add type vlan. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] net: dsa: Properly propagate errors from dsa_switch_setup_one
While shuffling some code around, dsa_switch_setup_one() was introduced, and it was modified to return either an error code using ERR_PTR() or a NULL pointer when running out of memory or failing to setup a switch. This is a problem for its caler: dsa_switch_setup() which uses IS_ERR() and expects to find an error code, not a NULL pointer, so we still try to proceed with dsa_switch_setup() and operate on invalid memory addresses. This can be easily reproduced by having e.g: the bcm_sf2 driver built-in, but having no such switch, such that drv-setup will fail. Fix this by using PTR_ERR() consistently which is both more informative and avoids for the caller to use IS_ERR_OR_NULL(). Fixes: df197195a5248 (net: dsa: split dsa_switch_setup into two functions) Reported-by: Andrew Lunn and...@lunn.ch Signed-off-by: Florian Fainelli f.faine...@gmail.com --- net/dsa/dsa.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c index e6f6cc3a1bcf..392e29a0227d 100644 --- a/net/dsa/dsa.c +++ b/net/dsa/dsa.c @@ -359,7 +359,7 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index, */ ds = kzalloc(sizeof(*ds) + drv-priv_size, GFP_KERNEL); if (ds == NULL) - return NULL; + return ERR_PTR(-ENOMEM); ds-dst = dst; ds-index = index; @@ -370,7 +370,7 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index, ret = dsa_switch_setup_one(ds, parent); if (ret) - return NULL; + return ERR_PTR(ret); return ds; } -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] net: dsa: add QCA AR8xxx switch family support\
On 29/05/15 11:59, Andrew Lunn wrote: On Fri, May 29, 2015 at 11:49:54AM -0700, Mathieu Olivari wrote: On Fri, May 29, 2015 at 04:00:01AM +0200, Andrew Lunn wrote: FYI: I have patches which allow DSA to use two cpu interfaces. Seems to work on my DIR665 with a Marvell Switch. I will post the patches as an RFC. Andrew Does it require the switch CPU ports to support LAG or is it generic enough to allow switch partitioning? When using tags, DSA by default partitions the switch. Each user port is separate from other ports. lan4 will not bridge to lan1 unless you either do it in software, or you implement the .port_join_bridge/.port_leave_bridge/.port_stp_update methods of dsa_switch_driver. What it requires is that for each user port, you can configure what cpu port it should use. Marvell devices have this ability, and at a first look, it seems like SF2 does as well, but i will leave Florian to answer definitively. That's right, such configuration happens by using VLAN_CTL in the context of SF2, by default only Port N and CPU can talk to each other. Bridging ports involving putting them in the same domain, e.g: updating the VLAN_CTL bitmask to include all bridge members. -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
