* [PATCH net-next 2/4] cnic: Read bnx2x function number from internal register
From: Michael Chan @ 2012-06-28 1:08 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1340845704-12580-1-git-send-email-mchan@broadcom.com>
From: Eddie Wai <eddie.wai@broadcom.com>
so that it will work on any hypervisor.
Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/cnic.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index 31b05ad..5980443 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -4988,8 +4988,14 @@ static int cnic_start_bnx2x_hw(struct cnic_dev *dev)
cp->port_mode = CHIP_PORT_MODE_NONE;
if (BNX2X_CHIP_IS_E2_PLUS(cp->chip_id)) {
- u32 val = CNIC_RD(dev, MISC_REG_PORT4MODE_EN_OVWR);
+ u32 val;
+
+ pci_read_config_dword(dev->pcidev, PCICFG_ME_REGISTER, &val);
+ cp->func = (u8) ((val & ME_REG_ABS_PF_NUM) >>
+ ME_REG_ABS_PF_NUM_SHIFT);
+ func = CNIC_FUNC(cp);
+ val = CNIC_RD(dev, MISC_REG_PORT4MODE_EN_OVWR);
if (!(val & 1))
val = CNIC_RD(dev, MISC_REG_PORT4MODE_EN);
else
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 4/4] cnic: Handle RAMROD_CMD_ID_CLOSE error.
From: Michael Chan @ 2012-06-28 1:08 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1340845704-12580-3-git-send-email-mchan@broadcom.com>
From: Eddie Wai <eddie.wai@broadcom.com>
If firmware returns error status, proceed to close the iSCSI connection.
Update version to 2.5.11.
Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/cnic.c | 9 +++++++++
drivers/net/ethernet/broadcom/cnic_if.h | 4 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index ec43df1..f897306 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -3953,6 +3953,15 @@ static void cnic_cm_process_kcqe(struct cnic_dev *dev, struct kcqe *kcqe)
cnic_cm_upcall(cp, csk, opcode);
break;
+ case L5CM_RAMROD_CMD_ID_CLOSE:
+ if (l4kcqe->status != 0) {
+ netdev_warn(dev->netdev, "RAMROD CLOSE compl with "
+ "status 0x%x\n", l4kcqe->status);
+ opcode = L4_KCQE_OPCODE_VALUE_CLOSE_COMP;
+ /* Fall through */
+ } else {
+ break;
+ }
case L4_KCQE_OPCODE_VALUE_RESET_RECEIVED:
case L4_KCQE_OPCODE_VALUE_CLOSE_COMP:
case L4_KCQE_OPCODE_VALUE_RESET_COMP:
diff --git a/drivers/net/ethernet/broadcom/cnic_if.h b/drivers/net/ethernet/broadcom/cnic_if.h
index d63d455..54f68f0 100644
--- a/drivers/net/ethernet/broadcom/cnic_if.h
+++ b/drivers/net/ethernet/broadcom/cnic_if.h
@@ -14,8 +14,8 @@
#include "bnx2x/bnx2x_mfw_req.h"
-#define CNIC_MODULE_VERSION "2.5.10"
-#define CNIC_MODULE_RELDATE "March 21, 2012"
+#define CNIC_MODULE_VERSION "2.5.11"
+#define CNIC_MODULE_RELDATE "June 27, 2012"
#define CNIC_ULP_RDMA 0
#define CNIC_ULP_ISCSI 1
--
1.7.1
^ permalink raw reply related
* [PATCH] net: Downgrade CAP_SYS_MODULE deprecated message from error to warning.
From: Vinson Lee @ 2012-06-28 0:32 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, mirq-linux, Jiri Pirko,
Tom Herbert
Cc: netdev, linux-kernel, Vinson Lee, David Mackey
Make logging level consistent with other deprecation messages in net
subsystem.
Signed-off-by: Vinson Lee <vlee@twitter.com>
Cc: David Mackey <tdmackey@twitter.com>
---
| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--git a/net/core/dev.c b/net/core/dev.c
index cd09819..b19a361 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1136,8 +1136,8 @@ void dev_load(struct net *net, const char *name)
no_module = request_module("netdev-%s", name);
if (no_module && capable(CAP_SYS_MODULE)) {
if (!request_module("%s", name))
- pr_err("Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s instead.\n",
- name);
+ pr_warn("Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s instead.\n",
+ name);
}
}
EXPORT_SYMBOL(dev_load);
--
1.7.9.5
^ permalink raw reply related
* I wanna be your friend if you don't mind
From: Claire Pesce @ 2012-06-28 0:28 UTC (permalink / raw)
To: mrdave_35@collegeclub.com
One of my female friends offered me to write u this mail and know you a little bit closer! I'm sure u would not be against of it.
My name is Claire! I am 23 years and I learn in university.
Here I'm looking for a nice man just to talk, to go to cafe, who knows have journey through Europe or even build family.
I hope one of my female friends was right and that u really the man that I was looking for!
^ permalink raw reply
* Re: [PATCH net-next] ipv4: tcp: dont cache unconfirmed intput dst
From: David Miller @ 2012-06-28 0:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hans.schillstrom
In-Reply-To: <20120627.170101.99084491660488389.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 27 Jun 2012 17:01:01 -0700 (PDT)
> There are quite a number of unwanted side effects from this change, so
> I think we'll have to revert unless you can fix up all of the relevant
> cases quickly.
Actually I've decided to revert it now.
Whilst this was a swell idea, there is no way for you to know if
we should really create a cached route or not.
Even if you could, there is a lot of logic you'll need to code up
so that, f.e., once we determine that we've got a DST_NOCACHE route
when we move to established state, we can insert it into the routing
cache and not mark it DST_NOCACHE any longer.
But even if we did that, we're going to eat 2 uncached route lookups
for every new incoming legitimate connection.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: tcp: dont cache unconfirmed intput dst
From: David Miller @ 2012-06-28 0:01 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hans.schillstrom
In-Reply-To: <20120627.164418.1928194990434756968.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 27 Jun 2012 16:44:18 -0700 (PDT)
> What happens now is that legitimate traffic is harmed too. If we
> really go to established state, we'll cache the DST_NOCACHE route
> in sk->sk_rx_dst.
This change also means that all routed TCP traffic will use
DST_NOCACHE routes as well.
It's not a requirement to turn off early demux on a router, and I very
much wanted to avoid the knob altogether. So this side effect is not
acceptable.
There are quite a number of unwanted side effects from this change, so
I think we'll have to revert unless you can fix up all of the relevant
cases quickly.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: tcp: dont cache unconfirmed intput dst
From: David Miller @ 2012-06-27 23:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hans.schillstrom
In-Reply-To: <20120627.153454.30398632011109264.davem@davemloft.net>
Eric, I think we need to make some adjustments after this change.
What happens now is that legitimate traffic is harmed too. If we
really go to established state, we'll cache the DST_NOCACHE route
in sk->sk_rx_dst.
I've added logging to validate that this is in fact happening, it
triggers when I initially ssh into my machine. The early demux route
we end up with has DST_NOCACHE set in it.
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Rick Jones @ 2012-06-27 23:39 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, greearb, shemminger, tparkin, netdev, David.Laight,
jchapman
In-Reply-To: <20120627.160922.686783180082355740.davem@davemloft.net>
On 06/27/2012 04:09 PM, David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Wed, 27 Jun 2012 16:01:23 -0700
>
>> At 100 Gbit/s Ethernet, that is upwards of 147
>
> Listing upcoming technologies shows that you miss Eric's point.
>
> Nobody with a brain is going to drive those kinds of cards on boxes
> running 32-bit kernels.
Yes, I strayed from the context of 32-bit kernels. I will go run iperf
a couple times as penance :)
rick
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: David Miller @ 2012-06-27 23:09 UTC (permalink / raw)
To: rick.jones2
Cc: eric.dumazet, greearb, shemminger, tparkin, netdev, David.Laight,
jchapman
In-Reply-To: <4FEB90C3.9050607@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Wed, 27 Jun 2012 16:01:23 -0700
> At 100 Gbit/s Ethernet, that is upwards of 147
Listing upcoming technologies shows that you miss Eric's point.
Nobody with a brain is going to drive those kinds of cards on boxes
running 32-bit kernels.
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Rick Jones @ 2012-06-27 23:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Greear, Stephen Hemminger, Tom Parkin, netdev, David.Laight,
James Chapman
In-Reply-To: <1340832947.26242.169.camel@edumazet-glaptop>
On 06/27/2012 02:35 PM, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 14:31 -0700, Ben Greear wrote:
>
>> For an example, see the VLAN code. rx-errors and tx-dropped are only 32-bit
>> counters. Now, in the real world, we wouldn't expect those counters to
>> increase at high rates, but they are still 32-bit counters masquerading
>> as 64, and they could wrap after a while, so any code that expected a wrap
>> to mean a 64-bit wrap would be wrong.
>>
>> At the time I was last complaining, there were lots more cases
>> of this that I was fighting with, but I don't recall exactly what they
>> were. Once my user-space code got paranoid enough, it was able to
>> at least mostly deal with 32 and 64 wraps.
>
> Good, you now know how to deal correctly with these things.
>
> Using 64bit fields for tx_dropped is what I call kernel bloat.
Today, sure, generalizing to packet counters in general, that bloat is
likely on its way. At 100 Gbit/s Ethernet, that is upwards of 147
million packets per second each way. At 1 GbE it is 125 million octets
per second. So, if 32 bit octet counters were insufficient for 1 GbE,
32 bit packet counters likely will be insufficient for 100GbE.
Or, I suppose, 3 or more bonded 40 GbEs or 10 or more bonded 10 GbEs
(unlikely though that last one may be) assuming there is stats
aggregation in the bond interface.
rick jones
^ permalink raw reply
* Re: [net-next patch] bnx2x: Define bnx2x_tests_str_arr as const
From: David Miller @ 2012-06-27 22:43 UTC (permalink / raw)
To: meravs; +Cc: David.Laight, netdev, eilong
In-Reply-To: <1340801110.27284.1.camel@lb-tlvb-meravs.il.broadcom.com>
From: "Merav Sicron" <meravs@broadcom.com>
Date: Wed, 27 Jun 2012 15:45:10 +0300
> Dave, please ignore this patch for now.
Ok.
^ permalink raw reply
* Re: [PATCH net-next] net: skb_free_datagram_locked() doesnt drop all packets
From: David Miller @ 2012-06-27 22:42 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1340792624.26242.75.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 12:23:44 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> dropwatch wrongly diagnose all received UDP packets as drops.
>
> This patch removes trace_kfree_skb() done in skb_free_datagram_locked().
>
> Locations calling skb_free_datagram_locked() should do it on their own.
>
> As a result, drops are accounted on the right function.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCHv1] net: added support for 40GbE link.
From: David Miller @ 2012-06-27 22:42 UTC (permalink / raw)
To: bhutchings; +Cc: parav.pandit, netdev
In-Reply-To: <1340812980.2591.0.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 27 Jun 2012 17:03:00 +0100
> On Wed, 2012-06-27 at 19:26 +0530, Parav Pandit wrote:
>> 1. removed code replication for tov calculation for 1G, 10G and
>> made is common for speed > 1G (1G, 10G, 40G, 100G).
>> 2. defines values for #4 different 40G Phys (KR4, LF4, SR4, CR4)
>>
>> Signed-off-by: Parav Pandit <parav.pandit@emulex.com>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/7] Get rid of RTA*() macros
From: David Miller @ 2012-06-27 22:37 UTC (permalink / raw)
To: tgraf; +Cc: netdev
In-Reply-To: <cover.1340788373.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Wed, 27 Jun 2012 11:36:09 +0200
> This patchset gets rid of all the RTA_PUT() and RTA_GET()
> macros and makes use of the type-safe netlink API variants
> where applicable.
>
> I did my best to test these patches but I do not own any
> decnet hardware so the decnet part is compile tested only.
All applied, thanks a lot Thomas.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: tcp: dont cache unconfirmed intput dst
From: David Miller @ 2012-06-27 22:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hans.schillstrom
In-Reply-To: <1340788455.26242.67.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 11:14:15 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> DDOS synflood attacks hit badly IP route cache.
>
> On typical machines, this cache is allowed to hold up to 8 Millions dst
> entries, 256 bytes for each, for a total of 2GB of memory.
>
> rt_garbage_collect() triggers and tries to cleanup things.
>
> Eventually route cache is disabled but machine is under fire and might
> OOM and crash.
>
> This patch exploits the new TCP early demux, to set a nocache
> boolean in case incoming TCP frame is for a not yet ESTABLISHED or
> TIMEWAIT socket.
>
> This 'nocache' boolean is then used in case dst entry is not found in
> route cache, to create an unhashed dst entry (DST_NOCACHE)
>
> SYN-cookie-ACK sent use a similar mechanism (ipv4: tcp: dont cache
> output dst for syncookies), so after this patch, a machine is able to
> absorb a DDOS synflood attack without polluting its IP route cache.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 7/7] netlink: Get rid of obsolete rtnetlink macros
From: Stephen Hemminger @ 2012-06-27 22:31 UTC (permalink / raw)
To: David Miller; +Cc: tgraf, netdev
In-Reply-To: <20120627.150435.67648216442174370.davem@davemloft.net>
On Wed, 27 Jun 2012 15:04:35 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 27 Jun 2012 08:35:32 -0700
>
> > On Wed, 27 Jun 2012 11:36:16 +0200
> > Thomas Graf <tgraf@suug.ch> wrote:
> >
> >> Removes all RTA_GET*() and RTA_PUT*() variations, as well as the
> >> the unused rtattr_strcmp(). Get rid of rtm_get_table() by moving
> >> it to its only user decnet.
> >>
> >> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> >> ---
> >
> > Nack. The RTA_ macros are exported to user space through kernel
> > headers process. If you do this it will break iproute2 build.
> >
>
> They are protected by __KERNEL__, what are you talking about?
Never mind, there are copies in other places in iproute
I plan to get rid of the macro versions of this stuff.
It is a nuisance in iproute for the same reason as the kernel.
^ permalink raw reply
* Re: pull-request: can 2012-06-27
From: David Miller @ 2012-06-27 22:28 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1340789236-28266-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 27 Jun 2012 11:27:15 +0200
> here's a patch intended for v3.5, targeting net/master. Hui Wang has
> found and fixed an endianness problem in the device tree handling in
> the flexcan driver.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [patch -resend] 9p: fix min_t() casting in p9pdu_vwritef()
From: David Miller @ 2012-06-27 22:26 UTC (permalink / raw)
To: dan.carpenter; +Cc: ericvh, aneesh.kumar, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20120627090141.GF31212@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 27 Jun 2012 12:01:41 +0300
> I don't think we're actually likely to hit this limit but if we do
> then the comparison should be done as size_t. The original code
> is equivalent to:
> len = strlen(sptr) % USHRT_MAX;
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: David Miller @ 2012-06-27 22:23 UTC (permalink / raw)
To: eric.dumazet
Cc: fw, brouer, hans.schillstrom, subramanian.vijay, dave.taht,
netdev, ncardwell, therbert, mph
In-Reply-To: <1340833160.26242.176.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 23:39:20 +0200
> On Wed, 2012-06-27 at 21:50 +0200, Florian Westphal wrote:
>
>> I doubt using jhash is safe for syncookies.
>>
>> There a several differences to other uses in kernel:
>> - all hash input except u32 cookie_secret[2] is known
>> - we transmit hash result (i.e, its visible to 3rd party)
>> - we do not re-seed the secret, ever
>>
>> it should be quite easy to recompute cookie_secret[] from known syncookie
>> values?
>
> We could re-seed the secrets every MSL seconds a bit like in
> tcp_cookie_generator()
>
> This would require check_tcp_syn_cookie() doing two checks (most recent
> seed, and previous one if first check failed)
That could help, but I'm leaning towards not doing this at all. Like
for the normal sequence number generation we really can't do this.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: David Miller @ 2012-06-27 22:23 UTC (permalink / raw)
To: fw
Cc: brouer, eric.dumazet, hans.schillstrom, subramanian.vijay,
dave.taht, netdev, ncardwell, therbert, mph
In-Reply-To: <20120627195032.GI1269@breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 27 Jun 2012 21:50:32 +0200
> - we transmit hash result (i.e, its visible to 3rd party)
Indeed, that's right.
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: David Miller @ 2012-06-27 22:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: rick.jones2, tparkin, netdev, David.Laight, jchapman
In-Reply-To: <1340829541.26242.90.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 22:39:01 +0200
> In 2012 or 2013, 64bits kernels are the norm, and 32bit the exception.
>
> Should we add complex code to l2tp just for being able to run it on
> 32bit kernels with 64bit stats ?
>
> Considering this code is buggy at the v1 & v2, I am really wondering.
>
> All sane SNMP applications are ready to cope with 32bits counters
> wrapping.
>
> Machines that could wrap the 32bit counter several times per second are
> probably running on 64bit kernels.
>
> Also percpu stats are overkill unless a device is really meant to be
> used in // by many cpus.
I agree with Eric on all counts.
^ permalink raw reply
* Re: [PATCH 7/18] netfilter: nfnetlink_log: Move away from NLMSG_PUT().
From: David Miller @ 2012-06-27 22:06 UTC (permalink / raw)
To: bhutchings; +Cc: netdev
In-Reply-To: <1340815773.2591.9.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 27 Jun 2012 17:49:33 +0100
> It looks like this also leaks the skb on failure. At least,
> __nfulnl_flush(inst) is expected to dipose of inst->skb.
I did not change the behavior of this function, if someone wants
to fix this bug that's great, but I'm certainly not obligated to
do so.
^ permalink raw reply
* Re: [PATCH 7/7] netlink: Get rid of obsolete rtnetlink macros
From: David Miller @ 2012-06-27 22:04 UTC (permalink / raw)
To: shemminger; +Cc: tgraf, netdev
In-Reply-To: <20120627083532.38566c87@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 27 Jun 2012 08:35:32 -0700
> On Wed, 27 Jun 2012 11:36:16 +0200
> Thomas Graf <tgraf@suug.ch> wrote:
>
>> Removes all RTA_GET*() and RTA_PUT*() variations, as well as the
>> the unused rtattr_strcmp(). Get rid of rtm_get_table() by moving
>> it to its only user decnet.
>>
>> Signed-off-by: Thomas Graf <tgraf@suug.ch>
>> ---
>
> Nack. The RTA_ macros are exported to user space through kernel
> headers process. If you do this it will break iproute2 build.
>
They are protected by __KERNEL__, what are you talking about?
^ permalink raw reply
* Re: Unknown chipsets from Realtek's 8168 driver
From: Francois Romieu @ 2012-06-27 21:43 UTC (permalink / raw)
To: hayeswang; +Cc: netdev
In-Reply-To: <A8D0CF5460074425A9047CB50C94617D@realtek.com.tw>
hayeswang <hayeswang@realtek.com> :
[...]
> Thanks. I would complete it as soon as possible.
There may be some 810x candidates as well.
[PATCH] r8169: more 810x chipsets from Realtek's 1.022.00 8101 driver
CFG_METHOD_15 / RTL_GIGA_MAC_VER_42
CFG_METHOD_16 / RTL_GIGA_MAC_VER_43
CFG_METHOD_6 / RTL_GIGA_MAC_VER_44
CFG_METHOD_7 / RTL_GIGA_MAC_VER_45
CFG_METHOD_8 / RTL_GIGA_MAC_VER_46
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/ethernet/realtek/r8169.c | 161 +++++++++++++++++++++++++++++++++-
1 file changed, 160 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 8381640..5544e36 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -145,6 +145,11 @@ enum mac_version {
RTL_GIGA_MAC_VER_39,
RTL_GIGA_MAC_VER_40,
RTL_GIGA_MAC_VER_41,
+ RTL_GIGA_MAC_VER_42,
+ RTL_GIGA_MAC_VER_43,
+ RTL_GIGA_MAC_VER_44,
+ RTL_GIGA_MAC_VER_45,
+ RTL_GIGA_MAC_VER_46,
RTL_GIGA_MAC_NONE = 0xff,
};
@@ -270,6 +275,16 @@ static const struct {
_R("RTL8168g/8111g", RTL_TD_1, NULL, JUMBO_9K, false),
[RTL_GIGA_MAC_VER_41] =
_R("RTL8168ep/8111ep", RTL_TD_1, NULL, JUMBO_9K, false),
+ [RTL_GIGA_MAC_VER_42] =
+ _R("RTL8106e", RTL_TD_1, NULL, JUMBO_1K, false),
+ [RTL_GIGA_MAC_VER_43] =
+ _R("RTL8106e", RTL_TD_1, NULL, JUMBO_1K, false),
+ [RTL_GIGA_MAC_VER_44] =
+ _R("RTL8103e", RTL_TD_1, NULL, JUMBO_1K, false),
+ [RTL_GIGA_MAC_VER_45] =
+ _R("RTL8103e", RTL_TD_1, NULL, JUMBO_1K, false),
+ [RTL_GIGA_MAC_VER_46] =
+ _R("RTL8103e", RTL_TD_1, NULL, JUMBO_1K, false),
};
#undef _R
@@ -1427,7 +1442,9 @@ static void rtl_link_chg_patch(struct rtl8169_private *tp)
rtl_eri_write(ioaddr, 0x1dc, ERIAR_MASK_1111,
0x0000003f, ERIAR_EXGMAC);
}
- } else if (tp->mac_version == RTL_GIGA_MAC_VER_37) {
+ } else if (tp->mac_version == RTL_GIGA_MAC_VER_37 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_42 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_43) {
if (RTL_R8(PHYstatus) & _10bps) {
rtl_eri_write(ioaddr, 0x1d0, ERIAR_MASK_0011,
0x4d02, ERIAR_EXGMAC);
@@ -2062,6 +2079,14 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
{ 0x7c800000, 0x30000000, RTL_GIGA_MAC_VER_11 },
/* 8101 family. */
+ { 0x7cf00000, 0x34e00000, RTL_GIGA_MAC_VER_46 },
+ { 0x7cf00000, 0x24e00000, RTL_GIGA_MAC_VER_46 },
+ { 0x7cf00000, 0x34d00000, RTL_GIGA_MAC_VER_45 },
+ { 0x7cf00000, 0x24d00000, RTL_GIGA_MAC_VER_45 },
+ { 0x7cf00000, 0x34c00000, RTL_GIGA_MAC_VER_44 },
+ { 0x7cf00000, 0x24c00000, RTL_GIGA_MAC_VER_44 },
+ { 0x7cf00000, 0x44900000, RTL_GIGA_MAC_VER_43 },
+ { 0x7cf00000, 0x44800000, RTL_GIGA_MAC_VER_42 },
{ 0x7c800000, 0x44000000, RTL_GIGA_MAC_VER_37 },
{ 0x7cf00000, 0x40b00000, RTL_GIGA_MAC_VER_30 },
{ 0x7cf00000, 0x40a00000, RTL_GIGA_MAC_VER_30 },
@@ -3428,6 +3453,64 @@ static void rtl8168ep_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
+static void rtl8106e_hw_phy_config(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0000 },
+ { 0x18, 0x0310 }
+ };
+
+
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+ msleep(20);
+}
+
+static void rtl8106e_1_hw_phy_config(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0001 },
+ { 0x11, 0x83ba },
+ { 0x1f, 0x0000 },
+ { 0x18, 0x8310 },
+ { 0x1f, 0x0000 }
+ };
+
+ rtl8106e_hw_phy_config(tp);
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
+static void rtl8106e_2_hw_phy_config(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0000 },
+ { 0x18, 0x8310 },
+ { 0x1f, 0x0000 }
+ };
+
+
+ rtl8106e_hw_phy_config(tp);
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
+static void rtl8103e_hw_phy_config(struct rtl8169_private *tp)
+{
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0003 },
+ { 0x08, 0x441d },
+ { 0x1f, 0x0000 }
+ };
+
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_w1w0_phy(tp, 0x11, 0x1000, 0x0000);
+ rtl_w1w0_phy(tp, 0x19, 0x2000, 0x0000);
+ rtl_w1w0_phy(tp, 0x10, 0x8000, 0x0000);
+
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
static void rtl_hw_phy_config(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -3536,6 +3619,20 @@ static void rtl_hw_phy_config(struct net_device *dev)
rtl8168ep_hw_phy_config(tp);
break;
+ case RTL_GIGA_MAC_VER_42:
+ rtl8106e_2_hw_phy_config(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_43:
+ rtl8106e_2_hw_phy_config(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_44:
+ rtl8103e_hw_phy_config(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_45:
+ case RTL_GIGA_MAC_VER_46:
default:
break;
}
@@ -3781,6 +3878,8 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_34:
case RTL_GIGA_MAC_VER_37:
case RTL_GIGA_MAC_VER_38:
+ case RTL_GIGA_MAC_VER_42:
+ case RTL_GIGA_MAC_VER_43:
RTL_W32(RxConfig, RTL_R32(RxConfig) |
AcceptBroadcast | AcceptMulticast | AcceptMyPhys);
break;
@@ -3788,6 +3887,9 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_39:
case RTL_GIGA_MAC_VER_40:
case RTL_GIGA_MAC_VER_41:
+ case RTL_GIGA_MAC_VER_44:
+ case RTL_GIGA_MAC_VER_45:
+ case RTL_GIGA_MAC_VER_46:
default:
break;
}
@@ -3835,6 +3937,17 @@ static void r810x_pll_power_down(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_13:
case RTL_GIGA_MAC_VER_16:
break;
+
+ case RTL_GIGA_MAC_VER_44:
+ // ..
+ RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
+ break;
+
+ case RTL_GIGA_MAC_VER_46:
+ // ..
+ RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
+ break;
+
default:
RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
break;
@@ -3855,6 +3968,7 @@ static void r810x_pll_power_up(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_13:
case RTL_GIGA_MAC_VER_16:
break;
+ case RTL_GIGA_MAC_VER_44:
default:
RTL_W8(PMCH, RTL_R8(PMCH) | 0x80);
break;
@@ -5374,6 +5488,34 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
ERIAR_EXGMAC);
}
+static void rtl_hw_start_8106e(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ // ...
+}
+
+static void rtl_hw_start_8103e_1(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ // ...
+}
+
+static void rtl_hw_start_8103e_2(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ // ...
+}
+
+static void rtl_hw_start_8103e_3(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ // ...
+}
+
static void rtl_hw_start_8101(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -5418,6 +5560,23 @@ static void rtl_hw_start_8101(struct net_device *dev)
case RTL_GIGA_MAC_VER_37:
rtl_hw_start_8402(tp);
break;
+
+ case RTL_GIGA_MAC_VER_42:
+ case RTL_GIGA_MAC_VER_43:
+ rtl_hw_start_8106e(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_44:
+ rtl_hw_start_8103e_1(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_45:
+ rtl_hw_start_8103e_2(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_46:
+ rtl_hw_start_8103e_3(tp);
+ break;
}
RTL_W8(Cfg9346, Cfg9346_Lock);
--
1.7.10.2
^ permalink raw reply related
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Eric Dumazet @ 2012-06-27 21:50 UTC (permalink / raw)
To: Ben Greear
Cc: Stephen Hemminger, Rick Jones, Tom Parkin, netdev, David.Laight,
James Chapman
In-Reply-To: <4FEB7DC0.9090404@candelatech.com>
On Wed, 2012-06-27 at 14:40 -0700, Ben Greear wrote:
> Notice that the netlink stats are claiming 64-bit and they are not
> (always) 64-bit.
There is no such claim.
netlink provides a 64bit generic binary holder, even for legacy drivers
still using 'unsigned long' stats, so obviously 32bit values on 32bit
kernels.
> That is a nice binary API that is still wrapping before its time
> in many cases. There may be good performance reasons for keeping
> some counters at 32-bit, but it plays merry hell with anyone wanting
> to optimize an application to poll less often for stats that are
> supposedly 64-bit.
We dont want hundred of patches to bring 64bit stats on legacy drivers.
Nobody cares, because its way too late to try to 'fix' this.
If you want your application running on linux-2.6.x, or linux-3.0, you
are forced to correctly detect each counter being 32 or 64, not because
netlink API is 64bit, but because a driver provides a 32 or 64 bit
value.
^ 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