* [PATCH net-next v2] ipv4: defer fib_compute_spec_dst() call
From: Eric Dumazet @ 2012-07-05 8:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
ip_options_compile() can avoid calling fib_compute_spec_dst()
by default, and perform the call only if needed.
David suggested to add a helper to make the call only once.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ip_options.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 1f02251..a19d647 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -242,6 +242,15 @@ void ip_options_fragment(struct sk_buff *skb)
opt->ts_needtime = 0;
}
+/* helper used by ip_options_compile() to call fib_compute_spec_dst()
+ * at most one time.
+ */
+static void spec_dst_fill(__be32 *spec_dst, struct sk_buff *skb)
+{
+ if (*spec_dst == htonl(INADDR_ANY))
+ *spec_dst = fib_compute_spec_dst(skb);
+}
+
/*
* Verify options and fill pointers in struct options.
* Caller should clear *opt, and set opt->data.
@@ -251,7 +260,7 @@ void ip_options_fragment(struct sk_buff *skb)
int ip_options_compile(struct net *net,
struct ip_options *opt, struct sk_buff *skb)
{
- __be32 spec_dst = (__force __be32) 0;
+ __be32 spec_dst = htonl(INADDR_ANY);
unsigned char *pp_ptr = NULL;
struct rtable *rt = NULL;
unsigned char *optptr;
@@ -260,8 +269,6 @@ int ip_options_compile(struct net *net,
if (skb != NULL) {
rt = skb_rtable(skb);
- if (rt)
- spec_dst = fib_compute_spec_dst(skb);
optptr = (unsigned char *)&(ip_hdr(skb)[1]);
} else
optptr = opt->__data;
@@ -334,6 +341,7 @@ int ip_options_compile(struct net *net,
goto error;
}
if (rt) {
+ spec_dst_fill(&spec_dst, skb);
memcpy(&optptr[optptr[2]-1], &spec_dst, 4);
opt->is_changed = 1;
}
@@ -376,6 +384,7 @@ int ip_options_compile(struct net *net,
}
opt->ts = optptr - iph;
if (rt) {
+ spec_dst_fill(&spec_dst, skb);
memcpy(&optptr[optptr[2]-1], &spec_dst, 4);
timeptr = &optptr[optptr[2]+3];
}
^ permalink raw reply related
* Re: TCP transmit performance regression
From: Ming Lei @ 2012-07-05 8:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Network Development, David Miller
In-Reply-To: <1341474192.2583.3299.camel@edumazet-glaptop>
On Thu, Jul 5, 2012 at 3:43 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-07-05 at 09:45 +0800, Ming Lei wrote:
>> Hi,
>>
>> I observed that on both 3.5-rc5 and 3.5-rc5-next, TCP transmit performance
>> degrades a lot, see my below simple test:
>>
>> 1, test box
>> NIC: 100M USB, normally can reach > 90Mbits/sec
>>
>
> What was the last "OK" kernel version ?
After some investigation, the problem is caused by enabling
DEBUG_SLAB, so it is not a regression.
>
> What NIC driver is it ?
>
>> 2, run below command on the box:
>> [root@root]#iperf -c 192.168.0.103 -w 131072 -t 10
>> ------------------------------------------------------------
>> Client connecting to 192.168.0.103, TCP port 5001
>> TCP window size: 256 KByte (WARNING: requested 128 KByte)
>> ------------------------------------------------------------
>> [ 3] local 192.168.0.108 port 59315 connected with 192.168.0.103 port 5001
>> [ ID] Interval Transfer Bandwidth
>> [ 3] 0.0-10.0 sec 40.4 MBytes 33.9 Mbits/sec
>>
>> note: 192.168.0.103 is another production machine running 'iperf -s -w 131072'
>>
>> 3, from traffic captured in wireshark, the window size of most of tcp packets
>> from the test box to 192.168.0.103 is set as 229, looks very weird and should
>> be the cause of performance regression.
>>
>
> Packets sent to 192.168.0.103 announce the window suitable for packets
> in the other way, so not relevant to your problem.
>
> Could you do
>
> # tcpdump -i eth0 -s 100 -c 1000 -w tcp.pcap host 192.168.0.103 &
> # iperf -c 192.168.0.103 -w 131072 -t 10
>
> and post the tcp.pcap file ?
>
> By the way, if you remove -w 131072 (on both sides), I guess throughput
> will increase.
Looks no improvement. I still don't know why the window size becomes so
small even in good situation(disabling DEBUG_SLAB), and the small
window size will cause almost every tcp data packet acked.
Thanks,
--
Ming Lei
^ permalink raw reply
* [patch] [AX.25]: small cleanup in ax25_addr_parse()
From: Dan Carpenter @ 2012-07-05 8:27 UTC (permalink / raw)
To: Ralf Baechle; +Cc: David S. Miller, linux-hams, netdev, kernel-janitors
The comments were wrong here because "AX25_MAX_DIGIS" is 8 but the
comments say 6. Also I've changed the "7" to "AX25_ADDR_LEN".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/ax25/ax25_addr.c b/net/ax25/ax25_addr.c
index 9162409..e7c9b0e 100644
--- a/net/ax25/ax25_addr.c
+++ b/net/ax25/ax25_addr.c
@@ -189,8 +189,10 @@ const unsigned char *ax25_addr_parse(const unsigned char *buf, int len,
digi->ndigi = 0;
while (!(buf[-1] & AX25_EBIT)) {
- if (d >= AX25_MAX_DIGIS) return NULL; /* Max of 6 digis */
- if (len < 7) return NULL; /* Short packet */
+ if (d >= AX25_MAX_DIGIS)
+ return NULL;
+ if (len < AX25_ADDR_LEN)
+ return NULL;
memcpy(&digi->calls[d], buf, AX25_ADDR_LEN);
digi->ndigi = d + 1;
^ permalink raw reply related
* Re: [PATCH] ipv4: Create and use fib_compute_spec_dst() helper.
From: Eric Dumazet @ 2012-07-05 8:10 UTC (permalink / raw)
To: David Miller; +Cc: ja, netdev
In-Reply-To: <20120705.005940.1078811938047681715.davem@davemloft.net>
On Thu, 2012-07-05 at 00:59 -0700, David Miller wrote:
> Yes, this is a great idea. Actually in some obscure cases your
> change can cause us to compute it more than once I think.
>
> I'd suggest we do something like create a helper function above this
> code in ip_options.c that checks whether spec_dst is INADDR_ANY or
> not, to guard computing it multiple times.
>
> Could you put together a quick patch like that?
Sure I'll do that.
^ permalink raw reply
* Re: AF_BUS socket address family
From: Linus Walleij @ 2012-07-05 7:59 UTC (permalink / raw)
To: Vincent Sanders
Cc: netdev, linux-kernel, David S. Miller, Arve Hjønnevåg,
Daniel Walker, John Stultz, Anton Vorontsov, Greg Kroah-Hartman
In-Reply-To: <1340988354-26981-1-git-send-email-vincent.sanders@collabora.co.uk>
2012/6/29 Vincent Sanders <vincent.sanders@collabora.co.uk>:
> AF_BUS is a message oriented inter process communication system.
We have a very huge and important in-kernel IPC message passer
in drivers/staging/android/binder.c
It's deployed in some 400 million devices according to latest reports.
John Stultz & Anton Vorontsov are trying to look after these Android
drivers a bit...
I and others discussed this in the past with the Android folks. Dianne
makes an excellent summary of how it works here:
https://lkml.org/lkml/2009/6/25/3
If we could all be convinced that this thing also fulfills the needs
of what binder does, this is a pretty solid case for it too. I can
sure see that some of the shortcuts that Android is taking with
binder try to address the same issue of high-speed IPC loopholes
through the kernel and some kind of security model.
Whether Android would actually use it (or wrap it) is a totally
different question, but what I think we need to know is whether it
*could*. And staging code has to move forward, maybe this
is the direction it should move?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] ipv4: Create and use fib_compute_spec_dst() helper.
From: David Miller @ 2012-07-05 7:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: ja, netdev
In-Reply-To: <1341474745.2583.3325.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 05 Jul 2012 09:52:25 +0200
> [PATCH] ipv4: defer fib_compute_spec_dst() call
>
> ip_options_compile() can avoid calling fib_compute_spec_dst()
> by default, and perform the call if needed.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Yes, this is a great idea. Actually in some obscure cases your
change can cause us to compute it more than once I think.
I'd suggest we do something like create a helper function above this
code in ip_options.c that checks whether spec_dst is INADDR_ANY or
not, to guard computing it multiple times.
Could you put together a quick patch like that?
^ permalink raw reply
* Re: [PATCH] ipv4: Create and use fib_compute_spec_dst() helper.
From: Eric Dumazet @ 2012-07-05 7:52 UTC (permalink / raw)
To: David Miller; +Cc: ja, netdev
In-Reply-To: <20120704.161335.1503971699878518173.davem@davemloft.net>
On Wed, 2012-07-04 at 16:13 -0700, David Miller wrote:
> ====================
> ipv4: Fix crashes in ip_options_compile().
>
> The spec_dst uses should be guarded by skb_rtable() being non-NULL
> not just the SKB being non-null.
>
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
Seems good to me thanks.
By the way, maybe we can defer fib_compute_spec_dst() call to the point
we really need it ?
[PATCH] ipv4: defer fib_compute_spec_dst() call
ip_options_compile() can avoid calling fib_compute_spec_dst()
by default, and perform the call if needed.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 1f02251..54ab83f 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -260,8 +260,6 @@ int ip_options_compile(struct net *net,
if (skb != NULL) {
rt = skb_rtable(skb);
- if (rt)
- spec_dst = fib_compute_spec_dst(skb);
optptr = (unsigned char *)&(ip_hdr(skb)[1]);
} else
optptr = opt->__data;
@@ -334,6 +332,7 @@ int ip_options_compile(struct net *net,
goto error;
}
if (rt) {
+ spec_dst = fib_compute_spec_dst(skb);
memcpy(&optptr[optptr[2]-1], &spec_dst, 4);
opt->is_changed = 1;
}
@@ -376,6 +375,7 @@ int ip_options_compile(struct net *net,
}
opt->ts = optptr - iph;
if (rt) {
+ spec_dst = fib_compute_spec_dst(skb);
memcpy(&optptr[optptr[2]-1], &spec_dst, 4);
timeptr = &optptr[optptr[2]+3];
}
^ permalink raw reply related
* Re: TCP transmit performance regression
From: Eric Dumazet @ 2012-07-05 7:43 UTC (permalink / raw)
To: Ming Lei; +Cc: Network Development, David Miller
In-Reply-To: <CACVXFVNM-Db=_793SVfRj+nxGtNG0pRFrwc_F9TGbU0FfES63A@mail.gmail.com>
On Thu, 2012-07-05 at 09:45 +0800, Ming Lei wrote:
> Hi,
>
> I observed that on both 3.5-rc5 and 3.5-rc5-next, TCP transmit performance
> degrades a lot, see my below simple test:
>
> 1, test box
> NIC: 100M USB, normally can reach > 90Mbits/sec
>
What was the last "OK" kernel version ?
What NIC driver is it ?
> 2, run below command on the box:
> [root@root]#iperf -c 192.168.0.103 -w 131072 -t 10
> ------------------------------------------------------------
> Client connecting to 192.168.0.103, TCP port 5001
> TCP window size: 256 KByte (WARNING: requested 128 KByte)
> ------------------------------------------------------------
> [ 3] local 192.168.0.108 port 59315 connected with 192.168.0.103 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0-10.0 sec 40.4 MBytes 33.9 Mbits/sec
>
> note: 192.168.0.103 is another production machine running 'iperf -s -w 131072'
>
> 3, from traffic captured in wireshark, the window size of most of tcp packets
> from the test box to 192.168.0.103 is set as 229, looks very weird and should
> be the cause of performance regression.
>
Packets sent to 192.168.0.103 announce the window suitable for packets
in the other way, so not relevant to your problem.
Could you do
# tcpdump -i eth0 -s 100 -c 1000 -w tcp.pcap host 192.168.0.103 &
# iperf -c 192.168.0.103 -w 131072 -t 10
and post the tcp.pcap file ?
By the way, if you remove -w 131072 (on both sides), I guess throughput
will increase.
^ permalink raw reply
* Re: [PATCH net 3/7] qlge: Garbage values shown in extra info during selftest.
From: David Miller @ 2012-07-05 7:23 UTC (permalink / raw)
To: jitendra.kalsaria; +Cc: netdev, ron.mercer, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1341272514-5156-4-git-send-email-jitendra.kalsaria@qlogic.com>
Why are you posting an arbitrary patch from a patch series,
yet not the rest of that series?
This needs to be sent alongside the rest of the series.
^ permalink raw reply
* RE: BISECTED: Re: REGRESSION: 3.4.0->3.5.0-rc2 kernel WARNING on cable plug on Acer Aspire One, no network
From: Marek Szyprowski @ 2012-07-05 6:58 UTC (permalink / raw)
To: 'Alex Villacís Lasso', 'Francois Romieu',
netdev
In-Reply-To: <4FF514B2.4050000@palosanto.com>
Hello,
On Thursday, July 05, 2012 6:15 AM Alex Villacís Lasso wrote:
> El 04/07/12 02:02, Marek Szyprowski escribió:
> > Hello,
> >
> > On Tuesday, July 03, 2012 4:27 PM Alex Villací¬s Lasso wrote:
> >
> >> El 03/07/12 00:40, Marek Szyprowski escribió:
> >>> Hi Alex,
> >>>
> >>> On Tuesday, July 03, 2012 4:45 AM Alex Villacís Lasso wrote:
> >>>
> >>>> -------- Mensaje original --------
> >>>> Asunto: BISECTED: Re: REGRESSION: 3.4.0->3.5.0-rc2 kernel WARNING on cable
> >>>> plug on Acer Aspire One, no network Fecha: Mon, 02 Jul 2012 21:33:41 -0500 De:
> >>>> Alex Villacís Lasso <a_villacis@palosanto.com> Para: Francois Romieu
> >>>> <romieu@fr.zoreil.com> CC: netdev@vger.kernel.org
> >>>> El 01/07/12 08:50, Alex Villacís Lasso escribió:
> >>>>> El 11/06/12 16:38, Francois Romieu escribió:
> >>>>>> Alex Villacís Lasso <a_villacis@palosanto.com> :
> >>>>>> [...]
> >>>>>>> $ grep XID dmesg-3.5.0-rc2.txt
> >>>>>>> [ 15.873858] r8169 0000:02:00.0: eth0: RTL8102e at 0xf7c0e000,
> >>>>>>> 00:1e:68:e5:5d:b1, XID 04a00000 IRQ 44
> >>>>>> The 8102e has not been touched by that many suspect patches but I do
> >>>>>> not see where the problem is :o(
> >>>>>>
> >>>>>> Can you peel off the r8169 patches between 3.4.0 and 3.5-rc ?
> >>>>>>
> >>>>> Still present in 3.5-rc5. Bisection still in progress.
> >>>>>
> >>>>> --
> >>>>> 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
> >>>> My full bisection points to this commit:
> >>>>
> >>>> commit 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6
> >>>> Author: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>> Date: Thu Dec 29 13:09:51 2011 +0100
> >>>>
> >>>> X86: integrate CMA with DMA-mapping subsystem
> >>>>
> >>>> This patch adds support for CMA to dma-mapping subsystem for x86
> >>>> architecture that uses common pci-dma/pci-nommu implementation. This
> >>>> allows to test CMA on KVM/QEMU and a lot of common x86 boxes.
> >>>>
> >>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> >>>> CC: Michal Nazarewicz <mina86@mina86.com>
> >>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
> >>>>
> >>>> Is this commit somehow messing with the network card DMA?
> >>> This commit in fact touches DMA-mapping subsystem and introduces a bug,
> >>> which has been finally fixed by commit c080e26edc3a2a3 merged to v3.5-rc3.
> >>> After applying it the DMA-mapping subsystem should work exactly the same was
> >>> as in v3.4. Could you please check if it fixes this issue?
> >>>
> >>> Best regards
> >> No. It still fails in 3.5-rc5, as mentioned before.
> > Hmm. I was a bit confused, because both the subject and git bisect log pointed to v3.5-rc2,
> > which had that bug. Maybe there is one some other issue present in v3.5-rc5 not related to
> > my patches?
> >
> > Could you check with v3.5-rc5 if reverting patch c080e26edc3a2a3cdfa4c430c663ee1c3bbd8fae
> > and 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6 fixes the problems with rtl driver?
> >
> > Best regards
> Reverting the two patches indeed fixes the bug on -rc5.
That's really strange. Could you check if you have CMA disabled in the config? After preparing
a c080e26edc3a2a3cdfa4c430c663ee1c3bbd8fae fixup patch, I was really convinced that there are
no functional changes in x86 dma mapping code when CMA is disabled. I will provide some
patches to revert different parts of my changes, so we will find which line causes issues.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* Re: BISECTED: Re: REGRESSION: 3.4.0->3.5.0-rc2 kernel WARNING on cable plug on Acer Aspire One, no network
From: Alex Villacís Lasso @ 2012-07-05 4:14 UTC (permalink / raw)
To: Marek Szyprowski, Francois Romieu, netdev
In-Reply-To: <000901cd59b2$f2a542e0$d7efc8a0$%szyprowski@samsung.com>
El 04/07/12 02:02, Marek Szyprowski escribió:
> Hello,
>
> On Tuesday, July 03, 2012 4:27 PM Alex Villací¬s Lasso wrote:
>
>> El 03/07/12 00:40, Marek Szyprowski escribió:
>>> Hi Alex,
>>>
>>> On Tuesday, July 03, 2012 4:45 AM Alex Villacís Lasso wrote:
>>>
>>>> -------- Mensaje original --------
>>>> Asunto: BISECTED: Re: REGRESSION: 3.4.0->3.5.0-rc2 kernel WARNING on cable
>>>> plug on Acer Aspire One, no network Fecha: Mon, 02 Jul 2012 21:33:41 -0500 De:
>>>> Alex Villacís Lasso <a_villacis@palosanto.com> Para: Francois Romieu
>>>> <romieu@fr.zoreil.com> CC: netdev@vger.kernel.org
>>>> El 01/07/12 08:50, Alex Villacís Lasso escribió:
>>>>> El 11/06/12 16:38, Francois Romieu escribió:
>>>>>> Alex Villacís Lasso <a_villacis@palosanto.com> :
>>>>>> [...]
>>>>>>> $ grep XID dmesg-3.5.0-rc2.txt
>>>>>>> [ 15.873858] r8169 0000:02:00.0: eth0: RTL8102e at 0xf7c0e000,
>>>>>>> 00:1e:68:e5:5d:b1, XID 04a00000 IRQ 44
>>>>>> The 8102e has not been touched by that many suspect patches but I do
>>>>>> not see where the problem is :o(
>>>>>>
>>>>>> Can you peel off the r8169 patches between 3.4.0 and 3.5-rc ?
>>>>>>
>>>>> Still present in 3.5-rc5. Bisection still in progress.
>>>>>
>>>>> --
>>>>> 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
>>>> My full bisection points to this commit:
>>>>
>>>> commit 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6
>>>> Author: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Date: Thu Dec 29 13:09:51 2011 +0100
>>>>
>>>> X86: integrate CMA with DMA-mapping subsystem
>>>>
>>>> This patch adds support for CMA to dma-mapping subsystem for x86
>>>> architecture that uses common pci-dma/pci-nommu implementation. This
>>>> allows to test CMA on KVM/QEMU and a lot of common x86 boxes.
>>>>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>>>> CC: Michal Nazarewicz <mina86@mina86.com>
>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>
>>>> Is this commit somehow messing with the network card DMA?
>>> This commit in fact touches DMA-mapping subsystem and introduces a bug,
>>> which has been finally fixed by commit c080e26edc3a2a3 merged to v3.5-rc3.
>>> After applying it the DMA-mapping subsystem should work exactly the same was
>>> as in v3.4. Could you please check if it fixes this issue?
>>>
>>> Best regards
>> No. It still fails in 3.5-rc5, as mentioned before.
> Hmm. I was a bit confused, because both the subject and git bisect log pointed to v3.5-rc2,
> which had that bug. Maybe there is one some other issue present in v3.5-rc5 not related to
> my patches?
>
> Could you check with v3.5-rc5 if reverting patch c080e26edc3a2a3cdfa4c430c663ee1c3bbd8fae
> and 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6 fixes the problems with rtl driver?
>
> Best regards
Reverting the two patches indeed fixes the bug on -rc5.
^ permalink raw reply
* RE: [PATCH 1/2] be2net: Fix Endian
From: Somnath.Kotur @ 2012-07-05 4:00 UTC (permalink / raw)
To: roy.qing.li, netdev
In-Reply-To: <1341453942-4198-1-git-send-email-roy.qing.li@gmail.com>
> -----Original Message-----
> From: roy.qing.li@gmail.com [mailto:roy.qing.li@gmail.com]
> Sent: Thursday, July 05, 2012 7:36 AM
> To: netdev@vger.kernel.org
> Cc: Kotur, Somnath
> Subject: [PATCH 1/2] be2net: Fix Endian
>
> From: Li RongQing <roy.qing.li@gmail.com>
>
> ETH_P_IP is host Endian, skb->protocol is big Endian, when compare them,
> we should change ETH_P_IP from host endian to big endian, htons, not
> ntohs.
>
> CC: Somnath Kotur <somnath.kotur@emulex.com>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Oops! Unintended...Thanks!
Acked-by: Somnath Kotur <somnath.kotur@emulex.com>
^ permalink raw reply
* Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper
From: Joe Perches @ 2012-07-05 3:25 UTC (permalink / raw)
To: Andy Green
Cc: linux-omap, s-jan, arnd, patches, tony, netdev, linux-kernel,
rostedt, linux-arm-kernel
In-Reply-To: <4FF507FF.3000604@linaro.org>
On Thu, 2012-07-05 at 11:20 +0800, Andy Green wrote:
> On 05/07/12 11:12, the mail apparently from Joe Perches included:
[]
> >> diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
> > []
> >> +static int mac_platform_netdev_event(struct notifier_block *this,
> >> + unsigned long event, void *ptr)
> >
> > alignment to parenthesis please.
>
> OK. Although different places in the kernel seem to have different
> expectations about that.
net and drivers/net is pretty consistent.
Most of the exceptions are old code.
Some of those exceptions are being slowly updated too.
cheers, Joe
^ permalink raw reply
* Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper
From: Andy Green @ 2012-07-05 3:20 UTC (permalink / raw)
To: Joe Perches
Cc: linux-omap, s-jan, arnd, patches, tony, netdev, linux-kernel,
rostedt, linux-arm-kernel
In-Reply-To: <1341457963.2058.13.camel@joe2Laptop>
On 05/07/12 11:12, the mail apparently from Joe Perches included:
Thanks for the comments.
>> This introduces a small helper in net/ethernet, which registers a network
>> notifier at core_initcall time, and accepts registrations mapping expected
>> asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
>> and the MAC that is needed to be assigned to the device when it appears.
>
> The mac prefix is poor. I think eth_mac is better.
OK.
>> diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
> []
>> +static int mac_platform_netdev_event(struct notifier_block *this,
>> + unsigned long event, void *ptr)
>
> alignment to parenthesis please.
OK. Although different places in the kernel seem to have different
expectations about that.
>> +int mac_platform_register_device_macs(const struct mac_platform *macs)
>> +{
> []
>> + next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
>> + if (!next) {
>> + ret = -ENOMEM;
>> + goto bail;
>> + }
>> +
>> + next->device_path = kmalloc(strlen(macs->device_path) + 1,
>> + GFP_KERNEL);
>> + if (!next->device_path) {
>> + ret = -ENOMEM;
>> + goto bail;
>> + }
>> +
>> + strcpy(next->device_path, macs->device_path);
>> + memcpy(next->mac, macs->mac, sizeof macs->mac);
>
> kmemdup and kstrdup()
OK
>> + list_add(&next->list, &mac_platform_list);
>> +
>> + macs++;
>> + }
>> +
>> +bail:
>> + mutex_unlock(&mac_platform_mutex);
>> +
>> + return ret;
>> +}
>
> leaking memory on failures.
Right... I'll fix these and wait for more comments.
Thanks again for the review.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
^ permalink raw reply
* Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper
From: Joe Perches @ 2012-07-05 3:12 UTC (permalink / raw)
To: Andy Green
Cc: linux-omap, s-jan, arnd, patches, tony, netdev, linux-kernel,
rostedt, linux-arm-kernel
In-Reply-To: <20120705024446.26317.49693.stgit@build.warmcat.com>
On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
> From: Andy Green <andy@warmcat.com>
>
> This introduces a small helper in net/ethernet, which registers a network
> notifier at core_initcall time, and accepts registrations mapping expected
> asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
> and the MAC that is needed to be assigned to the device when it appears.
The mac prefix is poor. I think eth_mac is better.
[]
> diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
[]
> +static int mac_platform_netdev_event(struct notifier_block *this,
> + unsigned long event, void *ptr)
alignment to parenthesis please.
[]
> +int mac_platform_register_device_macs(const struct mac_platform *macs)
> +{
[]
> + next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
> + if (!next) {
> + ret = -ENOMEM;
> + goto bail;
> + }
> +
> + next->device_path = kmalloc(strlen(macs->device_path) + 1,
> + GFP_KERNEL);
> + if (!next->device_path) {
> + ret = -ENOMEM;
> + goto bail;
> + }
> +
> + strcpy(next->device_path, macs->device_path);
> + memcpy(next->mac, macs->mac, sizeof macs->mac);
kmemdup and kstrdup()
> + list_add(&next->list, &mac_platform_list);
> +
> + macs++;
> + }
> +
> +bail:
> + mutex_unlock(&mac_platform_mutex);
> +
> + return ret;
> +}
leaking memory on failures.
^ permalink raw reply
* [PATCH 4 4/4] config test config extending omap2plus with wl12xx etc
From: Andy Green @ 2012-07-05 2:45 UTC (permalink / raw)
To: linux-omap
Cc: s-jan, arnd, patches, tony, netdev, linux-kernel, rostedt,
linux-arm-kernel
In-Reply-To: <20120705024259.26317.16000.stgit@build.warmcat.com>
From: Andy Green <andy@warmcat.com>
This is just provided for testing convenience, it has enough config
options to get Ethernet and WL12xx driver on PandaBoard / ES up
You should be able to reproduce something like this, with different
MAC addresses.
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 2e:20:3c:ea:46:01
inet addr:10.42.0.98 Bcast:10.42.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1647 (1.6 KB) TX bytes:5534 (5.5 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:100 (100.0 B) TX bytes:100 (100.0 B)
wlan0 Link encap:Ethernet HWaddr 2e:60:3c:ea:46:01
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Signed-off-by: Andy Green <andy.green@linaro.org>
---
arch/arm/configs/omap2plus_defconfig | 35 ++++++++++++++--------------------
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index f3087cb..7dcd384 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -2,13 +2,13 @@ CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_BLK_DEV_INITRD=y
CONFIG_EXPERT=y
-# CONFIG_SYSCTL_SYSCALL is not set
-CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_SLAB=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
@@ -20,13 +20,12 @@ CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
CONFIG_ARCH_OMAP=y
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_ERRATA_411920=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_LEDS=y
@@ -60,6 +59,7 @@ CONFIG_BT_HCIUART_LL=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_CFG80211=m
+CONFIG_LIB80211=m
CONFIG_MAC80211=m
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
@@ -87,22 +87,20 @@ CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_MD=y
CONFIG_NETDEVICES=y
-CONFIG_SMSC_PHY=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMC91X=y
-CONFIG_SMSC911X=y
CONFIG_KS8851=y
CONFIG_KS8851_MLL=y
-CONFIG_LIBERTAS=m
-CONFIG_LIBERTAS_USB=m
-CONFIG_LIBERTAS_SDIO=m
-CONFIG_LIBERTAS_DEBUG=y
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+CONFIG_SMSC_PHY=y
CONFIG_USB_USBNET=y
CONFIG_USB_NET_SMSC95XX=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
+CONFIG_WL_TI=y
+CONFIG_WL12XX=m
+CONFIG_WLCORE_SDIO=m
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_GPIO=y
@@ -131,14 +129,14 @@ CONFIG_POWER_SUPPLY=y
CONFIG_WATCHDOG=y
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
-CONFIG_REGULATOR_TWL4030=y
+CONFIG_MFD_WL1273_CORE=y
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
+CONFIG_REGULATOR_TWL4030=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_OMAP_LCD_VGA=y
CONFIG_OMAP2_DSS=m
CONFIG_OMAP2_DSS_RFBI=y
CONFIG_OMAP2_DSS_SDI=y
@@ -153,7 +151,6 @@ CONFIG_PANEL_ACX565AKM=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
-CONFIG_DISPLAY_SUPPORT=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
@@ -173,7 +170,6 @@ CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
-CONFIG_USB_DEVICEFS=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_MON=y
CONFIG_USB_EHCI_HCD=y
@@ -212,23 +208,20 @@ CONFIG_JFFS2_RUBIN=y
CONFIG_UBIFS_FS=y
CONFIG_CRAMFS=y
CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_PROVE_LOCKING=y
-CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
CONFIG_SECURITY=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
^ permalink raw reply related
* [PATCH 4 3/4] OMAP4 PANDA register ethernet and wlan for automatic mac allocation
From: Andy Green @ 2012-07-05 2:44 UTC (permalink / raw)
To: linux-omap
Cc: s-jan, arnd, patches, tony, netdev, linux-kernel, rostedt,
linux-arm-kernel
In-Reply-To: <20120705024259.26317.16000.stgit@build.warmcat.com>
From: Andy Green <andy@warmcat.com>
This provides the board-specific device paths needed to get
the panda boardfile working with the mac-platform api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding randomized MAC per-boot and consequent DHCP problems,
or in the case of wlan0 a MAC set by a firmware file in the rootfs
which unless customized yields a MAC of 00:00:00:00:00:00. No
official MAC is reserved for either network device even if you do
take the approach to customize the firmware file.
This gets sane, consistent MAC addresses on both devices which
should stand a good probability of differing between PandaBoards.
Signed-off-by: Andy Green <andy.green@linaro.org>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/board-omap4panda.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 83fb31c..06fadf4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -358,6 +358,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select MAC_PLATFORM
config MACH_PCM049
bool "OMAP4 based phyCORE OMAP4"
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..b028141 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -32,7 +32,10 @@
#include <linux/wl12xx.h>
#include <linux/platform_data/omap-abe-twl6040.h>
+#include <net/mac-platform.h>
+
#include <mach/hardware.h>
+#include <mach/id.h>
#include <asm/hardware/gic.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -486,16 +489,43 @@ static void omap4_panda_init_rev(void)
}
}
+/*
+ * These device paths represent onboard network devices which have
+ * no MAC address set at boot, and need synthetic ones assigning
+ */
+static __initdata struct mac_platform panda_mac_platform[] = {
+
+ { /* smsc USB <-> Ethernet bridge */
+ .device_path = "usb1/1-1/1-1.1/1-1.1:1.0",
+ },
+ { /* wlan0 module */
+ .device_path = "wl12xx",
+ },
+ { /* terminator */
+ }
+};
+
static void __init omap4_panda_init(void)
{
int package = OMAP_PACKAGE_CBS;
int ret;
+ int n;
if (omap_rev() == OMAP4430_REV_ES1_0)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, NULL, package);
omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+ /*
+ * provide MAC addresses computed from device ID for network
+ * devices that have no MAC address otherwise on Panda
+ */
+ for (n = 0; n < ARRAY_SIZE(panda_mac_platform) - 1; n++)
+ omap_die_id_to_ethernet_mac(panda_mac_platform[n].mac, n);
+ if (mac_platform_register_device_macs(panda_mac_platform))
+ pr_err("Unable to register mac_platform devices\n");
+
ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
if (ret)
pr_err("error setting wl12xx data: %d\n", ret);
^ permalink raw reply related
* [PATCH 4 2/4] NET ethernet introduce mac_platform helper
From: Andy Green @ 2012-07-05 2:44 UTC (permalink / raw)
To: linux-omap
Cc: s-jan, arnd, patches, tony, netdev, linux-kernel, rostedt,
linux-arm-kernel
In-Reply-To: <20120705024259.26317.16000.stgit@build.warmcat.com>
From: Andy Green <andy@warmcat.com>
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
and the MAC that is needed to be assigned to the device when it appears.
This allows platform code to enforce valid, consistent MAC addresses on to
devices that have not been probed at boot-time, but due to being wired on the
board are always present at the same interface. It has been tested with USB
and SDIO probed devices.
Other parts of this series provide an OMAP API that computes a valid
locally administered MAC address from CPU ID bits that are unique for each
physical SoC, and register those against devices wired to the board.
This solves a longstanding problem in at least Panda case that there are no
reserved MACs for either onboard Ethernet nor onboard WLAN module, and without
this patch a randomized MAC is assigned to Ethernet and 00:00:00:00:00:00 or
0xdeadbeef is assigned as the WLAN MAC address. The series provides sane,
constant locally-administered MAC addresses that have a high probability of
differing between boards.
To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.
At registration it makes a copy of the incoming data, so the data may be
__initdata or otherwise transitory. Registration can be called multiple times
so registrations from Device Tree and platform may be mixed.
Since it needs to be called quite early in boot and there is no lifecycle for
what it does, it could not be modular and is not a driver.
Via suggestions from Arnd Bergmann and Tony Lindgren (and Alan Cox for the
network notifier concept).
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andy Green <andy.green@linaro.org>
---
include/net/mac-platform.h | 39 +++++++++++
net/Kconfig | 5 +
net/ethernet/Makefile | 3 +
net/ethernet/mac-platform.c | 151 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 197 insertions(+), 1 deletion(-)
create mode 100644 include/net/mac-platform.h
create mode 100644 net/ethernet/mac-platform.c
diff --git a/include/net/mac-platform.h b/include/net/mac-platform.h
new file mode 100644
index 0000000..3a59098
--- /dev/null
+++ b/include/net/mac-platform.h
@@ -0,0 +1,39 @@
+/*
+ * mac-platform.h: Enforces platform-defined MAC for Async probed devices
+ */
+
+#ifndef __NET_MAC_PLATFORM_H__
+#define __NET_MAC_PLATFORM_H__
+
+#include <linux/if_ether.h>
+
+/**
+ * struct mac_platform - associates asynchronously probed device path with
+ * MAC address to be assigned to the device when it
+ * is created
+ *
+ * @device_path: device path name of network device
+ * @mac: MAC address to assign to network device matching device path
+ * @list: can be left uninitialized when passing from platform
+ */
+
+struct mac_platform {
+ char *device_path;
+ u8 mac[ETH_ALEN];
+ struct list_head list; /* unused in platform data usage */
+};
+
+#ifdef CONFIG_NET
+/**
+ * mac_platform_register_device_macs - add an array of device path to monitor
+ * and MAC to apply when the network device
+ * at the device path appears
+ * @macs: array of struct mac_platform terminated by entry with
+ * NULL device_path
+ */
+int mac_platform_register_device_macs(const struct mac_platform *macs);
+#else
+static inline int mac_platform_register_device_macs(macs) { return 0; }
+#endif /* !CONFIG_NET */
+
+#endif /* __NET_MAC_PLATFORM_H__ */
diff --git a/net/Kconfig b/net/Kconfig
index 245831b..487c9e6 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -335,9 +335,12 @@ source "net/caif/Kconfig"
source "net/ceph/Kconfig"
source "net/nfc/Kconfig"
-
endif # if NET
+# used by board / dt platform to enforce MACs for Async-probed devices
+config MAC_PLATFORM
+ bool
+
# Used by archs to tell that they support BPF_JIT
config HAVE_BPF_JIT
bool
diff --git a/net/ethernet/Makefile b/net/ethernet/Makefile
index 7cef1d8..475db2b 100644
--- a/net/ethernet/Makefile
+++ b/net/ethernet/Makefile
@@ -5,3 +5,6 @@
obj-y += eth.o
obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
obj-$(subst m,y,$(CONFIG_ATALK)) += pe2.o
+ifneq ($(CONFIG_NET),)
+obj-$(CONFIG_MAC_PLATFORM) += mac-platform.o
+endif
diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
new file mode 100644
index 0000000..88e50ce
--- /dev/null
+++ b/net/ethernet/mac-platform.c
@@ -0,0 +1,151 @@
+/*
+ * Helper to allow platform code to enforce association of a locally-
+ * administered MAC address automatically on asynchronously probed devices,
+ * such as SDIO and USB based devices.
+ *
+ * Because the "device path" is used for matching, this is only useful for
+ * network assets physcally wired on the board, and also requires any
+ * different drivers that can compete for bus ordinals (eg mUSB vs ehci) to
+ * have fixed initialization ordering, eg, by having ehci in monolithic
+ * kernel
+ *
+ * Neither a driver nor a module as needs to be callable from machine file
+ * before the network devices are registered.
+ *
+ * (c) 2012 Andy Green <andy.green@linaro.org>
+ */
+
+#include <linux/netdevice.h>
+#include <net/mac-platform.h>
+
+static LIST_HEAD(mac_platform_list);
+static DEFINE_MUTEX(mac_platform_mutex);
+
+static struct mac_platform *__mac_platform_check(struct device *dev)
+{
+ const char *path;
+ const char *p;
+ const char *try;
+ int len;
+ struct device *devn;
+ struct mac_platform *tmp;
+ struct list_head *pos;
+
+ list_for_each(pos, &mac_platform_list) {
+
+ tmp = list_entry(pos, struct mac_platform, list);
+
+ try = tmp->device_path;
+
+ p = try + strlen(try);
+ devn = dev;
+
+ while (devn) {
+
+ path = dev_name(devn);
+ len = strlen(path);
+
+ if ((p - try) < len) {
+ devn = NULL;
+ continue;
+ }
+
+ p -= len;
+
+ if (strncmp(path, p, len)) {
+ devn = NULL;
+ continue;
+ }
+
+ devn = devn->parent;
+ if (p == try)
+ return tmp;
+
+ if (devn != NULL && (p - try) < 2)
+ devn = NULL;
+
+ p--;
+ if (devn != NULL && *p != '/')
+ devn = NULL;
+ }
+ }
+
+ return NULL;
+}
+
+static int mac_platform_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ struct net_device *dev = ptr;
+ struct sockaddr sa;
+ struct mac_platform *match;
+
+ if (event != NETDEV_REGISTER)
+ return NOTIFY_DONE;
+
+ mutex_lock(&mac_platform_mutex);
+
+ match = __mac_platform_check(dev->dev.parent);
+ if (match == NULL)
+ goto bail;
+
+ sa.sa_family = dev->type;
+ memcpy(sa.sa_data, match->mac, sizeof match->mac);
+ dev->netdev_ops->ndo_set_mac_address(dev, &sa);
+
+bail:
+ mutex_unlock(&mac_platform_mutex);
+
+ return NOTIFY_DONE;
+}
+
+int mac_platform_register_device_macs(const struct mac_platform *macs)
+{
+ struct mac_platform *next;
+ int ret = 0;
+
+ mutex_lock(&mac_platform_mutex);
+
+ while (macs->device_path) {
+
+ next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
+ if (!next) {
+ ret = -ENOMEM;
+ goto bail;
+ }
+
+ next->device_path = kmalloc(strlen(macs->device_path) + 1,
+ GFP_KERNEL);
+ if (!next->device_path) {
+ ret = -ENOMEM;
+ goto bail;
+ }
+
+ strcpy(next->device_path, macs->device_path);
+ memcpy(next->mac, macs->mac, sizeof macs->mac);
+ list_add(&next->list, &mac_platform_list);
+
+ macs++;
+ }
+
+bail:
+ mutex_unlock(&mac_platform_mutex);
+
+ return ret;
+}
+
+static struct notifier_block mac_platform_netdev_notifier = {
+ .notifier_call = mac_platform_netdev_event,
+ .priority = 1,
+};
+
+static int __init mac_platform_init(void)
+{
+ int ret = register_netdevice_notifier(&mac_platform_netdev_notifier);
+ if (ret)
+ pr_err("mac_platform_init: Notifier registration failed\n");
+
+ return ret;
+}
+
+core_initcall(mac_platform_init);
^ permalink raw reply related
* [PATCH 4 1/4] OMAP: add cpu id register to MAC address helper
From: Andy Green @ 2012-07-05 2:44 UTC (permalink / raw)
To: linux-omap
Cc: s-jan, arnd, patches, tony, netdev, linux-kernel, rostedt,
linux-arm-kernel
In-Reply-To: <20120705024259.26317.16000.stgit@build.warmcat.com>
From: Andy Green <andy@warmcat.com>
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:20:3c:ea:46:01
for the ethernet device on my PandaBoard ES.
The MAC address space has space set aside for these kind of "locally
administered" MAC addresses, analogous to IPv4 10.x.x.x range, and this
patch marks the generated MAC addresses as such.
The patch leaves two bits allowing elaborating 4 different MACs from the
generated data.
Signed-off-by: Andy Green <andy.green@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
---
arch/arm/mach-omap2/id.c | 39 +++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/include/mach/id.h | 1 +
2 files changed, 40 insertions(+)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37eb95a..3ab5d4d 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -530,3 +530,42 @@ void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)
else
tap_prod_id = 0x0208;
}
+
+/*
+ * this uses the unique per-cpu info from the cpu fuses set at factory to
+ * generate a 6-byte MAC address. Two bits in the generated code are used
+ * to elaborate the generated address into four, so it can be used on multiple
+ * network interfaces.
+ */
+
+void omap_die_id_to_ethernet_mac(u8 *mac, int subtype)
+{
+ struct omap_die_id odi;
+ u32 tap = read_tap_reg(OMAP_TAP_IDCODE);
+
+ omap_get_die_id(&odi);
+
+ mac[0] = odi.id_2;
+ mac[1] = odi.id_2 >> 8;
+ mac[2] = odi.id_1;
+ mac[3] = odi.id_1 >> 8;
+ mac[4] = odi.id_1 >> 16;
+ mac[5] = odi.id_1 >> 24;
+
+ /* XOR other chip-specific data with ID */
+
+ tap ^= odi.id_3;
+
+ mac[0] ^= tap;
+ mac[1] ^= tap >> 8;
+ mac[2] ^= tap >> 16;
+ mac[3] ^= tap >> 24;
+
+ /* allow four MACs from this same basic data */
+
+ mac[1] = (mac[1] & ~0xc0) | ((subtype & 3) << 6);
+
+ /* mark it as not multicast, and outside official 80211 MAC namespace */
+
+ mac[0] = (mac[0] & ~1) | 2;
+}
diff --git a/arch/arm/mach-omap2/include/mach/id.h b/arch/arm/mach-omap2/include/mach/id.h
index 02ed3aa..d6c8d63 100644
--- a/arch/arm/mach-omap2/include/mach/id.h
+++ b/arch/arm/mach-omap2/include/mach/id.h
@@ -18,5 +18,6 @@ struct omap_die_id {
};
void omap_get_die_id(struct omap_die_id *odi);
+void omap_die_id_to_ethernet_mac(u8 *mac, int subtype);
#endif
^ permalink raw reply related
* [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
From: Andy Green @ 2012-07-05 2:44 UTC (permalink / raw)
To: linux-omap
Cc: s-jan, arnd, patches, tony, netdev, linux-kernel, rostedt,
linux-arm-kernel
The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
net/ethernet taking care of accepting device path / MAC mapping registrations
and running a notifier to enforce the requested MAC when the matching network
device turns up.
On PandaBoard / ES, two devices have no board-level MAC either assigned by
the manufacturer or stored on the board, the last patch in the series adds
these device paths and gets them set when the network device is registered.
Lastly for convenient testing, there's a little patch on omap2plus_defconfig
that will get Ethernet and WLAN up on Pandaboard.
The patches are against today's linux-omap.
Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
helper in net/ethernet.
---
Andy Green (4):
OMAP: add cpu id register to MAC address helper
NET ethernet introduce mac_platform helper
OMAP4 PANDA register ethernet and wlan for automatic mac allocation
config test config extending omap2plus with wl12xx etc
arch/arm/configs/omap2plus_defconfig | 35 +++----
arch/arm/mach-omap2/Kconfig | 1
arch/arm/mach-omap2/board-omap4panda.c | 30 ++++++
arch/arm/mach-omap2/id.c | 39 ++++++++
arch/arm/mach-omap2/include/mach/id.h | 1
include/net/mac-platform.h | 39 ++++++++
net/Kconfig | 5 +
net/ethernet/Makefile | 3 +
net/ethernet/mac-platform.c | 151 ++++++++++++++++++++++++++++++++
9 files changed, 282 insertions(+), 22 deletions(-)
create mode 100644 include/net/mac-platform.h
create mode 100644 net/ethernet/mac-platform.c
^ permalink raw reply
* [PATCH net 3/7] qlge: Garbage values shown in extra info during selftest.
From: Jitendra Kalsaria @ 2012-07-02 23:41 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, Dept_NX_Linux_NIC_Driver, Jitendra Kalsaria
In-Reply-To: <1341272514-5156-1-git-send-email-jitendra.kalsaria@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
while running selftest 'ethtool -t' multiple times will get
different values in the 'extra info' section, which was garbage.
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
---
drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c b/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
index 98f04d7..31ee6dc 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
@@ -248,6 +248,9 @@ static char ql_stats_str_arr[][ETH_GSTRING_LEN] = {
static void ql_get_strings(struct net_device *dev, u32 stringset, u8 *buf)
{
switch (stringset) {
+ case ETH_SS_TEST:
+ memcpy(buf, *ql_gstrings_test, QLGE_TEST_LEN * ETH_GSTRING_LEN);
+ break;
case ETH_SS_STATS:
memcpy(buf, ql_stats_str_arr, sizeof(ql_stats_str_arr));
break;
@@ -538,6 +541,8 @@ static void ql_self_test(struct net_device *ndev,
{
struct ql_adapter *qdev = netdev_priv(ndev);
+ memset(data, 0, sizeof(u64) * QLGE_TEST_LEN);
+
if (netif_running(ndev)) {
set_bit(QL_SELFTEST, &qdev->flags);
if (eth_test->flags == ETH_TEST_FL_OFFLINE) {
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] ksz884x: fix Endian
From: roy.qing.li @ 2012-07-05 2:06 UTC (permalink / raw)
To: netdev; +Cc: Tristram.Ha
From: Li RongQing <roy.qing.li@gmail.com>
ETH_P_IP is host Endian, skb->protocol is big Endian, when
compare them, we should change skb->protocol from big endian
to host endian, ntohs, not htons.
CC: Tristram Ha <Tristram.Ha@micrel.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
drivers/net/ethernet/micrel/ksz884x.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ksz884x.c b/drivers/net/ethernet/micrel/ksz884x.c
index eaf9ff0..d9727f7 100644
--- a/drivers/net/ethernet/micrel/ksz884x.c
+++ b/drivers/net/ethernet/micrel/ksz884x.c
@@ -4882,7 +4882,7 @@ static netdev_tx_t netdev_tx(struct sk_buff *skb, struct net_device *dev)
if (left) {
if (left < num ||
((CHECKSUM_PARTIAL == skb->ip_summed) &&
- (ETH_P_IPV6 == htons(skb->protocol)))) {
+ (ETH_P_IPV6 == ntohs(skb->protocol)))) {
struct sk_buff *org_skb = skb;
skb = netdev_alloc_skb(dev, org_skb->len);
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] be2net: Fix Endian
From: roy.qing.li @ 2012-07-05 2:05 UTC (permalink / raw)
To: netdev; +Cc: somnath.kotur
From: Li RongQing <roy.qing.li@gmail.com>
ETH_P_IP is host Endian, skb->protocol is big Endian, when
compare them, we should change ETH_P_IP from host endian
to big endian, htons, not ntohs.
CC: Somnath Kotur <somnath.kotur@emulex.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
drivers/net/ethernet/emulex/benet/be.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 7a71fb6..0490a04 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -575,7 +575,7 @@ static inline u8 is_udp_pkt(struct sk_buff *skb)
static inline bool is_ipv4_pkt(struct sk_buff *skb)
{
- return skb->protocol == ntohs(ETH_P_IP) && ip_hdr(skb)->version == 4;
+ return skb->protocol == htons(ETH_P_IP) && ip_hdr(skb)->version == 4;
}
static inline void be_vf_eth_addr_generate(struct be_adapter *adapter, u8 *mac)
--
1.7.1
^ permalink raw reply related
* TCP transmit performance regression
From: Ming Lei @ 2012-07-05 1:45 UTC (permalink / raw)
To: Network Development, David Miller
Hi,
I observed that on both 3.5-rc5 and 3.5-rc5-next, TCP transmit performance
degrades a lot, see my below simple test:
1, test box
NIC: 100M USB, normally can reach > 90Mbits/sec
2, run below command on the box:
[root@root]#iperf -c 192.168.0.103 -w 131072 -t 10
------------------------------------------------------------
Client connecting to 192.168.0.103, TCP port 5001
TCP window size: 256 KByte (WARNING: requested 128 KByte)
------------------------------------------------------------
[ 3] local 192.168.0.108 port 59315 connected with 192.168.0.103 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 40.4 MBytes 33.9 Mbits/sec
note: 192.168.0.103 is another production machine running 'iperf -s -w 131072'
3, from traffic captured in wireshark, the window size of most of tcp packets
from the test box to 192.168.0.103 is set as 229, looks very weird and should
be the cause of performance regression.
4, TCP receive performance is OK.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] r8169: support RTL8168G
From: Joe Perches @ 2012-07-05 0:51 UTC (permalink / raw)
To: Francois Romieu; +Cc: Hayes Wang, netdev, linux-kernel
In-Reply-To: <20120704220458.GA1621@electric-eye.fr.zoreil.com>
On Thu, 2012-07-05 at 00:04 +0200, Francois Romieu wrote:
> Hayes Wang <hayeswang@realtek.com> :
> > Support the new chip RTL8168G.
> - save Joe P. some work
Thanks. Just a trivial thing below:
[]
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
[]
> +#define RTL_LOOP_MAX 10000
> +
> +static void rtl_mcu_wait_list_ready(void __iomem *ioaddr)
> +{
> + int i;
> +
> + for (i = 0; i < RTL_LOOP_MAX; i++) {
> + if (RTL_R8(MCU) & LINK_LIST_RDY)
> + return;
> + udelay(100);
> + }
> +}
This pattern is used a couple more times.
There's no failure handling either.
Maybe use a macro with RTL_R8/32, register and test?
Maybe the delays could be tuned out a bit better.
Maybe a continuous read or a less frequent read
might be better.
> static void __devinit rtl_hw_init_8168g(struct rtl8169_private *tp)
> {
[]
> + for (i = 0; i < RTL_LOOP_MAX; i++) {
> + if (RTL_R32(TxConfig) & TXCFG_EMPTY)
> + break;
> udelay(100);
> + }
pattern
> + for (i = 0; i < RTL_LOOP_MAX; i++) {
> + if ((RTL_R8(MCU) & RXTX_EMPTY) == RXTX_EMPTY)
> + break;
> udelay(100);
> + }
pattern
^ 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