* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
From: David Miller @ 2013-09-09 4:13 UTC (permalink / raw)
To: hayeswang; +Cc: romieu, netdev, david, fredo, nic_swsd
In-Reply-To: <941AC15120E247718F8B349F9B3B7422@realtek.com.tw>
Please do not quote a patch this way, to our automated systems it makes
it look like another submission of the patch which makes more work for me.
Quoting must use some kind of reasonable prefix on the quoted content
such as "> ", as is common in mailers, to delimit new content from
quoted content.
Thank you.
^ permalink raw reply
* RE: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
From: hayeswang @ 2013-09-09 3:25 UTC (permalink / raw)
To: 'Francois Romieu', netdev
Cc: 'David Miller', 'David R',
'Frédéric Leroy', 'nic_swsd'
In-Reply-To: <20130907231535.GB24530@electric-eye.fr.zoreil.com>
Hi,
For RTL8111D and the later chips, the RxConfig (IO 0x44) bit 14 = 0 means
fetching multi-descriptor once. Note that, the meaning is different from
the RTL8111C. Therefore, the hw would only fetch one descriptor each time
when you set that bit.
I don't have any issue reported about the fetching numbers, so I have no
idea about why it could fix you problem.
Best Regards,
Hayes
-----Original Message-----
From: Francois Romieu [mailto:romieu@fr.zoreil.com]
Sent: Sunday, September 08, 2013 7:16 AM
To: netdev@vger.kernel.org
Cc: David Miller; David R; Frédéric Leroy; Hayeswang
Subject: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169: RxConfig
hack for the 8168evl.") regarding AMD IOMMU errors.
RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the
same.
Tested-by: David R <david@unsolicited.net>
Tested-by: Frédéric Leroy <fredo@starox.org>
Cc: Hayes Wang <hayeswang@realtek.com>
---
Hayes, a ack would be welcome.
drivers/net/ethernet/realtek/r8169.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6f87f2c..3397cee 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4231,6 +4231,7 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_23:
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
break;
case RTL_GIGA_MAC_VER_40:
--
1.8.3.1
------Please consider the environment before printing this e-mail.
^ permalink raw reply related
* e1000e: link up and down issue with TP-Link WDR4300 router
From: Dâniel Fraga @ 2013-09-09 0:33 UTC (permalink / raw)
To: netdev
Since I bought this motherboard (Asus P8Z68V-Pro Gen/3) I have
to deal sometimes (very rare) with this annoying problem:
Sep 8 21:24:43 tux kernel: e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 8 21:24:43 tux kernel: e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
Sep 8 21:24:44 tux kernel: e1000e: eth0 NIC Link is Down
It keeps trying to establish the link forever, going up and down.
Today it happened after I resumed from standby (S3).
My NIC is:
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 05)
If I search in google for "e1000e link up down" I see a LOT of users complaining.
As far as I remember Alan Cox onde wrote this is a issue with "cheap chinese router"
but I don't understand why there isn't a workaround for this annoying problem.
Usually it establishes the link at 1000 Mbps and as long as I don't turn off the router,
it negotiates the link speed correctly.
Is there some workaround for this? If you need more information, just ask!
Thanks.
Ps: I'm using Linux 3.11.0.
--
Linux 3.11.0: Linux for Workgroups
http://www.youtube.com/DanielFragaBR
http://www.libertarios.org.br
^ permalink raw reply
* drivers/net/ethernet/nvidia/forcedeth.c saved_config_space[size] access patch
From: Marc Weber @ 2013-09-08 23:39 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David S. Miller, Jiri Kosina
[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]
1) VER3 and _MAX are of same size:
#define NV_PCI_REGSZ_VER3 0x604
#define NV_PCI_REGSZ_MAX 0x604
2) It looks like there is a case where VER3 get's assigned to
register_size:
if (id->driver_data &
(DEV_HAS_VLAN|DEV_HAS_MSI_X|DEV_HAS_POWER_CNTRL|DEV_HAS_STATISTICS_V2|DEV_HAS_STATISTICS_V
np->register_size = NV_PCI_REGSZ_VER3;
3) the definition of saved_config_space is MAX divided by 4 (size of u32)
struct fe_priv {
[...]
u32 saved_config_space[NV_PCI_REGSZ_MAX/4]
4) This doesn't stop loop at [size-1]:
Thus there is the risk that it overrides the field after
saved_config_space. If that's desired behaviour at least a comment
is missing IMHO:
for (i = 0; i <= np->register_size/sizeof(u32); i++)
np->saved_config_space[i] = readl(base + i*sizeof(u32));
Such for loop is used twice in forcedeth.c
Patch againstn 4de9ad9bc08 (Fri Sep 6 11:14:33) attached fixing both
using < instead of <=.
If you think I've hit a small bug just fix and commit.
I don't care much about my ownership of this patch.
I didn't test this patch because I don't have the hardware and I think
its a trivial case.
Marc Weber
[-- Attachment #2: 0001-forcedepth-fix-possible-out-of-bounds-access.patch --]
[-- Type: application/octet-stream, Size: 1205 bytes --]
From 27cb3ef2e0797597b64773098ae0e4d1680c55cf Mon Sep 17 00:00:00 2001
From: Marc Weber <marc-oweber@gmx.de>
Date: Sun, 8 Sep 2013 23:35:28 +0200
Subject: [PATCH] forcedepth: fix possible out of bounds access
---
drivers/net/ethernet/nvidia/forcedeth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index 098b96d..d08f6ef 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -6106,7 +6106,7 @@ static int nv_suspend(struct device *device)
netif_device_detach(dev);
/* save non-pci configuration space */
- for (i = 0; i <= np->register_size/sizeof(u32); i++)
+ for (i = 0; i < np->register_size/sizeof(u32); i++)
np->saved_config_space[i] = readl(base + i*sizeof(u32));
return 0;
@@ -6121,7 +6121,7 @@ static int nv_resume(struct device *device)
int i, rc = 0;
/* restore non-pci configuration space */
- for (i = 0; i <= np->register_size/sizeof(u32); i++)
+ for (i = 0; i < np->register_size/sizeof(u32); i++)
writel(np->saved_config_space[i], base+i*sizeof(u32));
if (np->driver_data & DEV_NEED_MSI_FIX)
--
1.8.3.4
^ permalink raw reply related
* [PATCH RFC] net: neighbour: use source address of last enqueued packet for solicitation
From: Hannes Frederic Sowa @ 2013-09-08 19:30 UTC (permalink / raw)
To: netdev; +Cc: davem, ja
Currently we always use the first member of the arp_queue to determine
the sender ip address of the arp packet (or in case of IPv6 - source
address of the ndisc packet). This skb is fixed as long as the queue is
not drained by a complete purge because of a timeout or by a successful
response.
If the first packet enqueued on the arp_queue is from a local application
with a manually set source address and the to be discovered system
does some kind of uRPF checks on the source address in the arp packet
the resolving process hangs until a timeout and restarts. This hurts
communication with the participating network node.
This could be mitigated a bit if we use the latest enqueued skb's
source address for the resolving process, which is not as static as
the arp_queue's head. This change of the source address could result in
better recovery of a failed solicitation.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
I didn't find anything which could break because of this change, but
please have a second look.
net/core/neighbour.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 6072610..ca15f32 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -867,7 +867,7 @@ static void neigh_invalidate(struct neighbour *neigh)
static void neigh_probe(struct neighbour *neigh)
__releases(neigh->lock)
{
- struct sk_buff *skb = skb_peek(&neigh->arp_queue);
+ struct sk_buff *skb = skb_peek_tail(&neigh->arp_queue);
/* keep skb alive even if arp_queue overflows */
if (skb)
skb = skb_copy(skb, GFP_ATOMIC);
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC PATCH 4/4] ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode
From: Sergei Shtylyov @ 2013-09-08 18:04 UTC (permalink / raw)
To: Mugunthan V N
Cc: netdev, zonque, davem, bcousson, tony, devicetree-discuss,
linux-omap
In-Reply-To: <1378639438-27686-5-git-send-email-mugunthanvnm@ti.com>
Hello.
On 09/08/2013 03:23 PM, Mugunthan V N wrote:
> Add DT entries for the phy mode selection in AM33xx SoC using cpsw-phy-sel
> driver.
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index f9c5da9..4359672 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -594,6 +594,12 @@
> /* Filled in by U-Boot */
> mac-address = [ 00 00 00 00 00 00 ];
> };
> +
> + phy_sel: cpsw_phy_sel@44e10650 {
Dashes are preferred to uderscores in the device tree names.
> + compatible = "ti,am3352-cpsw-phy-sel";
> + reg= <0x44e10650 0x4>;
> + reg-names = "gmii-sel";
> + };
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v4] ipv6:introduce function to find route for redirect
From: Hannes Frederic Sowa @ 2013-09-08 18:00 UTC (permalink / raw)
To: Duan Jiong; +Cc: davem, netdev
In-Reply-To: <52272233.20307@cn.fujitsu.com>
On Wed, Sep 04, 2013 at 08:06:11PM +0800, Duan Jiong wrote:
> 于 2013年09月04日 03:17, Hannes Frederic Sowa 写道:
> > On Tue, Sep 03, 2013 at 01:37:19PM +0800, Duan Jiong wrote:
> >>> Btw. I still think it should be possible to eliminate
> >>> ip6_redirect_no_header:
> >>>
> >>> We could always use ip6_redirect_no_header and use the data of the redirected
> >>> header option just for finding the socket to be notified. We can do the whole
> >>> verification and route updating in ndisc layer and then just call into icmpv6
> >>> layer if upper protocols need a notification of the redirect. But that should
> >>> go into another patch. ;)
> >>>
> >>
> >> I think this is good, but i have a question below:
> >>
> >> if the socket type is connection-based, the dst information is stored in related
> >> sock struct, so there is no need to look up the route for redirect in ip6_redirect
> >> or ip6_redirect_no_header, in this case, we do the verification and route
> >> updating in the upper protocols' err_handler is better.
> >>
> >> How do you think of this?
> >
> > This should not be a problem, because every cached dst should be validated
> > with ip6_dst_check before it is used. It uses the fib6_node serial number
> > which is incremented for all fib6_nodes on the path to the new installed
> > node by fib6_add_1. So we are safe here.
> >
> > Btw. this is the same logic redirects get currently picked up, too.
> >
>
> Thanks for you answer, but i still have some questions on dealing with redirect
> in ip4ip6_err() and ipip6_err(), and i need some time to learn more about them.
> So i only send one patch to fix the bug.
Coverity discovered that the redirect code in ip6_tunnel.c is logically
dead, which is correct:
639 }
640 if (rel_type == ICMP_REDIRECT)
641 skb_dst(skb2)->ops->redirect(skb_dst(skb2), NULL, skb2);
642
643 icmp_send(skb2, rel_type, rel_code, htonl(rel_info));
rel_type will never be ICMP_REDIRECT in line 640 because of the updates
to rel_type in ip6_tnl_err.
My guess is that we need to move the call to ->redirect to ip6_tnl_err
and afterwards set rel_msg to 0 or we factor out the calls to ->redirect
into the ndisc layer.
I hope this clears up some confusion you had in ip6ip6_err.
Greetings,
Hannes
^ permalink raw reply
* [PATCH] fib6_rules: fix indentation
From: Stefan Tomanek @ 2013-09-08 15:09 UTC (permalink / raw)
To: netdev
This change just removes two tabs from the source file.
Signed-off-by: Stefan Tomanek <stefan.tomanek@wertarbyte.de>
---
net/ipv6/fib6_rules.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c
index a6c58ce..e275916 100644
--- a/net/ipv6/fib6_rules.c
+++ b/net/ipv6/fib6_rules.c
@@ -138,8 +138,8 @@ static bool fib6_rule_suppress(struct fib_rule *rule, struct fib_lookup_arg *arg
return false;
suppress_route:
- ip6_rt_put(rt);
- return true;
+ ip6_rt_put(rt);
+ return true;
}
static int fib6_rule_match(struct fib_rule *rule, struct flowi *fl, int flags)
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net] net: sctp: fix bug in sctp_poll for SOCK_SELECT_ERR_QUEUE
From: Neil Horman @ 2013-09-08 12:07 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, linux-sctp, Jacob Keller
In-Reply-To: <1378565099-20987-1-git-send-email-dborkman@redhat.com>
On Sat, Sep 07, 2013 at 04:44:59PM +0200, Daniel Borkmann wrote:
> If we do not add braces around ...
>
> mask |= POLLERR |
> sock_flag(sk, SOCK_SELECT_ERR_QUEUE) ? POLLPRI : 0;
>
> ... then this condition always evaluates to true as POLLERR is
> defined as 8 and binary or'd with whatever result comes out of
> sock_flag(). Hence instead of (X | Y) ? A : B, transform it into
> X | (Y ? A : B). Unfortunatelty, commit 8facd5fb73 ("net: fix
> smatch warnings inside datagram_poll") forgot about SCTP. :-(
>
> Introduced by 7d4c04fc170 ("net: add option to enable error queue
> packets waking select").
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> ---
> net/sctp/socket.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index d5d5882..5462bbb 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -6176,7 +6176,7 @@ unsigned int sctp_poll(struct file *file, struct socket *sock, poll_table *wait)
> /* Is there any exceptional events? */
> if (sk->sk_err || !skb_queue_empty(&sk->sk_error_queue))
> mask |= POLLERR |
> - sock_flag(sk, SOCK_SELECT_ERR_QUEUE) ? POLLPRI : 0;
> + (sock_flag(sk, SOCK_SELECT_ERR_QUEUE) ? POLLPRI : 0);
> if (sk->sk_shutdown & RCV_SHUTDOWN)
> mask |= POLLRDHUP | POLLIN | POLLRDNORM;
> if (sk->sk_shutdown == SHUTDOWN_MASK)
> --
> 1.7.11.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [RFC PATCH 4/4] ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode
From: Mugunthan V N @ 2013-09-08 11:23 UTC (permalink / raw)
To: netdev
Cc: zonque, davem, bcousson, tony, devicetree-discuss, linux-omap,
Mugunthan V N
In-Reply-To: <1378639438-27686-1-git-send-email-mugunthanvnm@ti.com>
Add DT entries for the phy mode selection in AM33xx SoC using cpsw-phy-sel
driver.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..4359672 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -594,6 +594,12 @@
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
+
+ phy_sel: cpsw_phy_sel@44e10650 {
+ compatible = "ti,am3352-cpsw-phy-sel";
+ reg= <0x44e10650 0x4>;
+ reg-names = "gmii-sel";
+ };
};
ocmcram: ocmcram@40300000 {
--
1.8.4
^ permalink raw reply related
* [RFC PATCH 3/4] drivers: net: cpsw: use cpsw-phy-sel driver to configure phy mode
From: Mugunthan V N @ 2013-09-08 11:23 UTC (permalink / raw)
To: netdev
Cc: zonque, davem, bcousson, tony, devicetree-discuss, linux-omap,
Mugunthan V N
In-Reply-To: <1378639438-27686-1-git-send-email-mugunthanvnm@ti.com>
Phy mode can be configured via the cpsw-phy-sel driver, this patch enabled the
cpsw driver to utilise the api provided by the cpsw-phy-sel driver to configure
the phy mode.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 01c42e1..5efb37b 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1021,6 +1021,10 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
dev_info(priv->dev, "phy found : id is : 0x%x\n",
slave->phy->phy_id);
phy_start(slave->phy);
+
+ /* Configure GMII_SEL register */
+ cpsw_phy_sel(&priv->pdev->dev, slave->phy->interface,
+ slave->slave_num);
}
}
--
1.8.4
^ permalink raw reply related
* [RFC PATCH 2/4] drivers: net: cpsw-phy-sel: Add new driver for phy mode selection for cpsw
From: Mugunthan V N @ 2013-09-08 11:23 UTC (permalink / raw)
To: netdev
Cc: zonque, davem, bcousson, tony, devicetree-discuss, linux-omap,
Mugunthan V N
In-Reply-To: <1378639438-27686-1-git-send-email-mugunthanvnm@ti.com>
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this register is modified, and so it needs reprogramming
after resume.
This patch adds a new driver in which hardware interface can configure
correct register bits when the slave is opened.
The AM33xx also has a bit for each slave to configure the RMII reference
clock direction. Setting it is now supported by a per-slave DT property.
This code path introducted by this patch is currently exclusive for
am33xx and same can be extened to various platforms via the DT compatibility
property.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
.../devicetree/bindings/net/cpsw-phy-sel.txt | 28 ++++
drivers/net/ethernet/ti/Kconfig | 8 +
drivers/net/ethernet/ti/Makefile | 1 +
drivers/net/ethernet/ti/cpsw-phy-sel.c | 161 +++++++++++++++++++++
drivers/net/ethernet/ti/cpsw.h | 2 +
5 files changed, 200 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
create mode 100644 drivers/net/ethernet/ti/cpsw-phy-sel.c
diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
new file mode 100644
index 0000000..d45fc83
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
@@ -0,0 +1,28 @@
+TI CPSW Phy mode Selection Device Tree Bindings
+-----------------------------------------------
+
+Required properties:
+- compatible : Should be "ti,am3352-cpsw-phy-sel"
+- reg : physical base address and size of the cpsw
+ registers map
+- reg-names : names of the register map given in "reg" node
+
+Optional properties:
+-rmii-clock-ext : If present, the driver will configure the RMII
+ interface to external clock usage
+
+Examples:
+
+ phy_sel: cpsw_phy_sel@44e10650 {
+ compatible = "ti,am3352-cpsw-phy-sel";
+ reg= <0x44e10650 0x4>;
+ reg-names = "gmii-sel";
+ };
+
+(or)
+ phy_sel: cpsw_phy_sel@44e10650 {
+ compatible = "ti,am3352-cpsw-phy-sel";
+ reg= <0x44e10650 0x4>;
+ reg-names = "gmii-sel";
+ rmii-clock-ext;
+ };
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index de71b1e..53150c2 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -49,11 +49,19 @@ config TI_DAVINCI_CPDMA
To compile this driver as a module, choose M here: the module
will be called davinci_cpdma. This is recommended.
+config TI_CPSW_PHY_SEL
+ boolean "TI CPSW Switch Phy sel Support"
+ depends on TI_CPSW
+ ---help---
+ This driver supports configuring of the phy mode connected to
+ the CPSW.
+
config TI_CPSW
tristate "TI CPSW Switch Support"
depends on ARM && (ARCH_DAVINCI || SOC_AM33XX)
select TI_DAVINCI_CPDMA
select TI_DAVINCI_MDIO
+ select TI_CPSW_PHY_SEL
---help---
This driver supports TI's CPSW Ethernet Switch.
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index c65148e..9cfaab8 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_CPMAC) += cpmac.o
obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
+obj-$(CONFIG_TI_CPSW_PHY_SEL) += cpsw-phy-sel.o
obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
ti_cpsw-y := cpsw_ale.o cpsw.o cpts.o
diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
new file mode 100644
index 0000000..593f459
--- /dev/null
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -0,0 +1,161 @@
+/* Texas Instruments Ethernet Switch Driver
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/phy.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#include "cpsw.h"
+
+/* AM33xx SoC specific definitions for the CONTROL port */
+#define AM33XX_GMII_SEL_MODE_MII 0
+#define AM33XX_GMII_SEL_MODE_RMII 1
+#define AM33XX_GMII_SEL_MODE_RGMII 2
+
+#define AM33XX_GMII_SEL_RMII2_IO_CLK_EN BIT(7)
+#define AM33XX_GMII_SEL_RMII1_IO_CLK_EN BIT(6)
+
+struct cpsw_phy_sel_priv {
+ struct device *dev;
+ u32 __iomem *gmii_sel;
+ bool rmii_clock_external;
+ void (*cpsw_phy_sel)(struct cpsw_phy_sel_priv *priv,
+ phy_interface_t phy_mode, int slave);
+};
+
+
+static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv *priv,
+ phy_interface_t phy_mode, int slave)
+{
+ u32 reg;
+ u32 mask;
+ u32 mode = 0;
+
+ reg = readl(priv->gmii_sel);
+
+ switch (phy_mode) {
+ case PHY_INTERFACE_MODE_RMII:
+ mode = AM33XX_GMII_SEL_MODE_RMII;
+ break;
+
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ mode = AM33XX_GMII_SEL_MODE_RGMII;
+ break;
+
+ case PHY_INTERFACE_MODE_MII:
+ default:
+ mode = AM33XX_GMII_SEL_MODE_MII;
+ break;
+ };
+
+ mask = 0x3 << (slave * 2) | BIT(slave + 6);
+ mode <<= slave * 2;
+
+ if (priv->rmii_clock_external) {
+ if (slave == 0)
+ mode |= AM33XX_GMII_SEL_RMII1_IO_CLK_EN;
+ else
+ mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
+ }
+
+ reg &= ~mask;
+ reg |= mode;
+
+ writel(reg, priv->gmii_sel);
+}
+
+static struct platform_driver cpsw_phy_sel_driver;
+static int match(struct device *dev, void *data)
+{
+ struct device_node *node = (struct device_node *)data;
+ return dev->of_node == node &&
+ dev->driver == &cpsw_phy_sel_driver.driver;
+}
+
+void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
+{
+ struct device_node *node;
+ struct cpsw_phy_sel_priv *priv;
+
+ node = of_get_child_by_name(dev->of_node, "cpsw_phy_sel");
+ if (!node) {
+ dev_err(dev, "Phy mode driver DT not found\n");
+ return;
+ }
+
+ dev = bus_find_device(&platform_bus_type, NULL, node, match);
+ priv = dev_get_drvdata(dev);
+
+ priv->cpsw_phy_sel(priv, phy_mode, slave);
+}
+EXPORT_SYMBOL_GPL(cpsw_phy_sel);
+
+static const struct of_device_id cpsw_phy_sel_id_table[] = {
+ {
+ .compatible = "ti,am3352-cpsw-phy-sel",
+ .data = &cpsw_gmii_sel_am3352,
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(of, cpsw_phy_sel_id_table);
+
+static int cpsw_phy_sel_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ const struct of_device_id *of_id;
+ struct cpsw_phy_sel_priv *priv;
+
+ of_id = of_match_node(cpsw_phy_sel_id_table, pdev->dev.of_node);
+ if (!of_id)
+ return -EINVAL;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ dev_err(&pdev->dev, "unable to alloc memory for cpsw phy sel\n");
+ return -ENOMEM;
+ }
+
+ priv->cpsw_phy_sel = of_id->data;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gmii-sel");
+ priv->gmii_sel = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->gmii_sel))
+ return PTR_ERR(priv->gmii_sel);
+
+ if (of_find_property(pdev->dev.of_node, "rmii-clock-ext", NULL))
+ priv->rmii_clock_external = true;
+
+ dev_set_drvdata(&pdev->dev, priv);
+
+ return 0;
+}
+
+static struct platform_driver cpsw_phy_sel_driver = {
+ .probe = cpsw_phy_sel_probe,
+ .driver = {
+ .name = "cpsw-phy-sel",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(cpsw_phy_sel_id_table),
+ },
+};
+
+module_platform_driver(cpsw_phy_sel_driver);
+MODULE_AUTHOR("Mugunthan V N <mugunthanvnm@ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index eb3e101..574f49d 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -39,4 +39,6 @@ struct cpsw_platform_data {
bool dual_emac; /* Enable Dual EMAC mode */
};
+void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave);
+
#endif /* __CPSW_H__ */
--
1.8.4
^ permalink raw reply related
* [RFC PATCH 1/4] net: ethernet: cpsw: switch to devres allocations
From: Mugunthan V N @ 2013-09-08 11:23 UTC (permalink / raw)
To: netdev
Cc: zonque, davem, bcousson, tony, devicetree-discuss, linux-omap,
Mugunthan V N
In-Reply-To: <1378639438-27686-1-git-send-email-mugunthanvnm@ti.com>
From: Daniel Mack <zonque@gmail.com>
This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 153 ++++++++++++-----------------------------
1 file changed, 43 insertions(+), 110 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 79974e3..01c42e1 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -367,8 +367,6 @@ struct cpsw_priv {
spinlock_t lock;
struct platform_device *pdev;
struct net_device *ndev;
- struct resource *cpsw_res;
- struct resource *cpsw_wr_res;
struct napi_struct napi;
struct device *dev;
struct cpsw_platform_data data;
@@ -1712,62 +1710,55 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
if (of_property_read_u32(node, "active_slave", &prop)) {
pr_err("Missing active_slave property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data->active_slave = prop;
if (of_property_read_u32(node, "cpts_clock_mult", &prop)) {
pr_err("Missing cpts_clock_mult property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data->cpts_clock_mult = prop;
if (of_property_read_u32(node, "cpts_clock_shift", &prop)) {
pr_err("Missing cpts_clock_shift property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data->cpts_clock_shift = prop;
- data->slave_data = kcalloc(data->slaves, sizeof(struct cpsw_slave_data),
- GFP_KERNEL);
+ data->slave_data = devm_kzalloc(&pdev->dev, data->slaves
+ * sizeof(struct cpsw_slave_data),
+ GFP_KERNEL);
if (!data->slave_data)
- return -EINVAL;
+ return -ENOMEM;
if (of_property_read_u32(node, "cpdma_channels", &prop)) {
pr_err("Missing cpdma_channels property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data->channels = prop;
if (of_property_read_u32(node, "ale_entries", &prop)) {
pr_err("Missing ale_entries property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data->ale_entries = prop;
if (of_property_read_u32(node, "bd_ram_size", &prop)) {
pr_err("Missing bd_ram_size property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data->bd_ram_size = prop;
if (of_property_read_u32(node, "rx_descs", &prop)) {
pr_err("Missing rx_descs property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data->rx_descs = prop;
if (of_property_read_u32(node, "mac_control", &prop)) {
pr_err("Missing mac_control property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data->mac_control = prop;
@@ -1794,8 +1785,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
parp = of_get_property(slave_node, "phy_id", &lenp);
if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
pr_err("Missing slave[%d] phy_id property\n", i);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
phyid = be32_to_cpup(parp+1);
@@ -1825,10 +1815,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
return 0;
-
-error_ret:
- kfree(data->slave_data);
- return ret;
}
static int cpsw_probe_dual_emac(struct platform_device *pdev,
@@ -1870,7 +1856,6 @@ static int cpsw_probe_dual_emac(struct platform_device *pdev,
priv_sl2->coal_intvl = 0;
priv_sl2->bus_freq_mhz = priv->bus_freq_mhz;
- priv_sl2->cpsw_res = priv->cpsw_res;
priv_sl2->regs = priv->regs;
priv_sl2->host_port = priv->host_port;
priv_sl2->host_port_regs = priv->host_port_regs;
@@ -1914,8 +1899,8 @@ static int cpsw_probe(struct platform_device *pdev)
struct cpsw_priv *priv;
struct cpdma_params dma_params;
struct cpsw_ale_params ale_params;
- void __iomem *ss_regs, *wr_regs;
- struct resource *res;
+ void __iomem *ss_regs;
+ struct resource *res, *ss_res;
u32 slave_offset, sliver_offset, slave_size;
int ret = 0, i, k = 0;
@@ -1951,7 +1936,7 @@ static int cpsw_probe(struct platform_device *pdev)
if (cpsw_probe_dt(&priv->data, pdev)) {
pr_err("cpsw: platform data missing\n");
ret = -ENODEV;
- goto clean_ndev_ret;
+ goto clean_runtime_disable_ret;
}
data = &priv->data;
@@ -1965,11 +1950,12 @@ static int cpsw_probe(struct platform_device *pdev)
memcpy(ndev->dev_addr, priv->mac_addr, ETH_ALEN);
- priv->slaves = kzalloc(sizeof(struct cpsw_slave) * data->slaves,
- GFP_KERNEL);
+ priv->slaves = devm_kzalloc(&pdev->dev,
+ sizeof(struct cpsw_slave) * data->slaves,
+ GFP_KERNEL);
if (!priv->slaves) {
- ret = -EBUSY;
- goto clean_ndev_ret;
+ ret = -ENOMEM;
+ goto clean_runtime_disable_ret;
}
for (i = 0; i < data->slaves; i++)
priv->slaves[i].slave_num = i;
@@ -1977,55 +1963,31 @@ static int cpsw_probe(struct platform_device *pdev)
priv->slaves[0].ndev = ndev;
priv->emac_port = 0;
- priv->clk = clk_get(&pdev->dev, "fck");
+ priv->clk = devm_clk_get(&pdev->dev, "fck");
if (IS_ERR(priv->clk)) {
- dev_err(&pdev->dev, "fck is not found\n");
+ dev_err(priv->dev, "fck is not found\n");
ret = -ENODEV;
- goto clean_slave_ret;
+ goto clean_runtime_disable_ret;
}
priv->coal_intvl = 0;
priv->bus_freq_mhz = clk_get_rate(priv->clk) / 1000000;
- priv->cpsw_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!priv->cpsw_res) {
- dev_err(priv->dev, "error getting i/o resource\n");
- ret = -ENOENT;
- goto clean_clk_ret;
- }
- if (!request_mem_region(priv->cpsw_res->start,
- resource_size(priv->cpsw_res), ndev->name)) {
- dev_err(priv->dev, "failed request i/o region\n");
- ret = -ENXIO;
- goto clean_clk_ret;
- }
- ss_regs = ioremap(priv->cpsw_res->start, resource_size(priv->cpsw_res));
- if (!ss_regs) {
- dev_err(priv->dev, "unable to map i/o region\n");
- goto clean_cpsw_iores_ret;
+ ss_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ss_regs = devm_ioremap_resource(&pdev->dev, ss_res);
+ if (IS_ERR(ss_regs)) {
+ ret = PTR_ERR(ss_regs);
+ goto clean_runtime_disable_ret;
}
priv->regs = ss_regs;
priv->version = __raw_readl(&priv->regs->id_ver);
priv->host_port = HOST_PORT_NUM;
- priv->cpsw_wr_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!priv->cpsw_wr_res) {
- dev_err(priv->dev, "error getting i/o resource\n");
- ret = -ENOENT;
- goto clean_iomap_ret;
- }
- if (!request_mem_region(priv->cpsw_wr_res->start,
- resource_size(priv->cpsw_wr_res), ndev->name)) {
- dev_err(priv->dev, "failed request i/o region\n");
- ret = -ENXIO;
- goto clean_iomap_ret;
- }
- wr_regs = ioremap(priv->cpsw_wr_res->start,
- resource_size(priv->cpsw_wr_res));
- if (!wr_regs) {
- dev_err(priv->dev, "unable to map i/o region\n");
- goto clean_cpsw_wr_iores_ret;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ priv->wr_regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->wr_regs)) {
+ ret = PTR_ERR(priv->wr_regs);
+ goto clean_runtime_disable_ret;
}
- priv->wr_regs = wr_regs;
memset(&dma_params, 0, sizeof(dma_params));
memset(&ale_params, 0, sizeof(ale_params));
@@ -2056,12 +2018,12 @@ static int cpsw_probe(struct platform_device *pdev)
slave_size = CPSW2_SLAVE_SIZE;
sliver_offset = CPSW2_SLIVER_OFFSET;
dma_params.desc_mem_phys =
- (u32 __force) priv->cpsw_res->start + CPSW2_BD_OFFSET;
+ (u32 __force) ss_res->start + CPSW2_BD_OFFSET;
break;
default:
dev_err(priv->dev, "unknown version 0x%08x\n", priv->version);
ret = -ENODEV;
- goto clean_cpsw_wr_iores_ret;
+ goto clean_runtime_disable_ret;
}
for (i = 0; i < priv->data.slaves; i++) {
struct cpsw_slave *slave = &priv->slaves[i];
@@ -2089,7 +2051,7 @@ static int cpsw_probe(struct platform_device *pdev)
if (!priv->dma) {
dev_err(priv->dev, "error initializing dma\n");
ret = -ENOMEM;
- goto clean_wr_iomap_ret;
+ goto clean_runtime_disable_ret;
}
priv->txch = cpdma_chan_create(priv->dma, tx_chan_num(0),
@@ -2124,8 +2086,8 @@ static int cpsw_probe(struct platform_device *pdev)
while ((res = platform_get_resource(priv->pdev, IORESOURCE_IRQ, k))) {
for (i = res->start; i <= res->end; i++) {
- if (request_irq(i, cpsw_interrupt, 0,
- dev_name(&pdev->dev), priv)) {
+ if (devm_request_irq(&pdev->dev, i, cpsw_interrupt, 0,
+ dev_name(priv->dev), priv)) {
dev_err(priv->dev, "error attaching irq\n");
goto clean_ale_ret;
}
@@ -2147,7 +2109,7 @@ static int cpsw_probe(struct platform_device *pdev)
if (ret) {
dev_err(priv->dev, "error registering net device\n");
ret = -ENODEV;
- goto clean_irq_ret;
+ goto clean_ale_ret;
}
if (cpts_register(&pdev->dev, priv->cpts,
@@ -2155,44 +2117,27 @@ static int cpsw_probe(struct platform_device *pdev)
dev_err(priv->dev, "error registering cpts device\n");
cpsw_notice(priv, probe, "initialized device (regs %x, irq %d)\n",
- priv->cpsw_res->start, ndev->irq);
+ ss_res->start, ndev->irq);
if (priv->data.dual_emac) {
ret = cpsw_probe_dual_emac(pdev, priv);
if (ret) {
cpsw_err(priv, probe, "error probe slave 2 emac interface\n");
- goto clean_irq_ret;
+ goto clean_ale_ret;
}
}
return 0;
-clean_irq_ret:
- for (i = 0; i < priv->num_irqs; i++)
- free_irq(priv->irqs_table[i], priv);
clean_ale_ret:
cpsw_ale_destroy(priv->ale);
clean_dma_ret:
cpdma_chan_destroy(priv->txch);
cpdma_chan_destroy(priv->rxch);
cpdma_ctlr_destroy(priv->dma);
-clean_wr_iomap_ret:
- iounmap(priv->wr_regs);
-clean_cpsw_wr_iores_ret:
- release_mem_region(priv->cpsw_wr_res->start,
- resource_size(priv->cpsw_wr_res));
-clean_iomap_ret:
- iounmap(priv->regs);
-clean_cpsw_iores_ret:
- release_mem_region(priv->cpsw_res->start,
- resource_size(priv->cpsw_res));
-clean_clk_ret:
- clk_put(priv->clk);
-clean_slave_ret:
+clean_runtime_disable_ret:
pm_runtime_disable(&pdev->dev);
- kfree(priv->slaves);
clean_ndev_ret:
- kfree(priv->data.slave_data);
free_netdev(priv->ndev);
return ret;
}
@@ -2201,30 +2146,18 @@ static int cpsw_remove(struct platform_device *pdev)
{
struct net_device *ndev = platform_get_drvdata(pdev);
struct cpsw_priv *priv = netdev_priv(ndev);
- int i;
if (priv->data.dual_emac)
unregister_netdev(cpsw_get_slave_ndev(priv, 1));
unregister_netdev(ndev);
cpts_unregister(priv->cpts);
- for (i = 0; i < priv->num_irqs; i++)
- free_irq(priv->irqs_table[i], priv);
cpsw_ale_destroy(priv->ale);
cpdma_chan_destroy(priv->txch);
cpdma_chan_destroy(priv->rxch);
cpdma_ctlr_destroy(priv->dma);
- iounmap(priv->regs);
- release_mem_region(priv->cpsw_res->start,
- resource_size(priv->cpsw_res));
- iounmap(priv->wr_regs);
- release_mem_region(priv->cpsw_wr_res->start,
- resource_size(priv->cpsw_wr_res));
pm_runtime_disable(&pdev->dev);
- clk_put(priv->clk);
- kfree(priv->slaves);
- kfree(priv->data.slave_data);
if (priv->data.dual_emac)
free_netdev(cpsw_get_slave_ndev(priv, 1));
free_netdev(ndev);
--
1.8.4
^ permalink raw reply related
* [RFC PATCH 0/4] cpsw: support for control module register
From: Mugunthan V N @ 2013-09-08 11:23 UTC (permalink / raw)
To: netdev
Cc: zonque, davem, bcousson, tony, devicetree-discuss, linux-omap,
Mugunthan V N
This patch series adds the support for configuring GMII_SEL register
of control module to select the phy mode type and also to configure
the clock source for RMII phy mode whether to use internal clock or
the external clock from the phy itself.
Till now CPSW works as this configuration is done in U-Boot and carried
over to the kernel. But during suspend/resume Control module tends to
lose its configured value for GMII_SEL register in AM33xx PG1.0, so
if CPSW is used in RMII or RGMII mode, on resume cpsw is not working
as GMII_SEL register lost its configuration values.
The initial version of the patch is done by Daniel Mack but as per
Tony's comment he wants it as a seperate driver as it is done in USB
control module. I have created a seperate driver for the same and as
the merge window is open now and no feature request is accepted I am
submitting it as RFC for reviews.
Daniel Mack (1):
net: ethernet: cpsw: switch to devres allocations
Mugunthan V N (3):
drivers: net: cpsw-phy-sel: Add new driver for phy mode selection for
cpsw
drivers: net: cpsw: use cpsw-phy-sel driver to configure phy mode
ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode
.../devicetree/bindings/net/cpsw-phy-sel.txt | 28 ++++
arch/arm/boot/dts/am33xx.dtsi | 6 +
drivers/net/ethernet/ti/Kconfig | 8 +
drivers/net/ethernet/ti/Makefile | 1 +
drivers/net/ethernet/ti/cpsw-phy-sel.c | 161 +++++++++++++++++++++
drivers/net/ethernet/ti/cpsw.c | 157 ++++++--------------
drivers/net/ethernet/ti/cpsw.h | 2 +
7 files changed, 253 insertions(+), 110 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
create mode 100644 drivers/net/ethernet/ti/cpsw-phy-sel.c
--
1.8.4
^ permalink raw reply
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
From: Daniel Borkmann @ 2013-09-08 8:45 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev, David Miller, David R, Frédéric Leroy,
Hayes Wang
In-Reply-To: <20130907231535.GB24530@electric-eye.fr.zoreil.com>
On 09/08/2013 01:15 AM, Francois Romieu wrote:
> Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169: RxConfig
> hack for the 8168evl.") regarding AMD IOMMU errors.
>
> RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the
> same.
>
> Tested-by: David R <david@unsolicited.net>
> Tested-by: Frédéric Leroy <fredo@starox.org>
> Cc: Hayes Wang <hayeswang@realtek.com>
> ---
Your signed-off-by is missing.
^ permalink raw reply
* Re: [PATCH net-next v4 1/6] bonding: simplify and use RCU protection for 3ad xmit path
From: Ding Tianhong @ 2013-09-08 6:05 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Nikolay Aleksandrov, Ding Tianhong, Jay Vosburgh, Andy Gospodarek,
David S. Miller, Netdev
In-Reply-To: <20130907150350.GF26163@redhat.com>
于 2013/9/7 23:03, Veaceslav Falico 写道:
> On Sat, Sep 07, 2013 at 04:45:05PM +0200, Nikolay Aleksandrov wrote:
>>
>> On 09/07/2013 04:20 PM, Veaceslav Falico wrote:
>>> On Fri, Sep 06, 2013 at 03:28:07PM +0800, Ding Tianhong wrote:
> ...snip...
>>> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
>>> index f4b1001..37b49d1 100644
>>> --- a/include/linux/rculist.h
>>> +++ b/include/linux/rculist.h
>>> @@ -23,6 +23,7 @@
>>> * way, we must not access it directly
>>> */
>>> #define list_next_rcu(list) (*((struct list_head __rcu
>>> **)(&(list)->next)))
>>> +#define list_prev_rcu(list) (*((struct list_head __rcu
>>> **)(&(list)->prev)))
>>>
>>> /*
>>> * Insert a new entry between two known consecutive entries.
>>> @@ -271,6 +272,12 @@ static inline void list_splice_init_rcu(struct
>>> list_head *list,
>>> likely(__ptr != __next) ? container_of(__next, type, member) : NULL; \
>>> })
>>>
>>> +#define list_last_or_null_rcu(ptr, type, member) \
>>> + ({struct list_head *__ptr = (ptr); \
>>> + struct list_head __rcu *__last = list_prev_rcu(__ptr); \
>>> + likely(__ptr != __last) ? container_of(__prev, type, member) :
>>> NULL; \
>>> + })
>>> +
>> Hi,
>> Actually I don't think you can dereference ->prev and use the standard
>> list_del_rcu because it guarantees only the ->next ptr will be valid and
>> ->prev is set to LIST_POISON2.
>> IMO, you'll need something like this:
>> https://lkml.org/lkml/2012/7/25/193
>> with the bidir_del and all that.
>
> Yeah, right, my bad - we can rely only on the ->next pointer, indeed,
> missed that part. RCU is hard :).
>
> So it'll be a lot harder to implement bond_last_slave_rcu() in a
> 'straightforward' approach.
>
> I'd rather go in the opposite direction here - i.e. drop the 'reverse'
> traversal completely, and all the use cases for bond_last_slave_rcu().
> I've
> got some patches already - http://patchwork.ozlabs.org/patch/272076/
> doing
> that, and hopefully will remove the whole 'backword' traversal completely
> in the future.
>
Although RCU is truely difficult to understand, but it is very
interesting and beautiful,
I will follow your footsteps and finish it.
>>
>> But in any case I complete agree with Veaceslav here. Read all the
>> documentation carefully :-)
>>
>> Cheers,
>> Nik
>>
good lession, read it complete and agreed, it is a hard work to do.
I need more time to review the Veaceslav's patchset and improve my
thought, thanks Nik and Veaceslav.
Best regards
Ding
>>> /**
>>> * list_for_each_entry_rcu - iterate over rcu list of given type
>>> * @pos: the type * to use as a loop cursor.
>>> ------- END OF PATCH ------
>>>
>>> Anyway, it's up to you.
>>>
>>> Hope that helps.
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net] net: ovs: flow: fix potential illegal memory access in __parse_flow_nlattrs
From: Jesse Gross @ 2013-09-08 5:35 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: David Miller, netdev, Andy Zhou, dev@openvswitch.org
In-Reply-To: <1378539694-3635-1-git-send-email-dborkman@redhat.com>
On Sat, Sep 7, 2013 at 12:41 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> In function __parse_flow_nlattrs(), we check for condition
> (type > OVS_KEY_ATTR_MAX) and if true, print an error, but we do
> not return from this function as in other checks. It seems this
> has been forgotten, as otherwise, we could access beyond the
> memory of ovs_key_lens, which is of ovs_key_lens[OVS_KEY_ATTR_MAX + 1].
> Hence, a maliciously prepared nla_type from user space could access
> beyond this upper limit.
>
> Introduced by 03f0d916a ("openvswitch: Mega flow implementation").
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Andy Zhou <azhou@nicira.com>
Yeah, looks like a mistake to me.
Acked-by: Jesse Gross <jesse@nicira.com>
^ permalink raw reply
* Re: [patch net/stable] ipv6/exthdrs: accept tlv which includes only padding
From: YOSHIFUJI Hideaki @ 2013-09-08 4:20 UTC (permalink / raw)
To: David Miller
Cc: eldad, jiri, netdev, kuznet, jmorris, kaber, YOSHIFUJI Hideaki
In-Reply-To: <20130907.215020.38125291010941900.davem@davemloft.net>
Hi.
David Miller wrote:
> From: Eldad Zack <eldad@fogrefinery.com>
> Date: Sat, 7 Sep 2013 14:31:36 +0200 (CEST)
>
>> On Fri, 6 Sep 2013, Jiri Pirko wrote:
>>
>>> Current behaviour breaks TAHI Test v6LC.1.2.6.
>>
>> I'm not familiar with this, but IMHO the test should be reversed :)
>
> I think I agree with Eldad on this, and that TAHI should be adjusted
> to have more reasonable expectations of an implementation.
>
The tests (including packet formats) are based on the test specification:
https://www.ipv6ready.org/?page=documents&tag=ipv6-core-protocols
If we want to change the tests, I think we need to consult with IPv6
Forum.
Regards,
--yoshfuji
^ permalink raw reply
* Re: [PATCH] net: fix multiqueue selection
From: Alexander Duyck @ 2013-09-08 4:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Alexander Duyck
In-Reply-To: <1378580577.26319.26.camel@edumazet-glaptop>
On 09/07/2013 12:02 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> commit 416186fbf8c5b4e4465 ("net: Split core bits of netdev_pick_tx
> into __netdev_pick_tx") added a bug that disables caching of queue
> index in the socket.
>
> This is the source of packet reorders for TCP flows, and
> again this is happening more often when using FQ pacing.
>
> Old code was doing
>
> if (queue_index != old_index)
> sk_tx_queue_set(sk, queue_index);
>
> Alexander renamed the variables but forgot to change sk_tx_queue_set()
> 2nd parameter.
>
> if (queue_index != new_index)
> sk_tx_queue_set(sk, queue_index);
>
> This means we store -1 over and over in sk->sk_tx_queue_mapping
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
> net/core/flow_dissector.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 0ff42f0..1929af8 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -352,7 +352,7 @@ u16 __netdev_pick_tx(struct net_device *dev, struct sk_buff *skb)
>
> if (queue_index != new_index && sk &&
> rcu_access_pointer(sk->sk_dst_cache))
> - sk_tx_queue_set(sk, queue_index);
> + sk_tx_queue_set(sk, new_index);
>
> queue_index = new_index;
> }
>
>
> --
Ugh, my bad. This is a nasty one too since the behaviour appeared to be
correct for most cases.
It looks like this needs to go into stable for 3.9 - 3.11.
Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
^ permalink raw reply
* [010/121] sctp: fully initialize sctp_outq in sctp_outq_init
From: Ben Hutchings @ 2013-09-08 2:52 UTC (permalink / raw)
To: linux-kernel, stable
Cc: akpm, davem, Vlad Yasevich, Neil Horman, netdev,
West, Steve (NSN - US/Fort Worth)
In-Reply-To: <lsq.1378608720.401499712@decadent.org.uk>
3.2.51-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Neil Horman <nhorman@tuxdriver.com>
[ Upstream commit c5c7774d7eb4397891edca9ebdf750ba90977a69 ]
In commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86
(refactor sctp_outq_teardown to insure proper re-initalization)
we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
outq structure. Steve West recently asked me why I removed the q->error = 0
initalization from sctp_outq_teardown. I did so because I was operating under
the impression that sctp_outq_init would properly initalize that value for us,
but it doesn't. sctp_outq_init operates under the assumption that the outq
struct is all 0's (as it is when called from sctp_association_init), but using
it in __sctp_outq_teardown violates that assumption. We should do a memset in
sctp_outq_init to ensure that the entire structure is in a known state there
instead.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: "West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: netdev@vger.kernel.org
CC: davem@davemloft.net
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/sctp/outqueue.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 96eb168..3dd7207 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -205,6 +205,8 @@ static inline int sctp_cacc_skip(struct sctp_transport *primary,
*/
void sctp_outq_init(struct sctp_association *asoc, struct sctp_outq *q)
{
+ memset(q, 0, sizeof(struct sctp_outq));
+
q->asoc = asoc;
INIT_LIST_HEAD(&q->out_chunk_list);
INIT_LIST_HEAD(&q->control_chunk_list);
@@ -212,13 +214,7 @@ void sctp_outq_init(struct sctp_association *asoc, struct sctp_outq *q)
INIT_LIST_HEAD(&q->sacked);
INIT_LIST_HEAD(&q->abandoned);
- q->fast_rtx = 0;
- q->outstanding_bytes = 0;
q->empty = 1;
- q->cork = 0;
-
- q->malloced = 0;
- q->out_qlen = 0;
}
/* Free the outqueue structure and any related pending chunks.
^ permalink raw reply related
* Re: [patch net/stable] ipv6/exthdrs: accept tlv which includes only padding
From: David Miller @ 2013-09-08 1:50 UTC (permalink / raw)
To: eldad; +Cc: jiri, netdev, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <alpine.LNX.2.00.1309071427120.1262@heraclitus>
From: Eldad Zack <eldad@fogrefinery.com>
Date: Sat, 7 Sep 2013 14:31:36 +0200 (CEST)
> On Fri, 6 Sep 2013, Jiri Pirko wrote:
>
>> Current behaviour breaks TAHI Test v6LC.1.2.6.
>
> I'm not familiar with this, but IMHO the test should be reversed :)
I think I agree with Eldad on this, and that TAHI should be adjusted
to have more reasonable expectations of an implementation.
^ permalink raw reply
* Re: [PATCH] bnx2x: avoid atomic allocations during initialization
From: David Miller @ 2013-09-08 1:48 UTC (permalink / raw)
To: dkravkov; +Cc: dmitry, mschmidt, netdev, ariele, eilong
In-Reply-To: <CAM8tLiPCUS3_jo4KU1zY9+8wRg08fA0ohH9d+0a4jyC69D9JZg@mail.gmail.com>
From: Dmitry Kravkov <dkravkov@gmail.com>
Date: Sat, 7 Sep 2013 12:07:50 +0300
> On Sat, Sep 7, 2013 at 7:29 AM, David Miller <davem@davemloft.net> wrote:
>> Probe should never fail because of an atomic memory allocation if at
>> all possible.
> We here are in open() flow, not probe()
It's the same from my perspective.
Better to drop some packets than have _COMPLETELY INOPERATIVE INTERFACE_.
^ permalink raw reply
* [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
From: Francois Romieu @ 2013-09-07 23:15 UTC (permalink / raw)
To: netdev; +Cc: David Miller, David R, Frédéric Leroy, Hayes Wang
Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169: RxConfig
hack for the 8168evl.") regarding AMD IOMMU errors.
RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the
same.
Tested-by: David R <david@unsolicited.net>
Tested-by: Frédéric Leroy <fredo@starox.org>
Cc: Hayes Wang <hayeswang@realtek.com>
---
Hayes, a ack would be welcome.
drivers/net/ethernet/realtek/r8169.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6f87f2c..3397cee 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4231,6 +4231,7 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_23:
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
break;
case RTL_GIGA_MAC_VER_40:
--
1.8.3.1
^ permalink raw reply related
* Re: [net v6 1/8] i40e: main driver core
From: Francois Romieu @ 2013-09-07 23:01 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: Daniel Borkmann, Kirsher, Jeffrey T, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Nelson, Shannon, Waskiewicz Jr, Peter P,
e1000-devel@lists.sourceforge.net
In-Reply-To: <1378581636.2509.12.camel@jbrandeb-mobl.amr.corp.intel.com>
Brandeburg, Jesse <jesse.brandeburg@intel.com> :
> On Sat, 2013-09-07 at 08:44 +0200, Daniel Borkmann wrote:
>
> > Nitpicking ... at some point in time i40e_status should be removed plus
> > I40E_ERR_PARAM, I40E_SUCCESS, I40E_ERR_NO_MEMORY and the like, as we have
> > int and -EINVAL, 0, -ENOMEM for that. ;-)
>
> First, thanks Daniel for taking the time to review.
>
> Those are a result of our files that are shared across OSes, as not all
> OSes have -ENOMEM etc, we also have a lot of status codes the kernel
> doesn't have. That said, when there is a 1-1 relationship the
> replacements should be made.
It should always be made. You have kept ignoring it since june (see
Ben Hutchings's comment on 2013/06/19).
Where did you see that rules changed and the linux kernel should care
about OS shared code ?
- the patchkit does not include a Makefile to compile from patch #1
- it would not compile since patch #1 depends on stuff that appears
later (see i40e_hw or i40e_lump_tracking for instance).
- some of the I40E_ERR_PARAM error can't happen or are assert() in
disguise that could / should instead BUG(). There is no reason to
confuse these with runtime failures, especially as code gets really
tested on hardware.
I could understand it from some newly introduced company but it's
a bit deceptive from Intel. :o/
--
Ueimor
^ permalink raw reply
* Re: [patch net/stable] ipv6/exthdrs: accept tlv which includes only padding
From: Hannes Frederic Sowa @ 2013-09-07 22:03 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Eldad Zack, netdev, davem, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20130907213445.GB1442@minipsycho.orion>
Hello!
On Sat, Sep 07, 2013 at 11:34:45PM +0200, Jiri Pirko wrote:
> Sat, Sep 07, 2013 at 06:46:12PM CEST, eldad@fogrefinery.com wrote:
> >
> >
> >On Sat, 7 Sep 2013, Jiri Pirko wrote:
> >
> >> Sat, Sep 07, 2013 at 02:31:36PM CEST, eldad@fogrefinery.com wrote:
> >> >
> >> >Hi Jiri,
> >> >
> >> >On Fri, 6 Sep 2013, Jiri Pirko wrote:
> >> >
> >> >> In rfc4942 and rfc2460 I cannot find anything which would implicate to
> >> >> drop packets which have only padding in tlv.
> >> >
> >> >NAK from my side.
> >> >Please read RFC4942 2.1.9.5 "Misuse of Pad1 and PadN Options".
> >>
> >> I did.
> >>
> >> >
> >> >While it doesn't specifically discusses this corner case, you can
> >> >understand from "There is no legitimate reason for padding beyond the
> >> >next eight octet..." that there's also no legitimate reason for an
> >> >option header containing only padding.
There could be a legitimate reason: if a firewall wants to discard a HBH
or DOH it could easily zero out the option space instead of rearranging
the segment. But to make this happen in the general case all limits
regarding padding options would have to be dropped, too. That said,
I don't see this as an valid argument.
> >>
> >> Okay. I'm glad you agree with me and that we both understand the rfc the
> >> same way. And since the rfc does not say that "here's no legitimate
> >> reason for an option header containing only padding", this should be
> >> possible. I say we respect rfc and do not add stronger restrictions than
> >> it dictates. No need for them.
> >
> >Strictly speaking, this RFC is informational, so it is doesn't dictate
> >per se. I hope you don't suggest removing the other checks as well...
>
> If there are some that just plainly assumes something and does
> restrictions without any solid argument, yes remove them.
>
> >
> >> >I can't imagine a sane use-case for this.
> >>
> >> rfcs are not about sanity...
> >
> >Great, we're in agreement again :) But I think the networking code is
> >or should be.
> >What IPv6 stack would generate such a packet, given that the only usage
> >of the padding options is to align other options?
>
> But why not? I do not see anything evil about that. And rfc allows it.
It is easier to generate valid ipv6 frames which are fragmented in the
header chain. This makes it harder for firewalls to match packets etc.
This was a known attack vector with e.g. router advertisments and
fragmentation. Filters implemented in switches could be circumvented
because they did not match the fragmented RA but the host correctly did
reassemble the packet.
> >Why should I accept a packet which is most likely an artificially
> >crafted packet (RFC 3514)?
Of course, dropping this check won't do big harm. But I actually like
the strictness of the ipv6 header chain checks and dropping this just
for the IPv6 Ready Logo doesn't seem right. Perhaps one could talk to
the people of tahi.org first?
Greetings,
Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox