* Re: [PATCH v2 0/3] Add device tree probe support for imx fec driver
From: David Miller @ 2011-07-06 5:30 UTC (permalink / raw)
To: shawn.guo; +Cc: netdev, devicetree-discuss, linux-arm-kernel, patches
In-Reply-To: <20110705.194854.1875695946300840388.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 05 Jul 2011 19:48:54 -0700 (PDT)
> All applied to net-next-2.6, thanks.
Come on guys:
drivers/of/of_net.c: In function 'of_get_phy_mode':
drivers/of/of_net.c:45: error: implicit declaration of function 'of_property_read_string'
This is completely rediculious.
Don't tell me that it's appropriate to merge something into
my net tree when it uses interfaces that don't even exist
in Linus's tree.
^ permalink raw reply
* have to rewind net-next-2.6
From: David Miller @ 2011-07-06 5:32 UTC (permalink / raw)
To: netdev
I have to rewind net-next-2.6 back to commit "f8bae99"
in order to get rid of the broken OF "phy-mode" patch
that breaks the build.
Sorry for any inconvenience.
^ permalink raw reply
* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: Stephen Hemminger @ 2011-07-06 5:35 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, mike, netdev
In-Reply-To: <20110706050848.GA7564@gondor.apana.org.au>
On Wed, 6 Jul 2011 13:08:48 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Jul 05, 2011 at 10:06:36PM -0700, Stephen Hemminger wrote:
> > On Tue, 05 Jul 2011 18:40:44 -0700 (PDT)
> > David Miller <davem@davemloft.net> wrote:
> >
> > > From: Herbert Xu <herbert@gondor.hengli.com.au>
> > > Date: Wed, 6 Jul 2011 07:58:33 +0800
> > >
> > > > bridge: Always flood broadcast packets
> > > >
> > > > As is_multicast_ether_addr returns true on broadcast packets as
> > > > well, we need to explicitly exclude broadcast packets so that
> > > > they're always flooded. This wasn't an issue before as broadcast
> > > > packets were considered to be an unregistered multicast group,
> > > > which were always flooded. However, as we now only flood such
> > > > packets to router ports, this is no longer acceptable.
> > > >
> > > > Reported-by: Michael Guntsche <mike@it-loops.com>
> > > > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> > >
> > > Applied.
> >
> > Obviously needs to go to stable as well.
>
> I don't think the buggy patch has made it to a release kernel
> yet.
>
> Thanks,
The bisected commit bd4265fe36 is in 3.0-rc4 but the input code
path still treats multicast and broadcast the same which means
there are some other possible cases where broadcast doesn't get
forwarded.
Wouldn't it make more sense to force input path to always forward
broadcasts. It would also save a lookup of mdb entry.
--- a/net/bridge/br_input.c 2011-07-05 22:28:30.111995701 -0700
+++ b/net/bridge/br_input.c 2011-07-05 22:34:08.259995671 -0700
@@ -77,7 +77,9 @@ int br_handle_frame_finish(struct sk_buf
dst = NULL;
- if (is_multicast_ether_addr(dest)) {
+ if (is_broadcast_ether_addr(dest))
+ skb2 = skb;
+ else if (is_multicast_ether_addr(dest)) {
mdst = br_mdb_get(br, skb);
if (mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) {
if ((mdst && mdst->mglist) ||
^ permalink raw reply
* Re: [PATCH v2] net: sched: constify tcf_proto and tc_action
From: David Miller @ 2011-07-06 5:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1309926765.2545.53.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Jul 2011 06:32:45 +0200
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: Herbert Xu @ 2011-07-06 5:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, mike, netdev
In-Reply-To: <20110705223551.5e1053af@nehalam.ftrdhcpuser.net>
On Tue, Jul 05, 2011 at 10:35:51PM -0700, Stephen Hemminger wrote:
>
> The bisected commit bd4265fe36 is in 3.0-rc4 but the input code
> path still treats multicast and broadcast the same which means
> there are some other possible cases where broadcast doesn't get
> forwarded.
AFAIK it worked properly prior to bd4265fe36 because broadcast
addresses simply get treated as an unregistered multicast group
and ends up being flooded.
So while yes we do do an extra mdb lookup I don't think there is
any visible problem in stable.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] net: sched: constify tcf_proto and tc_action
From: David Miller @ 2011-07-06 5:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20110705.223635.2008814218347412648.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 05 Jul 2011 22:36:35 -0700 (PDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 06 Jul 2011 06:32:45 +0200
>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied.
net/sched/cls_cgroup.c:279:2: warning: initialization from incompatible pointer type [enabled by default]
net/sched/cls_cgroup.c:279:2: warning: (near initialization for ‘cls_cgroup_ops.classify’) [enabled by default]
^ permalink raw reply
* Re: [PATCH v2] net: sched: constify tcf_proto and tc_action
From: David Miller @ 2011-07-06 5:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20110705.225633.2168272736556352902.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 05 Jul 2011 22:56:33 -0700 (PDT)
> From: David Miller <davem@davemloft.net>
> Date: Tue, 05 Jul 2011 22:36:35 -0700 (PDT)
>
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Wed, 06 Jul 2011 06:32:45 +0200
>>
>>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>>
>> Applied.
>
> net/sched/cls_cgroup.c:279:2: warning: initialization from incompatible pointer type [enabled by default]
> net/sched/cls_cgroup.c:279:2: warning: (near initialization for ‘cls_cgroup_ops.classify’) [enabled by default]
BTW, is is really so hard for people to do "allmodconfig"
builds?
You can take your chances the first time, but if you need to respin
because of warnings and breakage, the onus is on you to actually do a
real complete build regression test on your changes.
I shouldn't be the one hitting this stuff, you folks should.
^ permalink raw reply
* Re: [PATCH v2 0/3] Add device tree probe support for imx fec driver
From: Grant Likely @ 2011-07-06 6:19 UTC (permalink / raw)
To: David Miller
Cc: shawn.guo, netdev, devicetree-discuss, linux-arm-kernel, patches
In-Reply-To: <20110705.223045.738515407552627580.davem@davemloft.net>
On Tue, Jul 05, 2011 at 10:30:45PM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 05 Jul 2011 19:48:54 -0700 (PDT)
>
> > All applied to net-next-2.6, thanks.
>
> Come on guys:
>
> drivers/of/of_net.c: In function 'of_get_phy_mode':
> drivers/of/of_net.c:45: error: implicit declaration of function 'of_property_read_string'
>
> This is completely rediculious.
>
> Don't tell me that it's appropriate to merge something into
> my net tree when it uses interfaces that don't even exist
> in Linus's tree.
Sorry about that, I missed the reference to that function which is
currently in my devicetree/next branch. I can either take the series
via devicetree/next, or I can provide you with a topic branch
containing the needed commit that you can merge. Whichever you prefer.
g.
^ permalink raw reply
* Re: [PATCH v2 0/3] Add device tree probe support for imx fec driver
From: David Miller @ 2011-07-06 6:22 UTC (permalink / raw)
To: grant.likely
Cc: netdev, devicetree-discuss, shawn.guo, linux-arm-kernel, patches
In-Reply-To: <20110706061901.GH9978@ponder.secretlab.ca>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Wed, 6 Jul 2011 00:19:01 -0600
> Sorry about that, I missed the reference to that function which is
> currently in my devicetree/next branch. I can either take the series
> via devicetree/next, or I can provide you with a topic branch
> containing the needed commit that you can merge. Whichever you prefer.
Please just take the series, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/3] Add device tree probe support for imx fec driver
From: Grant Likely @ 2011-07-06 6:29 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patches-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <20110705.232252.897826991160254269.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, Jul 05, 2011 at 11:22:52PM -0700, David Miller wrote:
> From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Date: Wed, 6 Jul 2011 00:19:01 -0600
>
> > Sorry about that, I missed the reference to that function which is
> > currently in my devicetree/next branch. I can either take the series
> > via devicetree/next, or I can provide you with a topic branch
> > containing the needed commit that you can merge. Whichever you prefer.
>
> Please just take the series, thanks.
Will do.
g.
^ permalink raw reply
* [PATCH 1/2] net: sh_eth: fix cannot work half-duplex mode
From: Yoshihiro Shimoda @ 2011-07-06 6:33 UTC (permalink / raw)
To: davem; +Cc: netdev, SH-Linux
When link was down, the bit of DM in ECMR was always set.
So, we could not use half-duplex mode on the controller.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/net/sh_eth.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index 09b5aa8..c08d9e1 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -1185,8 +1185,8 @@ static void sh_eth_adjust_link(struct net_device *ndev)
mdp->cd->set_rate(ndev);
}
if (mdp->link == PHY_DOWN) {
- sh_eth_write(ndev, (sh_eth_read(ndev, ECMR) & ~ECMR_TXF)
- | ECMR_DM, ECMR);
+ sh_eth_write(ndev,
+ (sh_eth_read(ndev, ECMR) & ~ECMR_TXF), ECMR);
new_state = 1;
mdp->link = phydev->link;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] net: sh_eth: fix the parameter for the ETHER of SH7757
From: Yoshihiro Shimoda @ 2011-07-06 6:33 UTC (permalink / raw)
To: davem; +Cc: netdev, SH-Linux
If the driver didn't set this parameter on the ETHER, the CPU will
encounter the "data address error" exception.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/net/sh_eth.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index c08d9e1..93b347a 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -139,6 +139,8 @@ static struct sh_eth_cpu_data sh_eth_my_cpu_data = {
.tpauser = 1,
.hw_swap = 1,
.no_ade = 1,
+ .rpadir = 1,
+ .rpadir_value = 2 << 16,
};
#define SH_GIGA_ETH_BASE 0xfee00000
--
1.7.1
^ permalink raw reply related
* net-2.6 merged into net-next-2.6
From: David Miller @ 2011-07-06 6:38 UTC (permalink / raw)
To: netdev
Just FYI...
^ permalink raw reply
* Re: [PATCH 1/2] net: sh_eth: fix cannot work half-duplex mode
From: David Miller @ 2011-07-06 6:42 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4E1401CF.4080804@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed, 06 Jul 2011 15:33:51 +0900
> When link was down, the bit of DM in ECMR was always set.
> So, we could not use half-duplex mode on the controller.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: sh_eth: fix the parameter for the ETHER of SH7757
From: David Miller @ 2011-07-06 6:43 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4E1401D5.60506@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed, 06 Jul 2011 15:33:57 +0900
> If the driver didn't set this parameter on the ETHER, the CPU will
> encounter the "data address error" exception.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH v2 1/2] dcbnl: Aggregated CEE GET operation
From: David Miller @ 2011-07-06 6:43 UTC (permalink / raw)
To: shmulikr; +Cc: john.r.fastabend, netdev
In-Reply-To: <1309882582.22577.8.camel@lb-tlvb-shmulik.il.broadcom.com>
From: "Shmulik Ravid" <shmulikr@broadcom.com>
Date: Tue, 5 Jul 2011 19:16:22 +0300
> The following couple of patches add dcbnl an unsolicited notification of
> the the DCB configuration for the CEE flavor of the DCBX protocol. This
> is useful when the user-mode DCB client is not responsible for
> conducting and resolving the DCBX negotiation (either because the DCBX
> stack is embedded in the HW or the negotiation is handled by another
> agent in he host), but still needs to get the negotiated parameters.
> This functionality already exists for the IEEE flavor of the DCBX
> protocol and these patches add it to the older CEE flavor.
>
> The first patch extends the CEE attribute GET operation to include not
> only the peer information, but also all the pertinent local
> configuration (negotiated parameters). The second patch adds and export
> a CEE specific notification routine.
>
> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH v2 2/2] dcbnl: Add CEE notification
From: David Miller @ 2011-07-06 6:43 UTC (permalink / raw)
To: shmulikr; +Cc: john.r.fastabend, netdev
In-Reply-To: <1309882585.22577.9.camel@lb-tlvb-shmulik.il.broadcom.com>
From: "Shmulik Ravid" <shmulikr@broadcom.com>
Date: Tue, 5 Jul 2011 19:16:25 +0300
> This patch add an unsolicited notification of the DCBX negotiated
> parameters for the CEE flavor of the DCBX protocol. The notification
> message is identical to the aggregated CEE get operation and holds all
> the pertinent local and peer information. The notification routine is
> exported so it can be invoked by drivers supporting an embedded DCBX
> stack.
>
> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] AF_PACKET fanout support
From: David Miller @ 2011-07-06 6:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, victor, netdev, willemb
In-Reply-To: <1309925266.2545.48.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Jul 2011 06:07:46 +0200
> I suspect this can be solved adding a third policy : hash by CPU only
Agreed, I'll implement this policy.
^ permalink raw reply
* [PATCH] veth: Kill unused code label and code block.
From: David Miller @ 2011-07-06 6:49 UTC (permalink / raw)
To: netdev
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/veth.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 9eb92bf..19e0b0c 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -148,13 +148,6 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
-tx_drop:
- kfree_skb(skb);
- u64_stats_update_begin(&stats->syncp);
- stats->tx_dropped++;
- u64_stats_update_end(&stats->syncp);
- return NETDEV_TX_OK;
-
rx_drop:
u64_stats_update_begin(&rcv_stats->syncp);
rcv_stats->rx_dropped++;
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 0/2] AF_PACKET fanout support
From: David Miller @ 2011-07-06 6:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, victor, netdev, willemb
In-Reply-To: <20110705.234424.2099388019260070145.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 05 Jul 2011 23:44:24 -0700 (PDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 06 Jul 2011 06:07:46 +0200
>
>> I suspect this can be solved adding a third policy : hash by CPU only
>
> Agreed, I'll implement this policy.
packet: Add 'cpu' fanout policy.
Unfortunately we have to use a real modulus here as
the multiply trick won't work as effectively with cpu
numbers as it does with rxhash values.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/linux/if_packet.h b/include/linux/if_packet.h
index 84e684e..c148606 100644
--- a/include/linux/if_packet.h
+++ b/include/linux/if_packet.h
@@ -53,6 +53,7 @@ struct sockaddr_ll {
#define PACKET_FANOUT_HASH 0
#define PACKET_FANOUT_LB 1
+#define PACKET_FANOUT_CPU 2
#define PACKET_FANOUT_FLAG_DEFRAG 0x8000
struct tpacket_stats {
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 7ba6871..41f0489 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -447,6 +447,13 @@ static struct sock *fanout_demux_lb(struct packet_fanout *f, struct sk_buff *skb
return f->arr[cur];
}
+static struct sock *fanout_demux_cpu(struct packet_fanout *f, struct sk_buff *skb, unsigned int num)
+{
+ unsigned int cpu = smp_processor_id();
+
+ return f->arr[cpu % num];
+}
+
static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
{
const struct iphdr *iph;
@@ -482,8 +489,8 @@ static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
return skb;
}
-static int packet_rcv_fanout_hash(struct sk_buff *skb, struct net_device *dev,
- struct packet_type *pt, struct net_device *orig_dev)
+static int packet_rcv_fanout(struct sk_buff *skb, struct net_device *dev,
+ struct packet_type *pt, struct net_device *orig_dev)
{
struct packet_fanout *f = pt->af_packet_priv;
unsigned int num = f->num_members;
@@ -496,35 +503,25 @@ static int packet_rcv_fanout_hash(struct sk_buff *skb, struct net_device *dev,
return 0;
}
- if (f->defrag) {
- skb = fanout_check_defrag(skb);
- if (!skb)
- return 0;
- }
-
- skb_get_rxhash(skb);
-
- sk = fanout_demux_hash(f, skb, num);
- po = pkt_sk(sk);
-
- return po->prot_hook.func(skb, dev, &po->prot_hook, orig_dev);
-}
-
-static int packet_rcv_fanout_lb(struct sk_buff *skb, struct net_device *dev,
- struct packet_type *pt, struct net_device *orig_dev)
-{
- struct packet_fanout *f = pt->af_packet_priv;
- unsigned int num = f->num_members;
- struct packet_sock *po;
- struct sock *sk;
-
- if (!net_eq(dev_net(dev), read_pnet(&f->net)) ||
- !num) {
- kfree_skb(skb);
- return 0;
+ switch (f->type) {
+ case PACKET_FANOUT_HASH:
+ default:
+ if (f->defrag) {
+ skb = fanout_check_defrag(skb);
+ if (!skb)
+ return 0;
+ }
+ skb_get_rxhash(skb);
+ sk = fanout_demux_hash(f, skb, num);
+ break;
+ case PACKET_FANOUT_LB:
+ sk = fanout_demux_lb(f, skb, num);
+ break;
+ case PACKET_FANOUT_CPU:
+ sk = fanout_demux_cpu(f, skb, num);
+ break;
}
- sk = fanout_demux_lb(f, skb, num);
po = pkt_sk(sk);
return po->prot_hook.func(skb, dev, &po->prot_hook, orig_dev);
@@ -571,6 +568,7 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
switch (type) {
case PACKET_FANOUT_HASH:
case PACKET_FANOUT_LB:
+ case PACKET_FANOUT_CPU:
break;
default:
return -EINVAL;
@@ -606,14 +604,7 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
atomic_set(&match->sk_ref, 0);
match->prot_hook.type = po->prot_hook.type;
match->prot_hook.dev = po->prot_hook.dev;
- switch (type) {
- case PACKET_FANOUT_HASH:
- match->prot_hook.func = packet_rcv_fanout_hash;
- break;
- case PACKET_FANOUT_LB:
- match->prot_hook.func = packet_rcv_fanout_lb;
- break;
- }
+ match->prot_hook.func = packet_rcv_fanout;
match->prot_hook.af_packet_priv = match;
dev_add_pack(&match->prot_hook);
list_add(&match->list, &fanout_list);
^ permalink raw reply related
* Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown
From: David Miller @ 2011-07-06 7:24 UTC (permalink / raw)
To: tgraf; +Cc: vladislav.yasevich, netdev, yjwei, sri, linux-sctp
In-Reply-To: <20110704135019.GA801@canuck.infradead.org>
Vlad, SCTP folks, please review this patch.
^ permalink raw reply
* RE: [PATCH net-next 2/6] r8169: modify the flow hw reset
From: hayeswang @ 2011-07-06 7:48 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20110705185515.GB5105@electric-eye.fr.zoreil.com>
> -----Original Message-----
> From: Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Wednesday, July 06, 2011 2:55 AM
> To: Hayeswang
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 2/6] r8169: modify the flow hw reset
>
> >
> > +static void rtl_rx_close(struct rtl8169_private *tp) {
> > + void __iomem *ioaddr = tp->mmio_addr;
> > + u32 rxcfg = RTL_R32(RxConfig);
> > +
> > + rxcfg &= ~(AcceptBroadcast | AcceptMulticast |
> > + AcceptMyPhys | AcceptAllPhys);
> > + RTL_W32(RxConfig, rxcfg);
> > +}
> > +
>
> Should not error and runt packets be considered too ?
>
> <shot in the dark>
> Is there any relationship with commit
> ca52efd5490f97f396d3c5863ba714624f272033 ?
> </shot in the dark>
>
No, there is no relationship about that.
^ permalink raw reply
* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: Michael Guntsche @ 2011-07-06 7:57 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, davem
In-Reply-To: <20110705235833.GA5599@gondor.apana.org.au>
On 06 Jul 11 07:58, Herbert Xu wrote:
> Michael Guntsche <mike@it-loops.com> wrote:
> >
> > Looking at the changes between rc5 and rc6 I noticed commit
> >
> > bd4265fe365c0f3945d: bridge: Only flood unregistered groups to routers
>
> Oops, that was definitely my fault. This patch should fix your
> problem.
Good morning,
I can confirm that this fixes the issues I am seeing. The Bridge sees
the DHCP packets again.
Thank you very much for the quick fix,
Michael
^ permalink raw reply
* [PATCH net-next v2 1/7] r8169: adjust some registers
From: Hayes Wang @ 2011-07-06 7:58 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Define new registers and modify some existing ones.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 43 +++++++++++++++++++++++++++----------------
1 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index fbd6838..a8de449 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -70,8 +70,6 @@ static const int multicast_filter_limit = 32;
#define MAC_ADDR_LEN 6
#define MAX_READ_REQUEST_SHIFT 12
-#define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */
-#define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
#define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
#define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */
#define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */
@@ -270,9 +268,20 @@ enum rtl_registers {
TxPoll = 0x38,
IntrMask = 0x3c,
IntrStatus = 0x3e,
+
TxConfig = 0x40,
- RxConfig = 0x44,
+#define TXCFG_AUTO_FIFO (1 << 7) /* 8111e-vl */
+#define TXCFG_EMPTY (1 << 11) /* 8111e-vl */
+ RxConfig = 0x44,
+#define RX128_INT_EN (1 << 15) /* 8111c and later */
+#define RX_MULTI_EN (1 << 14) /* 8111c only */
+#define RXCFG_FIFO_SHIFT 13
+ /* No threshold before first PCI xfer. */
+#define RX_FIFO_THRESH (7 << RXCFG_FIFO_SHIFT)
+#define RXCFG_DMA_SHIFT 8
+ /* Unlimited maximum PCI burst. */
+#define RX_DMA_BURST (7 << RXCFG_DMA_SHIFT)
#define RTL_RX_CONFIG_MASK 0xff7e1880u
RxMissed = 0x4c,
@@ -327,12 +336,13 @@ enum rtl8168_8101_registers {
#define EPHYAR_REG_SHIFT 16
#define EPHYAR_DATA_MASK 0xffff
DLLPR = 0xd0,
-#define PM_SWITCH (1 << 6)
+#define PFM_EN (1 << 6)
DBG_REG = 0xd1,
#define FIX_NAK_1 (1 << 4)
#define FIX_NAK_2 (1 << 3)
TWSI = 0xd2,
MCU = 0xd3,
+#define NOW_IS_OOB (1 << 7)
#define EN_NDP (1 << 3)
#define EN_OOB_RESET (1 << 2)
EFUSEAR = 0xdc,
@@ -345,18 +355,22 @@ enum rtl8168_8101_registers {
};
enum rtl8168_registers {
+ LED_FREQ = 0x1a,
+ EEE_LED = 0x1b,
ERIDR = 0x70,
ERIAR = 0x74,
#define ERIAR_FLAG 0x80000000
#define ERIAR_WRITE_CMD 0x80000000
#define ERIAR_READ_CMD 0x00000000
#define ERIAR_ADDR_BYTE_ALIGN 4
-#define ERIAR_EXGMAC 0
-#define ERIAR_MSIX 1
-#define ERIAR_ASF 2
#define ERIAR_TYPE_SHIFT 16
-#define ERIAR_BYTEEN 0x0f
-#define ERIAR_BYTEEN_SHIFT 12
+#define ERIAR_EXGMAC (0x00 << ERIAR_TYPE_SHIFT)
+#define ERIAR_MSIX (0x01 << ERIAR_TYPE_SHIFT)
+#define ERIAR_ASF (0x02 << ERIAR_TYPE_SHIFT)
+#define ERIAR_MASK_SHIFT 12
+#define ERIAR_MASK_0001 (0x1 << ERIAR_MASK_SHIFT)
+#define ERIAR_MASK_0011 (0x3 << ERIAR_MASK_SHIFT)
+#define ERIAR_MASK_1111 (0xf << ERIAR_MASK_SHIFT)
EPHY_RXER_NUM = 0x7c,
OCPDR = 0xb0, /* OCP GPHY access */
#define OCPDR_WRITE_CMD 0x80000000
@@ -371,6 +385,7 @@ enum rtl8168_registers {
RDSAR1 = 0xd0, /* 8168c only. Undocumented on 8168dp */
MISC = 0xf0, /* 8168e only. */
#define TXPLA_RST (1 << 29)
+#define PWM_EN (1 << 22)
};
enum rtl_register_content {
@@ -395,6 +410,7 @@ enum rtl_register_content {
RxCRC = (1 << 19),
/* ChipCmdBits */
+ StopReq = 0x80,
CmdReset = 0x10,
CmdRxEnb = 0x08,
CmdTxEnb = 0x04,
@@ -417,10 +433,6 @@ enum rtl_register_content {
AcceptMyPhys = 0x02,
AcceptAllPhys = 0x01,
- /* RxConfigBits */
- RxCfgFIFOShift = 13,
- RxCfgDMAShift = 8,
-
/* TxConfigBits */
TxInterFrameGapShift = 24,
TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */
@@ -712,8 +724,7 @@ static void rtl8169_down(struct net_device *dev);
static void rtl8169_rx_clear(struct rtl8169_private *tp);
static int rtl8169_poll(struct napi_struct *napi, int budget);
-static const unsigned int rtl8169_rx_config =
- (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift);
+static const unsigned int rtl8169_rx_config = RX_FIFO_THRESH | RX_DMA_BURST;
static u32 ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
{
@@ -4368,7 +4379,7 @@ static void rtl_hw_start_8105e_1(void __iomem *ioaddr, struct pci_dev *pdev)
RTL_W32(FuncEvent, RTL_R32(FuncEvent) & ~0x010000);
RTL_W8(MCU, RTL_R8(MCU) | EN_NDP | EN_OOB_RESET);
- RTL_W8(DLLPR, RTL_R8(DLLPR) | PM_SWITCH);
+ RTL_W8(DLLPR, RTL_R8(DLLPR) | PFM_EN);
rtl_ephy_init(ioaddr, e_info_8105e_1, ARRAY_SIZE(e_info_8105e_1));
}
--
1.7.3.2
^ permalink raw reply related
* [PATCH net-next v2 2/7] r8169: modify the flow of the hw reset
From: Hayes Wang @ 2011-07-06 7:58 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1309939088-31994-1-git-send-email-hayeswang@realtek.com>
-Disable tx and rx by resetting hw, so replace rtl8169_asic_down with
rtl8169_hw_reset.
-RxConfig bits 0 ~ 5 have to be clear before hw reset to avoid the
coming of rx data.
-Certain chips need to do some checking before reset.
-Remove hw reset which is done before hw_start, because it would be
done in close or down functions.
-Move rtl8169_init_ring_indexes function into rtl_hw_reset function.
The indexes of tx and rx need to be zero only when the hw reset
occures.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 53 ++++++++++++++++++++++++++------------------------
1 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index a8de449..a579da0 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1071,13 +1071,6 @@ static void rtl8169_irq_mask_and_ack(void __iomem *ioaddr)
RTL_W16(IntrStatus, 0xffff);
}
-static void rtl8169_asic_down(void __iomem *ioaddr)
-{
- RTL_W8(ChipCmd, 0x00);
- rtl8169_irq_mask_and_ack(ioaddr);
- RTL_R16(CPlusCmd);
-}
-
static unsigned int rtl8169_tbi_reset_pending(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -3337,6 +3330,11 @@ static void __devinit rtl_init_pll_power_ops(struct rtl8169_private *tp)
}
}
+static void rtl8169_init_ring_indexes(struct rtl8169_private *tp)
+{
+ tp->dirty_tx = tp->dirty_rx = tp->cur_tx = tp->cur_rx = 0;
+}
+
static void rtl_hw_reset(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -3349,8 +3347,10 @@ static void rtl_hw_reset(struct rtl8169_private *tp)
for (i = 0; i < 100; i++) {
if ((RTL_R8(ChipCmd) & CmdReset) == 0)
break;
- msleep_interruptible(1);
+ udelay(100);
}
+
+ rtl8169_init_ring_indexes(tp);
}
static int __devinit
@@ -3732,6 +3732,16 @@ err_pm_runtime_put:
goto out;
}
+static void rtl_rx_close(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ u32 rxcfg = RTL_R32(RxConfig);
+
+ rxcfg &= ~(AcceptErr | AcceptRunt | AcceptBroadcast | AcceptMulticast |
+ AcceptMyPhys | AcceptAllPhys);
+ RTL_W32(RxConfig, rxcfg);
+}
+
static void rtl8169_hw_reset(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -3739,19 +3749,19 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
/* Disable interrupts */
rtl8169_irq_mask_and_ack(ioaddr);
+ rtl_rx_close(tp);
+
if (tp->mac_version == RTL_GIGA_MAC_VER_27 ||
tp->mac_version == RTL_GIGA_MAC_VER_28 ||
tp->mac_version == RTL_GIGA_MAC_VER_31) {
while (RTL_R8(TxPoll) & NPQ)
udelay(20);
-
+ } else {
+ RTL_W8(ChipCmd, RTL_R8(ChipCmd) | StopReq);
+ udelay(100);
}
- /* Reset the chipset */
- RTL_W8(ChipCmd, CmdReset);
-
- /* PCI commit */
- RTL_R8(ChipCmd);
+ rtl_hw_reset(tp);
}
static void rtl_set_rx_tx_config_registers(struct rtl8169_private *tp)
@@ -3771,8 +3781,6 @@ static void rtl_hw_start(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
- rtl_hw_reset(tp);
-
tp->hw_start(dev);
netif_start_queue(dev);
@@ -4581,11 +4589,6 @@ err_out:
return -ENOMEM;
}
-static void rtl8169_init_ring_indexes(struct rtl8169_private *tp)
-{
- tp->dirty_tx = tp->dirty_rx = tp->cur_tx = tp->cur_rx = 0;
-}
-
static int rtl8169_init_ring(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -4713,7 +4716,7 @@ static void rtl8169_reset_task(struct work_struct *work)
rtl8169_tx_clear(tp);
- rtl8169_init_ring_indexes(tp);
+ rtl8169_hw_reset(tp);
rtl_hw_start(dev);
netif_wake_queue(dev);
rtl8169_check_link_status(dev, tp, tp->mmio_addr);
@@ -5127,7 +5130,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
* the chip, so just exit the loop.
*/
if (unlikely(!netif_running(dev))) {
- rtl8169_asic_down(ioaddr);
+ rtl8169_hw_reset(tp);
break;
}
@@ -5250,7 +5253,7 @@ static void rtl8169_down(struct net_device *dev)
spin_lock_irq(&tp->lock);
- rtl8169_asic_down(ioaddr);
+ rtl8169_hw_reset(tp);
/*
* At this point device interrupts can not be enabled in any function,
* as netif_running is not true (rtl8169_interrupt, rtl8169_reset_task,
@@ -5504,7 +5507,7 @@ static void rtl_shutdown(struct pci_dev *pdev)
spin_lock_irq(&tp->lock);
- rtl8169_asic_down(ioaddr);
+ rtl8169_hw_reset(tp);
spin_unlock_irq(&tp->lock);
--
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