* Re: [RFC PATCH 4/4] ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode
From: Mugunthan V N @ 2013-09-09 6:42 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, zonque, davem, bcousson, tony, devicetree, linux-omap
In-Reply-To: <522CBC15.5060008@cogentembedded.com>
On Sunday 08 September 2013 11:34 PM, Sergei Shtylyov wrote:
> 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.
I tried with dashes but i get the below error.
$ make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm dtbs
DTC arch/arm/boot/dts/am335x-evm.dtb
Error: arch/arm/boot/dts/am33xx.dtsi:598.11-12 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [arch/arm/boot/dts/am335x-evm.dtb] Error 1
make: *** [dtbs] Error 2
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH] mwifiex: Remove casting the return value which is a void pointer
From: Joe Perches @ 2013-09-09 5:41 UTC (permalink / raw)
To: Jingoo Han
Cc: 'John W. Linville', linux-wireless, netdev,
'David Miller', 'Bing Zhao'
In-Reply-To: <004d01cead1d$3058dcf0$910a96d0$%han@samsung.com>
On Mon, 2013-09-09 at 14:26 +0900, Jingoo Han wrote:
> Casting the return value which is a void pointer is redundant.
> The conversion from void pointer to any other pointer type is
> guaranteed by the C programming language.
spatch (aka: Coccinelle) should be able to find a lot
of these with:
$ cat void.cocci
@@
void *t;
type other;
@@
- (other *)t
+ t
^ permalink raw reply
* Re: TSQ accounting skb->truesize degrades throughput for large packets
From: Cong Wang @ 2013-09-09 5:28 UTC (permalink / raw)
To: netdev
In-Reply-To: <1378486840.31445.36.camel@edumazet-glaptop>
On Fri, 06 Sep 2013 at 17:00 GMT, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2013-09-06 at 17:36 +0100, Zoltan Kiss wrote:
>
>> So I guess it would be good to revisit the default value of this
>> setting.
>
> If ixgbe requires 3 TSO packets in TX ring to get line rate, you also
> can tweak dev->gso_max_size from 65535 to 64000.
>
We observe similar regression on ixgbe driver, also virtio_net driver.
^ permalink raw reply
* [PATCH] mwifiex: Remove casting the return value which is a void pointer
From: Jingoo Han @ 2013-09-09 5:26 UTC (permalink / raw)
To: 'John W. Linville'
Cc: linux-wireless, netdev, 'David Miller',
'Bing Zhao', 'Jingoo Han'
Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/wireless/mwifiex/pcie.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c
index 52da8ee..33fa943 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -93,7 +93,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
struct pci_dev *pdev = to_pci_dev(dev);
if (pdev) {
- card = (struct pcie_service_card *) pci_get_drvdata(pdev);
+ card = pci_get_drvdata(pdev);
if (!card || !card->adapter) {
pr_err("Card or adapter structure is not valid\n");
return 0;
@@ -128,7 +128,7 @@ static int mwifiex_pcie_resume(struct device *dev)
struct pci_dev *pdev = to_pci_dev(dev);
if (pdev) {
- card = (struct pcie_service_card *) pci_get_drvdata(pdev);
+ card = pci_get_drvdata(pdev);
if (!card || !card->adapter) {
pr_err("Card or adapter structure is not valid\n");
return 0;
@@ -2037,7 +2037,7 @@ static irqreturn_t mwifiex_pcie_interrupt(int irq, void *context)
goto exit;
}
- card = (struct pcie_service_card *) pci_get_drvdata(pdev);
+ card = pci_get_drvdata(pdev);
if (!card || !card->adapter) {
pr_debug("info: %s: card=%p adapter=%p\n", __func__, card,
card ? card->adapter : NULL);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net] net: fib: fib6_add: fix potential NULL pointer dereference
From: Matti Vaittinen @ 2013-09-09 6:26 UTC (permalink / raw)
To: Daniel Borkmann, davem, netdev, Lin Ming
In-Reply-To: <20130907193557.GB17248@order.stressinduktion.org>
On 09/07/2013 10:35 PM, ext Hannes Frederic Sowa wrote:
> On Sat, Sep 07, 2013 at 03:13:20PM +0200, Daniel Borkmann wrote:
>> When the kernel is compiled with CONFIG_IPV6_SUBTREES, and we return
>> with an error in fn = fib6_add_1(), then error codes are encoded into
>> the return pointer e.g. ERR_PTR(-ENOENT). In such an error case, we
>> write the error code into err and jump to out, hence enter the if(err)
>> condition. Now, if CONFIG_IPV6_SUBTREES is enabled, we check for:
>>
>> if (pn != fn && pn->leaf == rt)
>> ...
>> if (pn != fn && !pn->leaf && !(pn->fn_flags & RTN_RTINFO))
>> ...
>>
>> Since pn is NULL and fn is f.e. ERR_PTR(-ENOENT), then pn != fn
>> evaluates to true and causes a NULL-pointer dereference on further
>> checks on pn. Fix it, by setting both NULL in error case, so that
>> pn != fn already evaluates to false and no further dereference
>> takes place.
>>
>> This was first correctly implemented in 4a287eba2 ("IPv6 routing,
>> NLM_F_* flag support: REPLACE and EXCL flags support, warn about
>> missing CREATE flag"), but the bug got later on introduced by
>> 188c517a0 ("ipv6: return errno pointers consistently for fib6_add_1()").
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> Cc: Lin Ming <mlin@ss.pku.edu.cn>
>> Cc: Matti Vaittinen <matti.vaittinen@nsn.com>
>> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
>
> Full ACK!
>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>
Acked-by: Matti Vaittinen <matti.vaittinen@nsn.com>
^ permalink raw reply
* [PATCH 2/2] irda: vlsi_ir: Remove casting the return value which is a void pointer
From: Jingoo Han @ 2013-09-09 5:24 UTC (permalink / raw)
To: 'David Miller'; +Cc: netdev, 'Samuel Ortiz'
Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/irda/vlsi_ir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/irda/vlsi_ir.c b/drivers/net/irda/vlsi_ir.c
index 5f47584..c5bd58b 100644
--- a/drivers/net/irda/vlsi_ir.c
+++ b/drivers/net/irda/vlsi_ir.c
@@ -543,7 +543,7 @@ static int vlsi_process_rx(struct vlsi_ring *r, struct ring_descr *rd)
int crclen, len = 0;
struct sk_buff *skb;
int ret = 0;
- struct net_device *ndev = (struct net_device *)pci_get_drvdata(r->pdev);
+ struct net_device *ndev = pci_get_drvdata(r->pdev);
vlsi_irda_dev_t *idev = netdev_priv(ndev);
pci_dma_sync_single_for_cpu(r->pdev, rd_get_addr(rd), r->len, r->dir);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] irda: donauboe: Remove casting the return value which is a void pointer
From: Jingoo Han @ 2013-09-09 5:22 UTC (permalink / raw)
To: 'David Miller'; +Cc: netdev, 'Samuel Ortiz'
Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/irda/donauboe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/irda/donauboe.c b/drivers/net/irda/donauboe.c
index c6bfc4a..bef2243 100644
--- a/drivers/net/irda/donauboe.c
+++ b/drivers/net/irda/donauboe.c
@@ -1488,7 +1488,7 @@ static void
toshoboe_close (struct pci_dev *pci_dev)
{
int i;
- struct toshoboe_cb *self = (struct toshoboe_cb*)pci_get_drvdata(pci_dev);
+ struct toshoboe_cb *self = pci_get_drvdata(pci_dev);
IRDA_DEBUG (4, "%s()\n", __func__);
@@ -1696,7 +1696,7 @@ freeself:
static int
toshoboe_gotosleep (struct pci_dev *pci_dev, pm_message_t crap)
{
- struct toshoboe_cb *self = (struct toshoboe_cb*)pci_get_drvdata(pci_dev);
+ struct toshoboe_cb *self = pci_get_drvdata(pci_dev);
unsigned long flags;
int i = 10;
@@ -1725,7 +1725,7 @@ toshoboe_gotosleep (struct pci_dev *pci_dev, pm_message_t crap)
static int
toshoboe_wakeup (struct pci_dev *pci_dev)
{
- struct toshoboe_cb *self = (struct toshoboe_cb*)pci_get_drvdata(pci_dev);
+ struct toshoboe_cb *self = pci_get_drvdata(pci_dev);
unsigned long flags;
IRDA_DEBUG (4, "%s()\n", __func__);
--
1.7.10.4
^ permalink raw reply related
* 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
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