* Re: [PATCH] net/fec: gasket needs to be enabled for some i.mx
From: Shawn Guo @ 2011-07-06 5:14 UTC (permalink / raw)
To: Sascha Hauer
Cc: Shawn Guo, netdev, linux-arm-kernel, u.kleine-koenig, LW,
Troy Kisky, David S. Miller
In-Reply-To: <20110704065523.GX6069@pengutronix.de>
On Mon, Jul 04, 2011 at 08:55:23AM +0200, Sascha Hauer wrote:
> David,
>
> On Fri, Jul 01, 2011 at 06:11:22PM +0800, Shawn Guo wrote:
> > On the recent i.mx (mx25/50/53), there is a gasket inside fec
> > controller which needs to be enabled no matter phy works in MII
> > or RMII mode.
> >
> > The current code enables the gasket only when phy interface is RMII.
> > It's broken when the driver works with a MII phy. The patch uses
> > platform_device_id to distinguish the SoCs that have the gasket and
> > enables it on these SoCs for both MII and RMII mode.
> >
> > Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > arch/arm/mach-imx/clock-imx25.c | 2 +-
> > arch/arm/mach-imx/clock-imx27.c | 2 +-
> > arch/arm/mach-imx/clock-imx35.c | 2 +-
> > arch/arm/mach-mx5/clock-mx51-mx53.c | 4 +-
> > arch/arm/plat-mxc/devices/platform-fec.c | 17 ++++++++-------
> > arch/arm/plat-mxc/include/mach/devices-common.h | 1 +
> > drivers/net/fec.c | 26 ++++++++++++++++++++--
>
> I either need your Ack for this or we need to split this up into two
> patches. Pushing this through the net tree is probably not a good idea.
>
I need to do another rebase on 'next' as David just applied the dt
series.
--
Regards,
Shawn
^ permalink raw reply
* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: Herbert Xu @ 2011-07-06 5:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, mike, netdev
In-Reply-To: <20110705220636.6afeb81c@nehalam.ftrdhcpuser.net>
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,
--
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 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
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