* (unknown),
From: Людмила @ 2011-06-14 14:12 UTC (permalink / raw)
ищу партнера для секса
http://4p5.com/244c
^ permalink raw reply
* RE: [PATCH] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: Vladislav Zolotarov @ 2011-06-15 11:57 UTC (permalink / raw)
To: David Woodhouse, Dave Miller; +Cc: Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <alpine.LFD.2.02.1106151138390.8326@localhost6.localdomain6>
>
> > I've sent it to u once again a minute ago.
> > If for any reason u don't get it, the patch is avaliable at
> > http://linux.broadcom.com/eilong/FW-7.0.20.0/
>
> Still didn't seem to get it; fetched patch from HTTP server and
> applied.
I pulled the linux-firmware git and saw the FW files.
Thanks a lot, David.
Dave, what do u want me to do now: do u want me to resend the series?
Thanks,
vlad
>
> --
> dwmw2
>
> --
> 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: [RFC][PATCH] add tracepoint to __sk_mem_schedule
From: Neil Horman @ 2011-06-15 11:07 UTC (permalink / raw)
To: Satoru Moriya
Cc: netdev@vger.kernel.org, davem@davemloft.net,
dle-develop@lists.sourceforge.net, Seiji Aguchi
In-Reply-To: <65795E11DBF1E645A09CEC7EAEE94B9C3FBC0707@USINDEVS02.corp.hds.com>
On Tue, Jun 14, 2011 at 03:24:14PM -0400, Satoru Moriya wrote:
> Hi,
>
> kernel drops packets when the amount of memory which is used for socket buffer
> exceeds limitations such as /proc/sys/net/ipv4/udp_mem. But currently we can't
> catch that event and know why packets are dropped. And also it is difficult to
> configure sysctl knob appropriately because we don't know when/why packets
> dropped.
>
There are several ways to do this already. Every drop that occurs in the stack
should have a corresponding statistical counter exposed for it, and we also have
a tracepoint in kfree_skb that the dropwatch system monitors to inform us of
dropped packets in a certralized fashion. Not saying this tracepoint isn't
worthwhile, only that it covers already covered ground.
> This patch adds tracepoint to __sk_mem_schedule(), which is called each time
> the socket memory usage exceeds limitations and kernel drops a packet.
> It allows us to hook in and examine when and why it happens.
>
> Note that this patch only collects information which is needed for udp
> because it's a RFC patch to show its concept and acutually we need it(*).
> If you guys need to get other parameters, please let me know. I'll add it.
>
> (*) Reason why we need this tracepoint for UDP
> Transaction data is sent by UDP multicast in finance systems because of its
> low overhead characteristics. UDP itself does not guarantee reliability,
> ordering and data integrity, but the system is designed not to drop any packets
> even when it is high load situation. And in that system if kernel drops packets,
> we need to find a root cause to avoid it next time.
>
Again, this is why dropwatch exists. UDP gets into this path from:
__udp_queue_rcv_skb
ip_queue_rcv_skb
sock_queue_rcv_skb
sk_rmem_schedule
__sk_mem_schedule
If ip_queue_rcv_skb fails we increment the UDP_MIB_RCVBUFERRORS counter as well
as the UDP_MIB_INERRORS counter, and on the kfree_skb call after those
increments, dropwatch will report the frame loss and the fact that it occured in
__udp_queue_rcv_skb
I still think its an interesting tracepoint, just because it might be nice to
know which sockets are expanding their snd/rcv buffer space, but why not modify
the tracepoint so that it accepts the return code of __sk_mem_schedule and call
it from both sk_rmem_schedule and sk_wmem_schedule. That way you can use the
tracepoint to record both successfull expansion and failed expansions.
Neil
> Any comments are welcome.
>
> Signed-off-by: Satoru Moriya <satoru.moriya@hds.com>
> ---
> include/trace/events/sock.h | 46 +++++++++++++++++++++++++++++++++++++++++++
> net/core/net-traces.c | 1 +
> net/core/sock.c | 4 +++
> 3 files changed, 51 insertions(+), 0 deletions(-)
> create mode 100644 include/trace/events/sock.h
>
> diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
> new file mode 100644
> index 0000000..409735a
> --- /dev/null
> +++ b/include/trace/events/sock.h
> @@ -0,0 +1,46 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM sock
> +
> +#if !defined(_TRACE_SOCK_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_SOCK_H
> +
> +#include <net/sock.h>
> +#include <linux/tracepoint.h>
> +
> +TRACE_EVENT(sock_exceed_buf_limit,
> +
> + TP_PROTO(struct sock *sk, struct proto *prot, long allocated),
> +
> + TP_ARGS(sk, prot, allocated),
> +
> + TP_STRUCT__entry(
> + __array(char, name, 32)
> + __field(long *, sysctl_mem)
> + __field(long, allocated)
> + __field(int, sysctl_rmem)
> + __field(int, rmem_alloc)
> + ),
> +
> + TP_fast_assign(
> + strncpy(__entry->name, prot->name, 32);
> + __entry->sysctl_mem = prot->sysctl_mem;
> + __entry->allocated = allocated;
> + __entry->sysctl_rmem = atomic_read(&sk->sk_rmem_alloc);
> + __entry->rmem_alloc = prot->sysctl_rmem[0];
> + ),
> +
> + TP_printk("proto:%s sysctl_mem=%ld,%ld,%ld allocated=%ld "
> + "sysctl_rmem=%d rmem_alloc=%d",
> + __entry->name,
> + __entry->sysctl_mem[0],
> + __entry->sysctl_mem[1],
> + __entry->sysctl_mem[2],
> + __entry->allocated,
> + __entry->sysctl_rmem,
> + __entry->rmem_alloc)
> +);
> +
> +#endif /* _TRACE_SOCK_H */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
> diff --git a/net/core/net-traces.c b/net/core/net-traces.c
> index 7f1bb2a..b9756f5 100644
> --- a/net/core/net-traces.c
> +++ b/net/core/net-traces.c
> @@ -28,6 +28,7 @@
> #include <trace/events/skb.h>
> #include <trace/events/net.h>
> #include <trace/events/napi.h>
> +#include <trace/events/sock.h>
>
> EXPORT_TRACEPOINT_SYMBOL_GPL(kfree_skb);
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 6e81978..8389032 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -128,6 +128,8 @@
>
> #include <linux/filter.h>
>
> +#include <trace/events/sock.h>
> +
> #ifdef CONFIG_INET
> #include <net/tcp.h>
> #endif
> @@ -1736,6 +1738,8 @@ suppress_allocation:
> return 1;
> }
>
> + trace_sock_exceed_buf_limit(sk, prot, allocated);
> +
> /* Alas. Undo changes. */
> sk->sk_forward_alloc -= amt * SK_MEM_QUANTUM;
> atomic_long_sub(amt, prot->memory_allocated);
> --
> 1.7.1
> --
> 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] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: David Woodhouse @ 2011-06-15 10:58 UTC (permalink / raw)
To: Vlad Zolotarov; +Cc: Dave Miller, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <201106151308.23789.vladz@broadcom.com>
On Wed, 15 Jun 2011, Vlad Zolotarov wrote:
> I've sent it to u once again a minute ago.
> If for any reason u don't get it, the patch is avaliable at
> http://linux.broadcom.com/eilong/FW-7.0.20.0/
Still didn't seem to get it; fetched patch from HTTP server and applied.
--
dwmw2
^ permalink raw reply
* Re: No traffic flow with Marvell 88E6095F using DSA
From: Lennert Buytenhek @ 2011-06-15 10:33 UTC (permalink / raw)
To: Barry G; +Cc: netdev
In-Reply-To: <BANLkTi=SLBskJu1BuXJzocabpwi8tURwDw@mail.gmail.com>
On Fri, Jun 10, 2011 at 09:52:08AM -0700, Barry G wrote:
> Hello all,
Hello,
> We are trying to bring up a board with two Marvell 88E6095F chips and
> one 88E6185 chip using the Distributed Switch Architecture (DSA)
> facilities in the kernel.
>
> We have a rough driver working, but we can't get traffic to flow in
> or out of the Marvell chips.
>
> To simplify the system, I am trying to bring up only the chip
> attached to the CPU (88E6095F). I have a dsa_chip_data with
> static struct dsa_chip_data switches[] = {
> {
> .sw_addr = 0x9,
> .port_names = {
> "eth%d", //0
> "eth%d", //1
> "eth%d", //2
> "eth%d", //3
> "eth%d", //4
> "eth%d", //5
> "eth%d", //6
> "eth%d", //7
> NULL, //8
> NULL, //9
> "cpu", //10
> },
> }
> };
>
> port 8 and 9 are DSA interfaces to other chips.
>
> The host CPU is an Freescale 8308 hooked up to TSEC1.
> We are using the mdio bus from the processor to drive
> the mdio on the Marells.
>
> Using this configuration with the driver shell I posted
> previously the system boots and I see:
> Distributed Switch Architecture driver version 0.1
> eth0[0]: detected a Marvell 88E6095/88E6095F switch
> dsa slave smi: probed
So far so good.
> All good. If I run ip link show I get:
> # ip link show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:30:a7:aa:aa:01 brd ff:ff:ff:ff:ff:ff
> 4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:30:a7:aa:aa:02 brd ff:ff:ff:ff:ff:ff
> 5: teql0: <NOARP> mtu 1500 qdisc noop qlen 100
> link/void
> 6: tunl0: <NOARP> mtu 1480 qdisc noop
> link/ipip 0.0.0.0 brd 0.0.0.0
> 7: eth2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> link/ether 00:30:a7:aa:aa:01 brd ff:ff:ff:ff:ff:ff
> 8: eth3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> link/ether 00:30:a7:aa:aa:01 brd ff:ff:ff:ff:ff:ff
> 9: eth4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> link/ether 00:30:a7:aa:aa:01 brd ff:ff:ff:ff:ff:ff
> 10: eth5@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> link/ether 00:30:a7:aa:aa:01 brd ff:ff:ff:ff:ff:ff
> 11: eth6@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> link/ether 00:30:a7:aa:aa:01 brd ff:ff:ff:ff:ff:ff
> 12: eth7@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> link/ether 00:30:a7:aa:aa:01 brd ff:ff:ff:ff:ff:ff
> 13: eth8@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> link/ether 00:30:a7:aa:aa:01 brd ff:ff:ff:ff:ff:ff
> 14: eth9@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> link/ether 00:30:a7:aa:aa:01 brd ff:ff:ff:ff:ff:ff
This looks good also.
> This is after running "ip link set dev eth0 up" and "ip link set dev eth9 up"
>
> Eth9 is hooked up to a cable. Removing the cable results in the
> "eth9: link down" message and plugging it back in gives the "eth9:
> link up, 100 Mb/s, half duplex, flow control disabled".
half duplex, is that correct?
> So it looks like everything is stellar, but we can't get traffic
> to leave the device. I configure eth9 with an address (192.168.1.50/24)
> and I try to ping 192.168.1.25 I get the following with tcpdump on eth9:
> 20:23:11.682628 arp who-has 192.168.1.25 tell 192.168.1.50 (repeats)
>
> And on eth0 I see:
> 20:23:54.692701 00:30:a7:aa:aa:01 (oui Unknown) > Broadcast, ethertype
> Unknown (0x4038), length 46:
> 0x0000: 0000 0806 0001 0800 0604 0001 0030 a7aa .............0..
> 0x0010: aa01 c0a8 0132 0000 0000 0000 c0a8 0119 .....2..........
>
>
> However if I hook up to the port with wireshark I see nothing leaving
> the port. Likewise if I attempt to ping into the device from 192.168.1.25
> I see nothing coming in on the tcpdump for eth0 or eth9.
As far as I can see from the dump below, the packets _are_ making it
out of eth0. Some things to try would be to check the switch chip's
port stats to make sure that the packets are really received on its CPU
interface, and then to just basically check all of the switch chip's
address/vlan/etc table registers to see where it's routing the packets
to. I assume you have docs for the switch chip?
thanks,
Lennert
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: Lennert Buytenhek @ 2011-06-15 10:21 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: Mika Westerberg, ynezz@true.cz, netdev@vger.kernel.org,
ryan@bluewatersys.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <ADE657CA350FB648AAC2C43247A983F001F381FC56CE@AUSP01VMBX24.collaborationhost.net>
On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
> Lennert,
Hi,
> You are listed as the maintainer for these EP93xx related pieces:
>
> ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
> CIRRUS LOGIC EP93XX ETHERNET DRIVER
> CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER
>
> I can take over the edb9315a with no problem. It actually falls under
> arch/arm/mach-ep93xx, so the entry could just be removed from MAINTAINERS.
If you have the hardware, that's fine with me.
> For the OHCI driver, I'm in the same boat as the Ethernet. If you are
> no longer maintaining this driver I'm willing to handle it but would
> like someone to step up as a co-maintainer. Hopefully someone that
> has some grasp of that subsystem.
Same here.
> Your also listed in the source as the maintainer of these ep93xx boards:
>
> ADSSPHERE adssphere.c
> EDB9302A edb93xx.c
> EDB9315 edb93xx.c
> EDB9315A edb93xx.c
> GESBC9312 gesbc9312.c
> TS72XX ts72xx.c
>
> I'm willing to handle those also since they are under arch/arm/mach-ep93xx.
Do you have all these boards, though?
thanks,
Lennert
^ permalink raw reply
* Re: [PATCH] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: Vlad Zolotarov @ 2011-06-15 10:08 UTC (permalink / raw)
To: David Woodhouse; +Cc: Dave Miller, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <1308127394.3450.103.camel@i7.infradead.org>
>
> Hm, I don't think I did receive that. Last message I have from you in
> that thread is Tue, 14 Jun 2011 13:53:34 +0300
>
> Please resend.
I've sent it to u once again a minute ago.
If for any reason u don't get it, the patch is avaliable at
http://linux.broadcom.com/eilong/FW-7.0.20.0/
thanks,
vlad
^ permalink raw reply
* [PATCH for 3.0-rc4 1/2] dp83640: fix phy status frame event parsing
From: Richard Cochran @ 2011-06-15 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, David Miller, John Stultz, Thomas Gleixner
In-Reply-To: <cover.1308129342.git.richard.cochran@omicron.at>
If two eternal time stamp events occur at nearly the same time, the
phyter will add an extra word into the status frame. This commit fixes
the parsing code to recognize and skip over the extra word.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/phy/dp83640.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index b0c9522..ead323e 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -543,11 +543,20 @@ static void recalibrate(struct dp83640_clock *clock)
/* time stamping methods */
-static void decode_evnt(struct dp83640_private *dp83640,
- struct phy_txts *phy_txts, u16 ests)
+static int decode_evnt(struct dp83640_private *dp83640,
+ void *data, u16 ests)
{
+ struct phy_txts *phy_txts;
struct ptp_clock_event event;
int words = (ests >> EVNT_TS_LEN_SHIFT) & EVNT_TS_LEN_MASK;
+ u16 ext_status = 0;
+
+ if (ests & MULT_EVNT) {
+ ext_status = *(u16 *) data;
+ data += sizeof(ext_status);
+ }
+
+ phy_txts = data;
switch (words) { /* fall through in every case */
case 3:
@@ -565,6 +574,9 @@ static void decode_evnt(struct dp83640_private *dp83640,
event.timestamp = phy2txts(&dp83640->edata);
ptp_clock_event(dp83640->clock->ptp_clock, &event);
+
+ words = ext_status ? words + 2 : words + 1;
+ return words * sizeof(u16);
}
static void decode_rxts(struct dp83640_private *dp83640,
@@ -643,9 +655,7 @@ static void decode_status_frame(struct dp83640_private *dp83640,
} else if (PSF_EVNT == type && len >= sizeof(*phy_txts)) {
- phy_txts = (struct phy_txts *) ptr;
- decode_evnt(dp83640, phy_txts, ests);
- size = sizeof(*phy_txts);
+ size = decode_evnt(dp83640, ptr, ests);
} else {
size = 0;
--
1.7.0.4
^ permalink raw reply related
* [PATCH for 3.0-rc4 2/2] dp83640: drop PHY status frames in the driver.
From: Richard Cochran @ 2011-06-15 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, David Miller, John Stultz, Thomas Gleixner
In-Reply-To: <cover.1308129342.git.richard.cochran@omicron.at>
The dp83640 PHY provides time stamp and other information via special
PHY status frames. Previously, the driver decoded the frames and then
let the network stack drop them. This works fine when the PTP messages
come over UDP.
However, when receiving PTP messages via L2 packets, this creates a
problem. The status frames use the official PTP destination MAC address,
and so they are delivered to user space along with the "real" frames,
causing confusion for applications.
This commit fixes the issue by simply dropping the PHY status frames
in the driver.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/phy/dp83640.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index ead323e..2cd8dc5 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -1044,8 +1044,8 @@ static bool dp83640_rxtstamp(struct phy_device *phydev,
if (is_status_frame(skb, type)) {
decode_status_frame(dp83640, skb);
- /* Let the stack drop this frame. */
- return false;
+ kfree_skb(skb);
+ return true;
}
SKB_PTP_TYPE(skb) = type;
--
1.7.0.4
^ permalink raw reply related
* [PATCH for 3.0-rc4 0/2] dp83640: bug fixes
From: Richard Cochran @ 2011-06-15 9:55 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, David Miller, John Stultz, Thomas Gleixner
This series fixes two status frame related bugs in the driver for the
dp83640 phy. I am not sure whether you would call this a timer fix or
a networking fix, so I put both groups on CC.
Thanks,
Richard
Richard Cochran (2):
dp83640: fix phy status frame event parsing
dp83640: drop PHY status frames in the driver.
drivers/net/phy/dp83640.c | 24 +++++++++++++++++-------
1 files changed, 17 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: tc match MAC destination
From: Eric Dumazet @ 2011-06-15 9:43 UTC (permalink / raw)
To: ierdnah; +Cc: linux-kernel, pdoru.kernel, netdev
In-Reply-To: <1308125523.30324.64.camel@ierdnac-hp>
Le mercredi 15 juin 2011 à 11:12 +0300, Andrei Popa a écrit :
> Hello,
>
> I want to shape PVSTP+ traffic (traffic that has MAC destination
> 01:00:0c:cc:cc:cd) and it doesn't work.
> I've tried
> filter parent 1: protocol 802_3 pref 2 u32 fh 802::11 order 17 key ht
> 802 bkt 0 flowid 1:3
> match 01000ccc/ffffffff at 0
> but it doesn't work.
>
> With
> filter parent 1: protocol arp pref 1 u32
> filter parent 1: protocol arp pref 1 u32 fh 801: ht divisor 1
> filter parent 1: protocol arp pref 1 u32 fh 801::7 order 7 key ht 801
> bkt 0 flowid 1:3
> match 00000000/00000000 at 0
> filter parent 1: protocol 802_3 pref 2 u32
> filter parent 1: protocol 802_3 pref 2 u32 fh 802: ht divisor 1
> filter parent 1: protocol 802_3 pref 2 u32 fh 802::3 order 3 key ht 802
> bkt 0 flowid 1:3
> match 00000000/00000000 at 0
> action order 1: mirred (Egress Mirror to device ifb1) pipe
> index 1923 ref 1 bind 1
>
> I see arp trafic with tcpdump on ifb1, but no STP traffic or any kind of
> traffic except arp, because I've matched all MAC addreses.
> Can somebody verify that this match works ?
>
> I use kernel 2.6.39.1.
>
> Thank you,
Hi Andrei
Since you refer to a very complex network setup, it would really help if
you provide a self contained script so that we can take a look.
We netdev guys saw your first mail days ago but are a bit busy, so the
7th point listed in "REPORTING-BUGS" would be nice :
[7.] A small shell script or example program which triggers the problem
^ permalink raw reply
* Hi Dear
From: monicagirl4god8g @ 2011-06-15 9:16 UTC (permalink / raw)
To: monicagirl4god8g
Hello
My name is Miss Monica.a 23 yrs old girl .I am average in height and fair in complexion ,am a loving and caring angel.I fine your mail contact today truly is quiet interesting to me then , i decide to contact you.i really want to have a good relationship with you. Beside i have a special something i want to discuses with you,so you can reach me through this my(monicagirl4god8g@yahoo.com)Hope to hear from you soon.i will send my beautiful pictures to you and also tell you more about my self. I know age will not be a barer to our relationship, what i need is just your love and caring. I will give you my best,
bye for now. care from
Miss Monica
^ permalink raw reply
* RE: [PATCH] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: David Woodhouse @ 2011-06-15 8:43 UTC (permalink / raw)
To: Vlad Zolotarov; +Cc: Dave Miller, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <201106151011.34758.vladz@broadcom.com>
On Wed, 2011-06-15 at 10:11 +0300, Vlad Zolotarov wrote:
> > - Add a separate directory for the bnx2x FW.
> > - Post a new FW version: 7.0.20.0
> >
> > Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> > Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> > ---
> > WHENCE | 3 +++
> > bnx2x/bnx2x-e1-7.0.20.0.fw | Bin 0 -> 161144 bytes
> > bnx2x/bnx2x-e1h-7.0.20.0.fw | Bin 0 -> 168552 bytes
> > bnx2x/bnx2x-e2-7.0.20.0.fw | Bin 0 -> 290952 bytes
> > 4 files changed, 3 insertions(+), 0 deletions(-)
> > create mode 100644 bnx2x/bnx2x-e1-7.0.20.0.fw
> > create mode 100644 bnx2x/bnx2x-e1h-7.0.20.0.fw
> > create mode 100644 bnx2x/bnx2x-e2-7.0.20.0.fw
>
> David, did u have a chance to apply it? Pls., let me know if u want me to
> resend it to u.
Hm, I don't think I did receive that. Last message I have from you in
that thread is Tue, 14 Jun 2011 13:53:34 +0300
Please resend.
--
dwmw2
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 2/9] xen: convert to 64 bit stats interface
From: Ian Campbell @ 2011-06-15 8:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ben Hutchings, Stephen Hemminger, xen-devel@lists.xensource.com,
netdev@vger.kernel.org, Jeremy Fitzhardinge, David S. Miller
In-Reply-To: <20110614210756.GA22304@dumpdata.com>
On Tue, 2011-06-14 at 22:07 +0100, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 09, 2011 at 02:56:45AM +0100, Ben Hutchings wrote:
> > On Wed, 2011-06-08 at 17:53 -0700, Stephen Hemminger wrote:
> > > Convert xen driver to 64 bit statistics interface.
> > > This driver was already counting packet per queue in a 64 bit value so not
> > > a huge change.
> > [...]
> >
> > I think this driver will need to use u64_stats_sync.
>
> Ian?
I'll defer to Ben on this, but the case for needing u64_stats_sync for
64 bit values seems reasonable to me.
Ian.
^ permalink raw reply
* Re: [PATCH] phylib: Allow BCM63XX PHY to be selected only on BCM63XX.
From: Florian Fainelli @ 2011-06-15 8:20 UTC (permalink / raw)
To: Ralf Baechle; +Cc: David S. Miller, netdev, linux-mips
In-Reply-To: <20110615080758.GA3226@linux-mips.org>
On Wednesday 15 June 2011 10:07:58 Ralf Baechle wrote:
> This PHY is available integrated into BCM63xx series SOCs only.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Florian Fainelli <ffainelli@freebox.fr>
>
> drivers/net/phy/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 392a6c4..a702443 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -58,6 +58,7 @@ config BROADCOM_PHY
>
> config BCM63XX_PHY
> tristate "Drivers for Broadcom 63xx SOCs internal PHY"
> + depends on BCM63XX
> ---help---
> Currently supports the 6348 and 6358 PHYs.
^ permalink raw reply
* tc match MAC destination
From: Andrei Popa @ 2011-06-15 8:12 UTC (permalink / raw)
To: linux-kernel; +Cc: pdoru.kernel, netdev
Hello,
I want to shape PVSTP+ traffic (traffic that has MAC destination
01:00:0c:cc:cc:cd) and it doesn't work.
I've tried
filter parent 1: protocol 802_3 pref 2 u32 fh 802::11 order 17 key ht
802 bkt 0 flowid 1:3
match 01000ccc/ffffffff at 0
but it doesn't work.
With
filter parent 1: protocol arp pref 1 u32
filter parent 1: protocol arp pref 1 u32 fh 801: ht divisor 1
filter parent 1: protocol arp pref 1 u32 fh 801::7 order 7 key ht 801
bkt 0 flowid 1:3
match 00000000/00000000 at 0
filter parent 1: protocol 802_3 pref 2 u32
filter parent 1: protocol 802_3 pref 2 u32 fh 802: ht divisor 1
filter parent 1: protocol 802_3 pref 2 u32 fh 802::3 order 3 key ht 802
bkt 0 flowid 1:3
match 00000000/00000000 at 0
action order 1: mirred (Egress Mirror to device ifb1) pipe
index 1923 ref 1 bind 1
I see arp trafic with tcpdump on ifb1, but no STP traffic or any kind of
traffic except arp, because I've matched all MAC addreses.
Can somebody verify that this match works ?
I use kernel 2.6.39.1.
Thank you,
--
Andrei Popa
0760 683 280
^ permalink raw reply
* [PATCH] phylib: Allow BCM63XX PHY to be selected only on BCM63XX.
From: Ralf Baechle @ 2011-06-15 8:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-mips, Florian Fainelli
This PHY is available integrated into BCM63xx series SOCs only.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
drivers/net/phy/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 392a6c4..a702443 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -58,6 +58,7 @@ config BROADCOM_PHY
config BCM63XX_PHY
tristate "Drivers for Broadcom 63xx SOCs internal PHY"
+ depends on BCM63XX
---help---
Currently supports the 6348 and 6358 PHYs.
^ permalink raw reply related
* [PATCH] ppp: use PPP_TRANS instead of the magic number 0x20
From: Changli Gao @ 2011-06-15 7:58 UTC (permalink / raw)
To: David S. Miller; +Cc: Paul Mackerras, linux-ppp, netdev, Changli Gao
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
drivers/net/ppp_async.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index 6436ba9..c6ba643 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -524,7 +524,7 @@ static void ppp_async_process(unsigned long arg)
#define PUT_BYTE(ap, buf, c, islcp) do { \
if ((islcp && c < 0x20) || (ap->xaccm[c >> 5] & (1 << (c & 0x1f)))) {\
*buf++ = PPP_ESCAPE; \
- *buf++ = c ^ 0x20; \
+ *buf++ = c ^ PPP_TRANS; \
} else \
*buf++ = c; \
} while (0)
@@ -897,7 +897,7 @@ ppp_async_input(struct asyncppp *ap, const unsigned char *buf,
sp = skb_put(skb, n);
memcpy(sp, buf, n);
if (ap->state & SC_ESCAPE) {
- sp[0] ^= 0x20;
+ sp[0] ^= PPP_TRANS;
ap->state &= ~SC_ESCAPE;
}
}
^ permalink raw reply related
* RE: [PATCH] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: Vlad Zolotarov @ 2011-06-15 7:11 UTC (permalink / raw)
To: David Woodhouse; +Cc: Dave Miller, Eilon Greenstein, netdev@vger.kernel.org
> - Add a separate directory for the bnx2x FW.
> - Post a new FW version: 7.0.20.0
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> ---
> WHENCE | 3 +++
> bnx2x/bnx2x-e1-7.0.20.0.fw | Bin 0 -> 161144 bytes
> bnx2x/bnx2x-e1h-7.0.20.0.fw | Bin 0 -> 168552 bytes
> bnx2x/bnx2x-e2-7.0.20.0.fw | Bin 0 -> 290952 bytes
> 4 files changed, 3 insertions(+), 0 deletions(-)
> create mode 100644 bnx2x/bnx2x-e1-7.0.20.0.fw
> create mode 100644 bnx2x/bnx2x-e1h-7.0.20.0.fw
> create mode 100644 bnx2x/bnx2x-e2-7.0.20.0.fw
David, did u have a chance to apply it? Pls., let me know if u want me to
resend it to u.
thanks,
vlad
^ permalink raw reply
* Re: [PATCH 1/2] batman-adv: count_real_packets() in batman-adv assumes char is signed
From: Sven Eckelmann @ 2011-06-15 6:58 UTC (permalink / raw)
To: David Howells; +Cc: Marek Lindner, Simon Wunderlich, b.a.t.m.a.n, netdev
In-Reply-To: <20110614235132.3724.57632.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: Text/Plain, Size: 1087 bytes --]
On Wednesday 15 June 2011 01:51:32 David Howells wrote:
> count_real_packets() in batman-adv assumes char is signed, and returns -1
> through it:
>
> net/batman-adv/routing.c: In function 'receive_bat_packet':
> net/batman-adv/routing.c:739: warning: comparison is always false due to
> limited range of data type
>
> Use int instead.
>
> This is also looks a bit weird as (presumably signed) is_duplicate is
> constructed by OR'ding together the unsigned results of get_bit_status()
> (though the latter only returns 0 or 1).
Sry, had to catch the train and had no time to explain it further.
It is correct that is_duplicate will only have 0 and 1 stored, but the
window_protected function (called before the loop) may detect that the packet
has to be dropped and we return in that case -1.
I don't know who started to use char in those places, but thanks for reminding
me how much I hate it and that I wanted to check the rest of the code. :)
I will submit the corrected patch in a pull request later this week to David
S. Miller.
Thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] batman-adv: count_real_packets() in batman-adv assumes char is signed
From: Sven Eckelmann @ 2011-06-15 5:59 UTC (permalink / raw)
To: David Howells
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, Marek Lindner,
Simon Wunderlich
In-Reply-To: <20110614235132.3724.57632.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 738 bytes --]
David Howells wrote:
> count_real_packets() in batman-adv assumes char is signed, and returns -1
> through it:
>
> net/batman-adv/routing.c: In function 'receive_bat_packet':
> net/batman-adv/routing.c:739: warning: comparison is always false due to
> limited range of data type
>
> Use int instead.
>
[...]
> -static char count_real_packets(struct ethhdr *ethhdr,
> - struct batman_packet *batman_packet,
> - struct hard_iface *if_incoming)
> +static int count_real_packets(struct ethhdr *ethhdr,
> + struct batman_packet *batman_packet,
> + struct hard_iface *if_incoming)
> {
This one doesn't apply on linux-next/net-next-2.6, but I will fix it by hand.
Thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [stable] Please revert "iwlagn: Support new 5000 microcode." from 2.6.32 and 2.6.33
From: Stanislaw Gruszka @ 2011-06-15 5:57 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski
Cc: Greg KH, stable, donald.h.fry, reinette.chatre, wey-yi.w.guy, ilw,
linville, ak, linux-wireless, netdev, linux-kernel
In-Reply-To: <20110615011443.GA13680@herton-IdeaPad-Y430>
On Tue, Jun 14, 2011 at 10:14:44PM -0300, Herton Ronaldo Krzesinski wrote:
> On Tue, Jun 14, 2011 at 04:03:44PM -0700, Greg KH wrote:
> > On Mon, Jun 13, 2011 at 03:13:18PM -0300, Herton Ronaldo Krzesinski wrote:
> > > The patch ("iwlagn: Support new 5000 microcode") shoudn't have been
> > > applied on 2.6.32 and 2.6.33 stable trees, it doesn't support new
> > > firmware file format, thus if the new firmware is on the disk, loading
> > > fails, as reported on:
> > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336
> > >
> > > Support for the iwlagn new firmware file format was only added beginning
> > > with 2.6.35 (commit "iwlagn: implement loading a new firmware file
> > > type"), so iwlagn works with new firmware only with 2.6.35 or later.
> >
> > Can I get an ack from the developer of the patch and the people involved
> > with it first? It was asked to be backported for a reason, so I would
> > at least like to get the people who asked for the backport to have a
> > chance to respond please.
> >
> > It's only nice, why would you exclude them?
>
> I didn't intend to exclude anyone and I'm just reporting it, it didn't
> came to my mind CC'ing people while sending to stable, and hopefully
> everyone related are CC'ed now.
>
> Also note that this revert request is for 2.6.32 and 2.6.33 *only*
>
> And seems the right thing to do for them.
>
> The other stable release where this was applied (2.6.35) looks fine
> but these two are too old to support the new firmware (don't work, need
> extra patches backported which weren't, like the commit I mentioned --
> commit "iwlagn: implement loading a new firmware file type"), as yourself
> can check reading the code/bug report, and what I wrote.
ACK for revert. I could be wrong, but I think some more patches, except mentioned
new format patch, are needed to make driver work reliably with the new firmware.
Stanislaw
^ permalink raw reply
* Re: [PATCH 2/2] batman-adv: compare_eth() should take const pointer arguments
From: Sven Eckelmann @ 2011-06-15 5:56 UTC (permalink / raw)
To: David Howells; +Cc: Marek Lindner, Simon Wunderlich, b.a.t.m.a.n, netdev
In-Reply-To: <20110614235142.3724.92963.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: Text/Plain, Size: 1825 bytes --]
David Howells wrote:
> compare_eth() should take const pointer arguments so that it can be passed
> const pointers without the need for a cast, leading to:
>
> net/batman-adv/vis.c: In function 'vis_data_insert_interface':
> net/batman-adv/vis.c:146: warning: passing argument 2 of 'compare_eth'
> discards qualifiers from pointer target type
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Marek Lindner <lindner_marek@yahoo.de>
> cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
> cc: Sven Eckelmann <sven@narfation.org>
> cc: b.a.t.m.a.n@lists.open-mesh.org
> cc: netdev@vger.kernel.org
> ---
>
> net/batman-adv/main.h | 2 +-
> net/batman-adv/vis.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
> index 148b49e..e6fc798 100644
> --- a/net/batman-adv/main.h
> +++ b/net/batman-adv/main.h
> @@ -172,7 +172,7 @@ static inline void bat_dbg(char type __always_unused,
> *
> * note: can't use compare_ether_addr() as it requires aligned memory
> */
> -static inline int compare_eth(void *data1, void *data2)
> +static inline int compare_eth(const void *data1, const void *data2)
> {
> return (memcmp(data1, data2, ETH_ALEN) == 0 ? 1 : 0);
> }
> diff --git a/net/batman-adv/vis.c b/net/batman-adv/vis.c
> index c39f20c..34053ac 100644
> --- a/net/batman-adv/vis.c
> +++ b/net/batman-adv/vis.c
> @@ -143,7 +143,7 @@ static void vis_data_insert_interface(const uint8_t
> *interface, struct hlist_node *pos;
>
> hlist_for_each_entry(entry, pos, if_list, list) {
> - if (compare_eth(entry->addr, (void *)interface))
> + if (compare_eth(entry->addr, interface))
> return;
> }
Sry, but this patch doesn't apply here (net-next-2.6/linux-next)
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: IGMP snooping: set mrouters_only flag for IPv4 traffic properly
From: Fernando Luis Vázquez Cao @ 2011-06-15 5:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Herbert Xu, netdev, Hayato Kakuta
In-Reply-To: <20110614132212.2ac83c6c@s6510.ftrdhcpuser.net>
On Tue, 2011-06-14 at 13:22 -0400, Stephen Hemminger wrote:
> On Mon, 13 Jun 2011 12:02:43 +0900
> Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> wrote:
>
> > Upon reception of a IGMP/IGMPv2 membership report the kernel sets the
> > mrouters_only flag in a skb that may be a clone of the original skb, which
> > means that sometimes the bridge loses track of membership report packets (cb
> > buffers are tied to a specifici skb and not shared) and it ends up forwading
> > join requests to the bridge interface.
> >
> > This can cause unexpected membership timeouts and intermitent/permanent loss of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
> >
> > A snooping switch should forward IGMP Membership Reports only to
> > those ports where multicast routers are attached.
> > [...]
> > Sending membership reports to other hosts can result, for IGMPv1
> > and IGMPv2, in unintentionally preventing a host from joining a
> > specific multicast group.
> >
> >
> > Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> > Tested-by: Hayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
> > ---
> >
> > diff -urNp linux-3.0-rc2-orig/net/bridge/br_multicast.c linux-3.0-rc2/net/bridge/br_multicast.c
> > --- linux-3.0-rc2-orig/net/bridge/br_multicast.c 2011-06-09 13:34:04.164261031 +0900
> > +++ linux-3.0-rc2/net/bridge/br_multicast.c 2011-06-09 20:04:23.473930447 +0900
> > @@ -1424,7 +1424,7 @@ static int br_multicast_ipv4_rcv(struct
> > switch (ih->type) {
> > case IGMP_HOST_MEMBERSHIP_REPORT:
> > case IGMPV2_HOST_MEMBERSHIP_REPORT:
> > - BR_INPUT_SKB_CB(skb2)->mrouters_only = 1;
> > + BR_INPUT_SKB_CB(skb)->mrouters_only = 1;
> > err = br_ip4_multicast_add_group(br, port, ih->group);
> > break;
> > case IGMPV3_HOST_MEMBERSHIP_REPORT:
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Can I take that as an acked-by for the IPv6 patch too?
Thanks,
Fernando
^ permalink raw reply
* [PATCH v2] net/r8169: update the new parser for the new firmware
From: Hayes Wang @ 2011-06-15 3:45 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Update the parser for the new firmware which is embedded some information.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 96 +++++++++++++++++++++++++++++++++++++--------------
1 files changed, 70 insertions(+), 26 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index ef1ce2e..bd9e78f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -594,6 +594,14 @@ struct ring_info {
u8 __pad[sizeof(void *) - sizeof(u32)];
};
+struct fw_info {
+ u32 magic;
+ char version[32];
+ u32 fw_start;
+ u32 fw_len;
+ u8 chksum;
+};
+
enum features {
RTL_FEATURE_WOL = (1 << 0),
RTL_FEATURE_MSI = (1 << 1),
@@ -1740,21 +1748,57 @@ static void rtl_writephy_batch(struct rtl8169_private *tp,
#define PHY_DELAY_MS 0xe0000000
#define PHY_WRITE_ERI_WORD 0xf0000000
+static int is_firmware_valid(const struct firmware *fw)
+{
+ struct fw_info *f_info = (struct fw_info *)fw->data;
+
+ if (f_info->magic == 0) {
+ size_t i, fw_size;
+ u8 checksum = 0;
+
+ for (i = 0; i < fw->size; i++) {
+ checksum += fw->data[i];
+ }
+
+ if (checksum != 0)
+ return 0;
+
+ fw_size = (fw->size - le32_to_cpu(f_info->fw_start)) / 4;
+ if (fw_size < le32_to_cpu(f_info->fw_len))
+ return 0;
+ } else if (fw->size % 4) {
+ return 0;
+ }
+
+ return 1;
+}
+
static void
rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
{
- __le32 *phytable = (__le32 *)fw->data;
+ struct fw_info *f_info = (struct fw_info *)fw->data;
struct net_device *dev = tp->dev;
- size_t index, fw_size = fw->size / sizeof(*phytable);
+ __le32 *phytable;
+ size_t i, fw_size;
u32 predata, count;
- if (fw->size % sizeof(*phytable)) {
- netif_err(tp, probe, dev, "odd sized firmware %zd\n", fw->size);
+ if (!is_firmware_valid(fw)) {
+ netif_err(tp, probe, dev, "Invalid firwmare\n");
return;
}
- for (index = 0; index < fw_size; index++) {
- u32 action = le32_to_cpu(phytable[index]);
+ if (f_info->magic == 0) {
+ netif_info(tp, probe, dev, "firmware: %s\n", f_info->version);
+
+ phytable = (__le32 *)(fw->data + le32_to_cpu(f_info->fw_start));
+ fw_size = le32_to_cpu(f_info->fw_len);
+ } else {
+ phytable = (__le32 *)fw->data;
+ fw_size = fw->size / sizeof(*phytable);
+ }
+
+ for (i = 0; i < fw_size; i++) {
+ u32 action = le32_to_cpu(phytable[i]);
u32 regno = (action & 0x0fff0000) >> 16;
switch(action & 0xf0000000) {
@@ -1769,14 +1813,14 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
break;
case PHY_BJMPN:
- if (regno > index) {
+ if (regno > i) {
netif_err(tp, probe, tp->dev,
"Out of range of firmware\n");
return;
}
break;
case PHY_READCOUNT_EQ_SKIP:
- if (index + 2 >= fw_size) {
+ if (i + 2 >= fw_size) {
netif_err(tp, probe, tp->dev,
"Out of range of firmware\n");
return;
@@ -1785,7 +1829,7 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
case PHY_COMP_EQ_SKIPN:
case PHY_COMP_NEQ_SKIPN:
case PHY_SKIPN:
- if (index + 1 + regno >= fw_size) {
+ if (i + 1 + regno >= fw_size) {
netif_err(tp, probe, tp->dev,
"Out of range of firmware\n");
return;
@@ -1805,8 +1849,8 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
predata = 0;
count = 0;
- for (index = 0; index < fw_size; ) {
- u32 action = le32_to_cpu(phytable[index]);
+ for (i = 0; i < fw_size; ) {
+ u32 action = le32_to_cpu(phytable[i]);
u32 data = action & 0x0000ffff;
u32 regno = (action & 0x0fff0000) >> 16;
@@ -1817,54 +1861,54 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
case PHY_READ:
predata = rtl_readphy(tp, regno);
count++;
- index++;
+ i++;
break;
case PHY_DATA_OR:
predata |= data;
- index++;
+ i++;
break;
case PHY_DATA_AND:
predata &= data;
- index++;
+ i++;
break;
case PHY_BJMPN:
- index -= regno;
+ i -= regno;
break;
case PHY_READ_EFUSE:
predata = rtl8168d_efuse_read(tp->mmio_addr, regno);
- index++;
+ i++;
break;
case PHY_CLEAR_READCOUNT:
count = 0;
- index++;
+ i++;
break;
case PHY_WRITE:
rtl_writephy(tp, regno, data);
- index++;
+ i++;
break;
case PHY_READCOUNT_EQ_SKIP:
- index += (count == data) ? 2 : 1;
+ i += (count == data) ? 2 : 1;
break;
case PHY_COMP_EQ_SKIPN:
if (predata == data)
- index += regno;
- index++;
+ i += regno;
+ i++;
break;
case PHY_COMP_NEQ_SKIPN:
if (predata != data)
- index += regno;
- index++;
+ i += regno;
+ i++;
break;
case PHY_WRITE_PREVIOUS:
rtl_writephy(tp, regno, predata);
- index++;
+ i++;
break;
case PHY_SKIPN:
- index += regno + 1;
+ i += regno + 1;
break;
case PHY_DELAY_MS:
mdelay(data);
- index++;
+ i++;
break;
case PHY_READ_MAC_BYTE:
--
1.7.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox