* Re: [PATCH] stmmac: Don't init ptp again when resume fromsuspend/hibernation
From: 陈华才 @ 2014-12-19 2:10 UTC (permalink / raw)
To: David Miller; +Cc: peppe.cavallaro, vbridgers2013, netdev, stable
In-Reply-To: <20141218.153650.2242996610693466579.davem@davemloft.net>
I have CC netdev@vger.kernel.org, but I don't know why it didn't reach the maillist...
Anyway, I will resend the patch.
Huacai
------------------ Original ------------------
From: "David Miller"<davem@davemloft.net>;
Date: Fri, Dec 19, 2014 04:36 AM
To: "chenhc"<chenhc@lemote.com>;
Cc: "peppe.cavallaro"<peppe.cavallaro@st.com>; "vbridgers2013"<vbridgers2013@gmail.com>; "netdev"<netdev@vger.kernel.org>; "stable"<stable@vger.kernel.org>;
Subject: Re: [PATCH] stmmac: Don't init ptp again when resume fromsuspend/hibernation
Two problems:
1) This post did not reach netdev and therefore did not make it into
patchwork for tracking. You need to correct this.
2) Do not CC: stable on networking changes, instead ask me explicitly
to queue them up for -stable submission and to which trees.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/5] tcp: TCP tracer
From: Yuchung Cheng @ 2014-12-19 1:42 UTC (permalink / raw)
To: Lawrence Brakmo
Cc: Josef Bacik, Alexei Starovoitov, Martin Lau, Eric Dumazet,
Blake Matheny, Laurent Chavey, netdev@vger.kernel.org,
David S. Miller, Hannes Frederic Sowa, Steven Rostedt,
Kernel Team
In-Reply-To: <D0B86A04.1B29%brakmo@fb.com>
On Thu, Dec 18, 2014 at 3:43 PM, Lawrence Brakmo <brakmo@fb.com> wrote:
>
>
> On 12/17/14, 1:42 PM, "Josef Bacik" <jbacik@fb.com> wrote:
>
> >>>> It feels that for stats collection only, tracepoints+tcp_trace
> >>>> do not add much additional value vs extending tcp_info
> >>>> and using ss.
> >>> I think we are on the same page. Once 'this should cost nothing if not
> >>> activated' proposition was cleared out. It was what I meant that
> >>>doing the
> >>> collection part in the TCP itself (instead of tracepoints) would be
> >>>nice.
> >>
> >> agree.
> >>
> >>> I think going forward, as others have suggested, it may be better to
> >>>come
> >>> together and reach a common ground on what to collect first before I
> >>>re-work
> >>> patch 1 to 3 and repost.
> >>
> >> I think as a minimum it will be discussed at netdev01 in Feb,
> >> but I suspect not everyone on this list can(want) go to Ottawa,
> >> so would be nice to have a meetup for bay area folks to
> >> discuss this sooner with public g+ hangout.
> >> Thoughts?
> >>
> >
> >Yeah I think we're all in agreement that this is a good netdev01
> >discussion. I'm happy to include people who want to talk about this
> >before hand in the bay area meetup we're throwing, but it seems like
> >this is going to be something that the larger community is going to want
> >to talk about so it may be more productive to wait until netdev01.
> >Thanks,
>
>
> Josef: I think a preliminary discussion during the bay area meet up would
> be useful to get some of us in sync.
>
> There are two issues going on. One is the collection of statistics that
> can be read every-so-often and another is the issue of enabling easier
> tracing of TCP state for analysis and debugging.
>
> For statistics collection, extending tcp_info is a viable option although
> we may need to do some modifications to deal with: (1) Having many
> connections most of which are idle. We need an option to only output those
> whose stats have changed since the last read. (2) A mechanism to deal with
> closed connections and their stats. Note that in our current setup neither
> of these is an issue for us.
>
> For tracing and event collection, I see a lot of value in tracepoints that
> could print basic info with perf but also allow us to do more complex
> things by loading a module that hooks to the tracepoints. This is one way
> to set up triggers to collect state for a particular flow.
>
> Yuchung: I agree that a lot of information can be obtained through
> analysis of tcpdumps, but some internal state must be inferred and in many
> instances we can only get bounds.
Hi Larry :)
I definitely see values in tracepoints. I was responding to the commit
message in patch 5/5: "Uncover uplink/backbone/subnet issue, e.g. by
tracking the rxmit rate.". First ss and tcp_info can collect that
data. But rxmit rate is often not enough for diagnosis. One needs to
inspect the loss patterns from packet traces. I am sure you know what
I am talking about.
>
> - Larry
>
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Thomas Graf @ 2014-12-19 0:45 UTC (permalink / raw)
To: Varlese, Marco
Cc: Roopa Prabhu, netdev@vger.kernel.org, Fastabend, John R,
Jiri Pirko, sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104ADA310@IRSMSX108.ger.corp.intel.com>
On 12/18/14 at 06:02pm, Varlese, Marco wrote:
> Roopa, one of the comments I got from Thomas Graf on my v1 patch was that your patch and mine were supplementary ("I think Roopa's patches are supplementary. Not all switchdev users will be backed with a Linux Bridge. I therefore welcome your patches very much")... I also understood by others that the patch made sense for the same reason. I simply do not understand why these attributes (and maybe others in the future) could not be configured directly on a standard port but have to go through a bridge.
Apologies for this confusion. I take that back. I was under the
impression netdev_switch_port_bridge_setlink(), based on the "bridge"
in the function name, would derive the attributes based on capabilities
and assumption of the bridge module.
This is not the case in the latest patchset proposed so it could
indeed serve as the Netlink API for both the bridge and non bridge
case.
^ permalink raw reply
* Re: [RFC PATCH net-next v3 1/1] net: Support for switch port configuration
From: Thomas Graf @ 2014-12-19 0:35 UTC (permalink / raw)
To: John Fastabend
Cc: Varlese, Marco, netdev@vger.kernel.org, Fastabend, John R,
Jiri Pirko, roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <5492FAD4.7070308@gmail.com>
On 12/18/14 at 08:03am, John Fastabend wrote:
> On 12/18/2014 07:30 AM, Varlese, Marco wrote:
> Could you also document the attributes. I think they are mostly
> clear but what is IFLA_SW_LOOPBACK. It will help later when we
> try to read the code in 6months and implement drivers.
>
> I am thinking something like
>
> /* Switch Port Attributes section
> * IFLA_SW_LEARNING - turns learning on in the bridge
> * IFLA_SW_LOOPBACK - does something interesting
>
> [...]
> */
+1. I would even ask for more than that. While clear in the bridge
context, "learning" for this API targetting multi layer switches
is ambigious. The expectation towards the driver must be crystical
clear.
> >+
> >+enum {
> >+ IFLA_SW_UNSPEC,
> >+ IFLA_SW_LEARNING,
>
> Can you address Roopa's feedback. I'm also a bit confused by the
> duplication.
Agreed. Can we decide on the ndo first and then build the APIs on
top of that? While I agree that we should have a non-bridge based
Netlink API, the underlying ndo should be the same.
> >+static const struct nla_policy ifla_sw_attr_policy[IFLA_SW_ATTR_MAX+1] = {
> >+ [IFLA_SW_LEARNING] = { .type = NLA_U64 },
> >+ [IFLA_SW_LOOPBACK] = { .type = NLA_U64 },
> >+ [IFLA_SW_BCAST_FLOODING] = { .type = NLA_U64 },
> >+ [IFLA_SW_UCAST_FLOODING] = { .type = NLA_U64 },
> >+ [IFLA_SW_MCAST_FLOODING] = { .type = NLA_U64 },
> >+};
>
> Why U64 values? What would we pass in these? Are these just boolean
> bits? Maybe the annotation above will help me understand this.
I think the intent is to keep the ndo API as simple as possible
but I agree that this is wasteful. I gave this feedback on v2 already.
^ permalink raw reply
* [PATCH] Fixed TPACKET V3 to signal poll when block is closed rather than every packet
From: Dan Collins @ 2014-12-19 0:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Dan
From: Dan <dan@dcollins.co.nz>
Make TPACKET_V3 signal poll when block is closed rather than for every
packet. Side effect is that poll will be signaled when block retire
timer expires which didn't previously happen. Issue was visible when
sending packets at a very low frequency such that all blocks are retired
before packets are received by TPACKET_V3. This caused avoidable packet
loss. The fix ensures that the signal is sent when blocks are closed
which covers the normal path where the block is filled as well as the
path where the timer expires. The case where a block is filled without
moving to the next block (ie. all blocks are full) will still cause poll
to be signaled.
Signed-off-by: Dan Collins <dan@dcollins.co.nz>
---
net/packet/af_packet.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e52a447..14e883d 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -43,6 +43,8 @@
* Chetan Loke : Implemented TPACKET_V3 block abstraction
* layer.
* Copyright (C) 2011, <lokec@ccs.neu.edu>
+ * Dan Collins : Fixed TPACKET_V3 to wake poll when block is closed
+ * rather than for every packet.
*
*
* This program is free software; you can redistribute it and/or
@@ -785,6 +787,7 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
struct tpacket3_hdr *last_pkt;
struct tpacket_hdr_v1 *h1 = &pbd1->hdr.bh1;
+ struct sock *sk = &po->sk;
if (po->stats.stats3.tp_drops)
status |= TP_STATUS_LOSING;
@@ -809,6 +812,8 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
/* Flush the block */
prb_flush_block(pkc1, pbd1, status);
+ sk->sk_data_ready(sk);
+
pkc1->kactive_blk_num = GET_NEXT_PRB_BLK_NUM(pkc1);
}
@@ -2052,12 +2057,12 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
smp_wmb();
#endif
- if (po->tp_version <= TPACKET_V2)
+ if (po->tp_version <= TPACKET_V2) {
__packet_set_status(po, h.raw, status);
- else
+ sk->sk_data_ready(sk);
+ } else {
prb_clear_blk_fill_status(&po->rx_ring);
-
- sk->sk_data_ready(sk);
+ }
drop_n_restore:
if (skb_head != skb->data && skb_shared(skb)) {
--
2.1.3
^ permalink raw reply related
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Roopa Prabhu @ 2014-12-18 23:48 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: John Fastabend, Varlese, Marco, netdev@vger.kernel.org,
Thomas Graf, Jiri Pirko, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <549362A5.3000808@intel.com>
On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote:
>
> On 12/18/2014 3:07 PM, Roopa Prabhu wrote:
>> On 12/18/14, 11:21 AM, John Fastabend wrote:
>>> On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
>>>> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>>>>> Removed unnecessary content for ease of reading...
>>>>>
>>>>>>>>>>> +/* Switch Port Attributes section */
>>>>>>>>>>> +
>>>>>>>>>>> +enum {
>>>>>>>>>>> + IFLA_ATTR_UNSPEC,
>>>>>>>>>>> + IFLA_ATTR_LEARNING,
>>>>>>>>>> Any reason you want learning here ?. This is covered as part of
>>>>>>>>>> the bridge setlink attributes.
>>>>>>>>>>
>>>>>>>>> Yes, because the user may _not_ want to go through a bridge
>>>>>>>>> interface
>>>>>>>> necessarily.
>>>>>>>> But, the bridge setlink/getlink interface was changed to
>>>>>>>> accommodate
>>>>>> 'self'
>>>>>>>> for exactly such cases.
>>>>>>>> I kind of understand your case for the other attributes (these are
>>>>>>>> per port settings that switch asics provide).
>>>>>>>>
>>>>>>>> However, i don't understand the reason to pull in bridge
>>>>>>>> attributes here.
>>>>>>>>
>>>>>>> Maybe, I am missing something so you might help. The learning
>>>>>>> attribute -
>>>>>> in my case - it is like all other attributes: a port attribute
>>>>>> (as you said, port
>>>>>> settings that the switch provides per port).
>>>>>>> So, what I was saying is "why the user shall go through a bridge
>>>>>>> to configure
>>>>>> the learning attribute"? From my perspective, it is as any other
>>>>>> attribute and
>>>>>> as such configurable on the port.
>>>>>>
>>>>>> Thinking about this some more, i don't see why any of these
>>>>>> attributes
>>>>>> (except loopback. I dont understand the loopback attribute) cant
>>>>>> be part of
>>>>>> the birdge port attributes.
>>>>>>
>>>>>> With this we will end up adding l2 attributes in two places: the
>>>>>> general link
>>>>>> attributes and bridge attributes.
>>>>>>
>>>>>> And since we have gone down the path of using
>>>>>> ndo_bridge_setlink/getlink
>>>>>> with 'self'....we should stick to that for all l2 attributes.
>>>>>>
>>>>>> The idea of overloading ndo_bridge_set/getlink, was to have the
>>>>>> same set of
>>>>>> attributes but support both cases where the user wants to go
>>>>>> through the
>>>>>> bridge driver or directly to the switch port driver. So, you are
>>>>>> not really going
>>>>>> through the bridge driver if you use 'self' and
>>>>>> ndo_bridge_setlink/getlink.
>>>>>>
>>>>> Roopa, one of the comments I got from Thomas Graf on my v1 patch
>>>>> was that your patch and mine were supplementary ("I think Roopa's
>>>>> patches are supplementary. Not all switchdev users will be backed
>>>>> with a Linux Bridge. I therefore welcome your patches very
>>>>> much")... I also understood by others that the patch made sense for
>>>>> the same reason. I simply do not understand why these attributes
>>>>> (and maybe others in the future) could not be configured directly
>>>>> on a standard port but have to go through a bridge.
>>>>>
>>>> ok, i am very confused in that case. The whole moving of bridge
>>>> attributes from the bridge driver to rtnetlink.c was to make the
>>>> bridge attributes accessible to any driver who wants to set l2/bridge
>>>> attributes on their switch ports. So, its unclear to me why we are
>>>> doing this parallel thing again. This move to rtnetlink.c was done
>>>> during the recent rocker support. so, maybe scott/jiri can elaborate
>>>> more.
>>>
>>> Not sure if this will add to the confusion or help. But you do not
>>> need to have the bridge.ko loaded or netdev's attached to a bridge
>>> to use the setlink/getlink ndo ops and netlink messages.
>>>
>>> This was intentionally done. Its already used with NIC devices to
>>> configure embedded bridge settings such as VEB/VEPA.
>>
>> that helps my case, thanks.
>
> So the user interface to set/get the per-port attributes will be via
> 'bridge', not 'ip'
>
> bridge link set dev sw0p1 port_attr bcast_flooding 1 self
> bridge link get dev sw0p1 port_attr bcast_flooding self
yes, l2 attributes.
>
> We also need an interface to set per-switch attributes. Can this work?
> bridge link set dev sw0 sw_attr bcast_flooding 1 master
> where sw0 is a bridge representing the hardware switch.
Not today. We discussed this @ LPC, and one way to do this would be to
have a device
representing the switch asic. This is in the works.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/5] tcp: TCP tracer
From: Lawrence Brakmo @ 2014-12-18 23:43 UTC (permalink / raw)
To: Josef Bacik, Alexei Starovoitov, Martin Lau
Cc: Eric Dumazet, Blake Matheny, Laurent Chavey, Yuchung Cheng,
netdev@vger.kernel.org, David S. Miller, Hannes Frederic Sowa,
Steven Rostedt, Kernel Team
In-Reply-To: <5491F8D1.2090103@fb.com>
On 12/17/14, 1:42 PM, "Josef Bacik" <jbacik@fb.com> wrote:
>>>> It feels that for stats collection only, tracepoints+tcp_trace
>>>> do not add much additional value vs extending tcp_info
>>>> and using ss.
>>> I think we are on the same page. Once 'this should cost nothing if not
>>> activated' proposition was cleared out. It was what I meant that
>>>doing the
>>> collection part in the TCP itself (instead of tracepoints) would be
>>>nice.
>>
>> agree.
>>
>>> I think going forward, as others have suggested, it may be better to
>>>come
>>> together and reach a common ground on what to collect first before I
>>>re-work
>>> patch 1 to 3 and repost.
>>
>> I think as a minimum it will be discussed at netdev01 in Feb,
>> but I suspect not everyone on this list can(want) go to Ottawa,
>> so would be nice to have a meetup for bay area folks to
>> discuss this sooner with public g+ hangout.
>> Thoughts?
>>
>
>Yeah I think we're all in agreement that this is a good netdev01
>discussion. I'm happy to include people who want to talk about this
>before hand in the bay area meetup we're throwing, but it seems like
>this is going to be something that the larger community is going to want
>to talk about so it may be more productive to wait until netdev01.
>Thanks,
Josef: I think a preliminary discussion during the bay area meet up would
be useful to get some of us in sync.
There are two issues going on. One is the collection of statistics that
can be read every-so-often and another is the issue of enabling easier
tracing of TCP state for analysis and debugging.
For statistics collection, extending tcp_info is a viable option although
we may need to do some modifications to deal with: (1) Having many
connections most of which are idle. We need an option to only output those
whose stats have changed since the last read. (2) A mechanism to deal with
closed connections and their stats. Note that in our current setup neither
of these is an issue for us.
For tracing and event collection, I see a lot of value in tracepoints that
could print basic info with perf but also allow us to do more complex
things by loading a module that hooks to the tracepoints. This is one way
to set up triggers to collect state for a particular flow.
Yuchung: I agree that a lot of information can be obtained through
analysis of tcpdumps, but some internal state must be inferred and in many
instances we can only get bounds.
- Larry
^ permalink raw reply
* [PATCH] net: eth: xgene: change APM X-Gene SoC platform ethernet to support ACPI
From: Feng Kan @ 2014-12-18 23:39 UTC (permalink / raw)
To: davem, netdev, patches, linux-kernel; +Cc: Feng Kan
This adds support for APM X-Gene ethernet driver to use ACPI table to derive
ethernet driver parameter.
Signed-off-by: Feng Kan <fkan@apm.com>
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 94 +++++++++++++++++------
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 96 +++++++++++++++++++-----
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 3 +
3 files changed, 150 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 7ba83ff..869d97f 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -593,10 +593,12 @@ static int xgene_enet_reset(struct xgene_enet_pdata *pdata)
if (!xgene_ring_mgr_init(pdata))
return -ENODEV;
- clk_prepare_enable(pdata->clk);
- clk_disable_unprepare(pdata->clk);
- clk_prepare_enable(pdata->clk);
- xgene_enet_ecc_init(pdata);
+ if (!efi_enabled(EFI_BOOT)) {
+ clk_prepare_enable(pdata->clk);
+ clk_disable_unprepare(pdata->clk);
+ clk_prepare_enable(pdata->clk);
+ xgene_enet_ecc_init(pdata);
+ }
xgene_enet_config_ring_if_assoc(pdata);
/* Enable auto-incr for scanning */
@@ -663,15 +665,20 @@ static int xgene_enet_phy_connect(struct net_device *ndev)
struct phy_device *phy_dev;
struct device *dev = &pdata->pdev->dev;
- phy_np = of_parse_phandle(dev->of_node, "phy-handle", 0);
- if (!phy_np) {
- netdev_dbg(ndev, "No phy-handle found\n");
- return -ENODEV;
+ if (dev->of_node) {
+ phy_np = of_parse_phandle(dev->of_node, "phy-handle", 0);
+ if (!phy_np) {
+ netdev_dbg(ndev, "No phy-handle found in DT\n");
+ return -ENODEV;
+ }
+ pdata->phy_dev = of_phy_find_device(phy_np);
}
- phy_dev = of_phy_connect(ndev, phy_np, &xgene_enet_adjust_link,
- 0, pdata->phy_mode);
- if (!phy_dev) {
+ phy_dev = pdata->phy_dev;
+
+ if (!phy_dev ||
+ phy_connect_direct(ndev, phy_dev, &xgene_enet_adjust_link,
+ pdata->phy_mode)) {
netdev_err(ndev, "Could not connect to PHY\n");
return -ENODEV;
}
@@ -681,32 +688,71 @@ static int xgene_enet_phy_connect(struct net_device *ndev)
~SUPPORTED_100baseT_Half &
~SUPPORTED_1000baseT_Half;
phy_dev->advertising = phy_dev->supported;
- pdata->phy_dev = phy_dev;
return 0;
}
-int xgene_enet_mdio_config(struct xgene_enet_pdata *pdata)
+static int xgene_mdiobus_register(struct xgene_enet_pdata *pdata,
+ struct mii_bus *mdio)
{
- struct net_device *ndev = pdata->ndev;
struct device *dev = &pdata->pdev->dev;
+ struct net_device *ndev = pdata->ndev;
+ struct phy_device *phy;
struct device_node *child_np;
struct device_node *mdio_np = NULL;
- struct mii_bus *mdio_bus;
int ret;
+ u32 phy_id;
+
+ if (dev->of_node) {
+ for_each_child_of_node(dev->of_node, child_np) {
+ if (of_device_is_compatible(child_np,
+ "apm,xgene-mdio")) {
+ mdio_np = child_np;
+ break;
+ }
+ }
- for_each_child_of_node(dev->of_node, child_np) {
- if (of_device_is_compatible(child_np, "apm,xgene-mdio")) {
- mdio_np = child_np;
- break;
+ if (!mdio_np) {
+ netdev_dbg(ndev, "No mdio node in the dts\n");
+ return -ENXIO;
}
- }
- if (!mdio_np) {
- netdev_dbg(ndev, "No mdio node in the dts\n");
- return -ENXIO;
+ return of_mdiobus_register(mdio, mdio_np);
}
+ /* Mask out all PHYs from auto probing. */
+ mdio->phy_mask = ~0;
+
+ /* Register the MDIO bus */
+ ret = mdiobus_register(mdio);
+ if (ret)
+ return ret;
+
+ ret = device_property_read_u32(dev, "phy-channel", &phy_id);
+ if (ret)
+ ret = device_property_read_u32(dev, "phy-addr", &phy_id);
+ if (ret)
+ return -EINVAL;
+
+ phy = get_phy_device(mdio, phy_id, true);
+ if (!phy || IS_ERR(phy))
+ return -EIO;
+
+ ret = phy_device_register(phy);
+ if (ret)
+ phy_device_free(phy);
+ else
+ pdata->phy_dev = phy;
+
+ return ret;
+}
+
+int xgene_enet_mdio_config(struct xgene_enet_pdata *pdata)
+{
+ struct net_device *ndev = pdata->ndev;
+ struct mii_bus *mdio_bus;
+ int ret;
+
mdio_bus = mdiobus_alloc();
if (!mdio_bus)
return -ENOMEM;
@@ -720,7 +766,7 @@ int xgene_enet_mdio_config(struct xgene_enet_pdata *pdata)
mdio_bus->priv = pdata;
mdio_bus->parent = &ndev->dev;
- ret = of_mdiobus_register(mdio_bus, mdio_np);
+ ret = xgene_mdiobus_register(pdata, mdio_bus);
if (ret) {
netdev_err(ndev, "Failed to register MDIO bus\n");
mdiobus_free(mdio_bus);
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 83a5028..7d5f937 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -24,6 +24,11 @@
#include "xgene_enet_sgmac.h"
#include "xgene_enet_xgmac.h"
+#define NO_MAC_FOUND 0
+#define RES_ENET_CSR 0
+#define RES_RING_CSR 1
+#define RES_RING_CMD 2
+
static void xgene_enet_init_bufpool(struct xgene_enet_desc_ring *buf_pool)
{
struct xgene_enet_raw_desc16 *raw_desc;
@@ -746,6 +751,41 @@ static const struct net_device_ops xgene_ndev_ops = {
.ndo_set_mac_address = xgene_enet_set_mac_address,
};
+static int xgene_get_mac_address(struct device *dev,
+ unsigned char *addr)
+{
+ int ret;
+
+ ret = device_property_read_u8_array(dev, "local-mac-address", addr, 6);
+ if (ret)
+ ret = device_property_read_u8_array(dev, "mac-address",
+ addr, 6);
+ if (ret)
+ return NO_MAC_FOUND;
+
+ return ETH_ALEN;
+}
+
+static int xgene_get_phy_mode(struct device *dev)
+{
+ int i, ret;
+ char *modestr;
+
+ ret = device_property_read_string(dev, "phy-connection-type",
+ (const char **)&modestr);
+ if (ret)
+ ret = device_property_read_string(dev, "phy-mode",
+ (const char **)&modestr);
+ if (ret)
+ return -ENODEV;
+
+ for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++) {
+ if (!strcasecmp(modestr, phy_modes(i)))
+ return i;
+ }
+ return -ENODEV;
+}
+
static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
{
struct platform_device *pdev;
@@ -753,29 +793,42 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
struct device *dev;
struct resource *res;
void __iomem *base_addr;
- const char *mac;
int ret;
pdev = pdata->pdev;
dev = &pdev->dev;
ndev = pdata->ndev;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "enet_csr");
- pdata->base_addr = devm_ioremap_resource(dev, res);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, RES_ENET_CSR);
+ if (!res) {
+ dev_err(dev, "Resource enet_csr not defined\n");
+ return -ENODEV;
+ }
+ pdata->base_addr = devm_ioremap(dev, res->start, resource_size(res));
if (IS_ERR(pdata->base_addr)) {
dev_err(dev, "Unable to retrieve ENET Port CSR region\n");
return PTR_ERR(pdata->base_addr);
}
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ring_csr");
- pdata->ring_csr_addr = devm_ioremap_resource(dev, res);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, RES_RING_CSR);
+ if (!res) {
+ dev_err(dev, "Resource ring_csr not defined\n");
+ return -ENODEV;
+ }
+ pdata->ring_csr_addr = devm_ioremap(dev, res->start,
+ resource_size(res));
if (IS_ERR(pdata->ring_csr_addr)) {
dev_err(dev, "Unable to retrieve ENET Ring CSR region\n");
return PTR_ERR(pdata->ring_csr_addr);
}
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ring_cmd");
- pdata->ring_cmd_addr = devm_ioremap_resource(dev, res);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, RES_RING_CMD);
+ if (!res) {
+ dev_err(dev, "Resource ring_cmd not defined\n");
+ return -ENODEV;
+ }
+ pdata->ring_cmd_addr = devm_ioremap(dev, res->start,
+ resource_size(res));
if (IS_ERR(pdata->ring_cmd_addr)) {
dev_err(dev, "Unable to retrieve ENET Ring command region\n");
return PTR_ERR(pdata->ring_cmd_addr);
@@ -789,14 +842,12 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
}
pdata->rx_irq = ret;
- mac = of_get_mac_address(dev->of_node);
- if (mac)
- memcpy(ndev->dev_addr, mac, ndev->addr_len);
- else
+ if (!xgene_get_mac_address(dev, ndev->dev_addr))
eth_hw_addr_random(ndev);
+
memcpy(ndev->perm_addr, ndev->dev_addr, ndev->addr_len);
- pdata->phy_mode = of_get_phy_mode(pdev->dev.of_node);
+ pdata->phy_mode = xgene_get_phy_mode(dev);
if (pdata->phy_mode < 0) {
dev_err(dev, "Unable to get phy-connection-type\n");
return pdata->phy_mode;
@@ -809,11 +860,9 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
}
pdata->clk = devm_clk_get(&pdev->dev, NULL);
- ret = IS_ERR(pdata->clk);
if (IS_ERR(pdata->clk)) {
- dev_err(&pdev->dev, "can't get clock\n");
- ret = PTR_ERR(pdata->clk);
- return ret;
+ /* Firmware may have set up the clock already. */
+ pdata->clk = NULL;
}
base_addr = pdata->base_addr;
@@ -924,7 +973,7 @@ static int xgene_enet_probe(struct platform_device *pdev)
goto err;
}
- ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+ ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));
if (ret) {
netdev_err(ndev, "No usable DMA configuration\n");
goto err;
@@ -972,7 +1021,15 @@ static int xgene_enet_remove(struct platform_device *pdev)
return 0;
}
-static struct of_device_id xgene_enet_match[] = {
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_enet_acpi_match[] = {
+ { "APMC0D05", },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
+#endif
+
+static struct of_device_id xgene_enet_of_match[] = {
{.compatible = "apm,xgene-enet",},
{},
};
@@ -982,7 +1039,8 @@ MODULE_DEVICE_TABLE(of, xgene_enet_match);
static struct platform_driver xgene_enet_driver = {
.driver = {
.name = "xgene-enet",
- .of_match_table = xgene_enet_match,
+ .of_match_table = of_match_ptr(xgene_enet_of_match),
+ .acpi_match_table = ACPI_PTR(xgene_enet_acpi_match),
},
.probe = xgene_enet_probe,
.remove = xgene_enet_remove,
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index f9958fa..c2d465c 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -22,7 +22,10 @@
#ifndef __XGENE_ENET_MAIN_H__
#define __XGENE_ENET_MAIN_H__
+#include <linux/acpi.h>
#include <linux/clk.h>
+#include <linux/efi.h>
+#include <linux/io.h>
#include <linux/of_platform.h>
#include <linux/of_net.h>
#include <linux/of_mdio.h>
--
1.9.1
^ permalink raw reply related
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Samudrala, Sridhar @ 2014-12-18 23:26 UTC (permalink / raw)
To: Roopa Prabhu, John Fastabend
Cc: Varlese, Marco, netdev@vger.kernel.org, Thomas Graf, Jiri Pirko,
sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <54935E28.8050602@cumulusnetworks.com>
On 12/18/2014 3:07 PM, Roopa Prabhu wrote:
> On 12/18/14, 11:21 AM, John Fastabend wrote:
>> On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
>>> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>>>> Removed unnecessary content for ease of reading...
>>>>
>>>>>>>>>> +/* Switch Port Attributes section */
>>>>>>>>>> +
>>>>>>>>>> +enum {
>>>>>>>>>> + IFLA_ATTR_UNSPEC,
>>>>>>>>>> + IFLA_ATTR_LEARNING,
>>>>>>>>> Any reason you want learning here ?. This is covered as part of
>>>>>>>>> the bridge setlink attributes.
>>>>>>>>>
>>>>>>>> Yes, because the user may _not_ want to go through a bridge
>>>>>>>> interface
>>>>>>> necessarily.
>>>>>>> But, the bridge setlink/getlink interface was changed to
>>>>>>> accommodate
>>>>> 'self'
>>>>>>> for exactly such cases.
>>>>>>> I kind of understand your case for the other attributes (these are
>>>>>>> per port settings that switch asics provide).
>>>>>>>
>>>>>>> However, i don't understand the reason to pull in bridge
>>>>>>> attributes here.
>>>>>>>
>>>>>> Maybe, I am missing something so you might help. The learning
>>>>>> attribute -
>>>>> in my case - it is like all other attributes: a port attribute (as
>>>>> you said, port
>>>>> settings that the switch provides per port).
>>>>>> So, what I was saying is "why the user shall go through a bridge
>>>>>> to configure
>>>>> the learning attribute"? From my perspective, it is as any other
>>>>> attribute and
>>>>> as such configurable on the port.
>>>>>
>>>>> Thinking about this some more, i don't see why any of these
>>>>> attributes
>>>>> (except loopback. I dont understand the loopback attribute) cant
>>>>> be part of
>>>>> the birdge port attributes.
>>>>>
>>>>> With this we will end up adding l2 attributes in two places: the
>>>>> general link
>>>>> attributes and bridge attributes.
>>>>>
>>>>> And since we have gone down the path of using
>>>>> ndo_bridge_setlink/getlink
>>>>> with 'self'....we should stick to that for all l2 attributes.
>>>>>
>>>>> The idea of overloading ndo_bridge_set/getlink, was to have the
>>>>> same set of
>>>>> attributes but support both cases where the user wants to go
>>>>> through the
>>>>> bridge driver or directly to the switch port driver. So, you are
>>>>> not really going
>>>>> through the bridge driver if you use 'self' and
>>>>> ndo_bridge_setlink/getlink.
>>>>>
>>>> Roopa, one of the comments I got from Thomas Graf on my v1 patch
>>>> was that your patch and mine were supplementary ("I think Roopa's
>>>> patches are supplementary. Not all switchdev users will be backed
>>>> with a Linux Bridge. I therefore welcome your patches very
>>>> much")... I also understood by others that the patch made sense for
>>>> the same reason. I simply do not understand why these attributes
>>>> (and maybe others in the future) could not be configured directly
>>>> on a standard port but have to go through a bridge.
>>>>
>>> ok, i am very confused in that case. The whole moving of bridge
>>> attributes from the bridge driver to rtnetlink.c was to make the
>>> bridge attributes accessible to any driver who wants to set l2/bridge
>>> attributes on their switch ports. So, its unclear to me why we are
>>> doing this parallel thing again. This move to rtnetlink.c was done
>>> during the recent rocker support. so, maybe scott/jiri can elaborate
>>> more.
>>
>> Not sure if this will add to the confusion or help. But you do not
>> need to have the bridge.ko loaded or netdev's attached to a bridge
>> to use the setlink/getlink ndo ops and netlink messages.
>>
>> This was intentionally done. Its already used with NIC devices to
>> configure embedded bridge settings such as VEB/VEPA.
>
> that helps my case, thanks.
So the user interface to set/get the per-port attributes will be via
'bridge', not 'ip'
bridge link set dev sw0p1 port_attr bcast_flooding 1 self
bridge link get dev sw0p1 port_attr bcast_flooding self
We also need an interface to set per-switch attributes. Can this work?
bridge link set dev sw0 sw_attr bcast_flooding 1 master
where sw0 is a bridge representing the hardware switch.
>>
>> I think I'm just repeating Roopa though.
>>
>
> --
> 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 net-next v2 1/1] net: Support for switch port configuration
From: Roopa Prabhu @ 2014-12-18 23:07 UTC (permalink / raw)
To: John Fastabend
Cc: Varlese, Marco, netdev@vger.kernel.org, Thomas Graf, Jiri Pirko,
sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <5493293A.2000802@intel.com>
On 12/18/14, 11:21 AM, John Fastabend wrote:
> On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
>> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>>> Removed unnecessary content for ease of reading...
>>>
>>>>>>>>> +/* Switch Port Attributes section */
>>>>>>>>> +
>>>>>>>>> +enum {
>>>>>>>>> + IFLA_ATTR_UNSPEC,
>>>>>>>>> + IFLA_ATTR_LEARNING,
>>>>>>>> Any reason you want learning here ?. This is covered as part of
>>>>>>>> the bridge setlink attributes.
>>>>>>>>
>>>>>>> Yes, because the user may _not_ want to go through a bridge
>>>>>>> interface
>>>>>> necessarily.
>>>>>> But, the bridge setlink/getlink interface was changed to accommodate
>>>> 'self'
>>>>>> for exactly such cases.
>>>>>> I kind of understand your case for the other attributes (these are
>>>>>> per port settings that switch asics provide).
>>>>>>
>>>>>> However, i don't understand the reason to pull in bridge attributes here.
>>>>>>
>>>>> Maybe, I am missing something so you might help. The learning attribute -
>>>> in my case - it is like all other attributes: a port attribute (as you said, port
>>>> settings that the switch provides per port).
>>>>> So, what I was saying is "why the user shall go through a bridge to configure
>>>> the learning attribute"? From my perspective, it is as any other attribute and
>>>> as such configurable on the port.
>>>>
>>>> Thinking about this some more, i don't see why any of these attributes
>>>> (except loopback. I dont understand the loopback attribute) cant be part of
>>>> the birdge port attributes.
>>>>
>>>> With this we will end up adding l2 attributes in two places: the general link
>>>> attributes and bridge attributes.
>>>>
>>>> And since we have gone down the path of using ndo_bridge_setlink/getlink
>>>> with 'self'....we should stick to that for all l2 attributes.
>>>>
>>>> The idea of overloading ndo_bridge_set/getlink, was to have the same set of
>>>> attributes but support both cases where the user wants to go through the
>>>> bridge driver or directly to the switch port driver. So, you are not really going
>>>> through the bridge driver if you use 'self' and ndo_bridge_setlink/getlink.
>>>>
>>> Roopa, one of the comments I got from Thomas Graf on my v1 patch
>>> was that your patch and mine were supplementary ("I think Roopa's
>>> patches are supplementary. Not all switchdev users will be backed
>>> with a Linux Bridge. I therefore welcome your patches very
>>> much")... I also understood by others that the patch made sense for
>>> the same reason. I simply do not understand why these attributes
>>> (and maybe others in the future) could not be configured directly
>>> on a standard port but have to go through a bridge.
>>>
>> ok, i am very confused in that case. The whole moving of bridge
>> attributes from the bridge driver to rtnetlink.c was to make the
>> bridge attributes accessible to any driver who wants to set l2/bridge
>> attributes on their switch ports. So, its unclear to me why we are
>> doing this parallel thing again. This move to rtnetlink.c was done
>> during the recent rocker support. so, maybe scott/jiri can elaborate
>> more.
>
> Not sure if this will add to the confusion or help. But you do not
> need to have the bridge.ko loaded or netdev's attached to a bridge
> to use the setlink/getlink ndo ops and netlink messages.
>
> This was intentionally done. Its already used with NIC devices to
> configure embedded bridge settings such as VEB/VEPA.
that helps my case, thanks.
>
> I think I'm just repeating Roopa though.
>
^ permalink raw reply
* RE: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Arad, Ronen @ 2014-12-18 22:43 UTC (permalink / raw)
To: Fastabend, John R, Roopa Prabhu, Varlese, Marco,
netdev@vger.kernel.org
Cc: Thomas Graf, Jiri Pirko, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <5493293A.2000802@intel.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of John Fastabend
>Sent: Thursday, December 18, 2014 9:21 PM
>To: Roopa Prabhu; Varlese, Marco
>Cc: netdev@vger.kernel.org; Thomas Graf; Jiri Pirko; sfeldma@gmail.com; linux-
>kernel@vger.kernel.org
>Subject: Re: [RFC PATCH net-next v2 1/1] net: Support for switch port
>configuration
>
>On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
>> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>>> Removed unnecessary content for ease of reading...
>>>
>>>>>>>>> +/* Switch Port Attributes section */
>>>>>>>>> +
>>>>>>>>> +enum {
>>>>>>>>> + IFLA_ATTR_UNSPEC,
>>>>>>>>> + IFLA_ATTR_LEARNING,
>>>>>>>> Any reason you want learning here ?. This is covered as part of
>>>>>>>> the bridge setlink attributes.
>>>>>>>>
>>>>>>> Yes, because the user may _not_ want to go through a bridge
>>>>>>> interface
>>>>>> necessarily.
>>>>>> But, the bridge setlink/getlink interface was changed to accommodate
>>>> 'self'
>>>>>> for exactly such cases.
>>>>>> I kind of understand your case for the other attributes (these are
>>>>>> per port settings that switch asics provide).
>>>>>>
>>>>>> However, i don't understand the reason to pull in bridge attributes
>here.
>>>>>>
>>>>> Maybe, I am missing something so you might help. The learning attribute -
>>>> in my case - it is like all other attributes: a port attribute (as you
>said, port
>>>> settings that the switch provides per port).
>>>>> So, what I was saying is "why the user shall go through a bridge to
>configure
>>>> the learning attribute"? From my perspective, it is as any other attribute
>and
>>>> as such configurable on the port.
>>>>
>>>> Thinking about this some more, i don't see why any of these attributes
>>>> (except loopback. I dont understand the loopback attribute) cant be part
>of
>>>> the birdge port attributes.
>>>>
>>>> With this we will end up adding l2 attributes in two places: the general
>link
>>>> attributes and bridge attributes.
>>>>
>>>> And since we have gone down the path of using ndo_bridge_setlink/getlink
>>>> with 'self'....we should stick to that for all l2 attributes.
>>>>
>>>> The idea of overloading ndo_bridge_set/getlink, was to have the same set
>of
>>>> attributes but support both cases where the user wants to go through the
>>>> bridge driver or directly to the switch port driver. So, you are not
>really going
>>>> through the bridge driver if you use 'self' and
>ndo_bridge_setlink/getlink.
>>>>
>
>>> Roopa, one of the comments I got from Thomas Graf on my v1 patch
>>> was that your patch and mine were supplementary ("I think Roopa's
>>> patches are supplementary. Not all switchdev users will be backed
>>> with a Linux Bridge. I therefore welcome your patches very
>>> much")... I also understood by others that the patch made sense for
>>> the same reason. I simply do not understand why these attributes
>>> (and maybe others in the future) could not be configured directly
>>> on a standard port but have to go through a bridge.
>>>
>> ok, i am very confused in that case. The whole moving of bridge
>> attributes from the bridge driver to rtnetlink.c was to make the
>> bridge attributes accessible to any driver who wants to set l2/bridge
>> attributes on their switch ports. So, its unclear to me why we are
>> doing this parallel thing again. This move to rtnetlink.c was done
>> during the recent rocker support. so, maybe scott/jiri can elaborate
>> more.
>
>
>Not sure if this will add to the confusion or help. But you do not
>need to have the bridge.ko loaded or netdev's attached to a bridge
>to use the setlink/getlink ndo ops and netlink messages.
No you don't need bridge.ko to implement ndo_bridge_setlink/getlink. Rtnetlink invokes those ndos from code which does not depend on CONFIG_BRIDGE or the presence of bridge.ko.
Calling some bridge exported functions such as br_fdb_external_learn_add/del requires the presence of bridge.ko and it only makes sense when the switch port device is enslaved to a bridge.
>
>This was intentionally done. Its already used with NIC devices to
>configure embedded bridge settings such as VEB/VEPA.
>
>I think I'm just repeating Roopa though.
>
>--
>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 net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
From: Jamal Hadi Salim @ 2014-12-18 22:32 UTC (permalink / raw)
To: Hubert Sokolowski, vyasevic
Cc: John Fastabend, Roopa Prabhu, netdev@vger.kernel.org
In-Reply-To: <e3ac4e3535a18f6dd1cf31030674f91c.squirrel@poczta.wsisiz.edu.pl>
Sorry for the latency (head-buried-in-sand in effect)
On 12/17/14 11:18, Hubert Sokolowski wrote:
> I have just prepared a patch where I dump uc/mc for bridge devices
> by looking at (dev->priv_flags & IFF_EBRIDGE), so I have same results
> as without my changes. This should satisfy Jamal and Roopa.
> I could send it as v3 of my patch along with the results if you are
> interested.
>
Please do. If you satisfy Vlad's goals then we are all happy.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] Fixed TPACKET V3 to signal poll when block is closed rather than for every packet
From: David Miller @ 2014-12-18 21:51 UTC (permalink / raw)
To: dan; +Cc: netdev, linux-kernel
In-Reply-To: <1418939356.3016.9.camel@voodoo.cms.waikato.ac.nz>
From: Dan Collins <dan@dcollins.co.nz>
Date: Fri, 19 Dec 2014 10:49:16 +1300
> Make TPACKET_V3 signal poll when block is closed rather than for every
> packet. Side effect is that poll will be signaled when block retire
> timer expires which didn't previously happen. Issue was visible when
> sending packets at a very low frequency such that all blocks are retired
> before packets are received by TPACKET_V3. This caused avoidable packet
> loss. The fix ensures that the signal is sent when blocks are closed
> which covers the normal path where the block is filled as well as the
> path where the timer expires. The case where a block is filled without
> moving to the next block (ie. all blocks are full) will still cause poll
> to be signaled.
>
> Signed-off-by: Dan Collins <dan@dcollins.co.nz>
Your email client has corrupted the patch, turning TAB characters into
sequences of SPACE characters.
Please turn off all formatting in your email client, read:
Documentation/email-clients.txt
for help.
^ permalink raw reply
* [PATCH] Fixed TPACKET V3 to signal poll when block is closed rather than for every packet
From: Dan Collins @ 2014-12-18 21:49 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel
Make TPACKET_V3 signal poll when block is closed rather than for every
packet. Side effect is that poll will be signaled when block retire
timer expires which didn't previously happen. Issue was visible when
sending packets at a very low frequency such that all blocks are retired
before packets are received by TPACKET_V3. This caused avoidable packet
loss. The fix ensures that the signal is sent when blocks are closed
which covers the normal path where the block is filled as well as the
path where the timer expires. The case where a block is filled without
moving to the next block (ie. all blocks are full) will still cause poll
to be signaled.
Signed-off-by: Dan Collins <dan@dcollins.co.nz>
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e52a447..14e883d 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -43,6 +43,8 @@
* Chetan Loke : Implemented TPACKET_V3 block abstraction
* layer.
* Copyright (C) 2011, <lokec@ccs.neu.edu>
+ * Dan Collins : Fixed TPACKET_V3 to wake poll when block is closed
+ * rather than for every packet.
*
*
* This program is free software; you can redistribute it and/or
@@ -785,6 +787,7 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
struct tpacket3_hdr *last_pkt;
struct tpacket_hdr_v1 *h1 = &pbd1->hdr.bh1;
+ struct sock *sk = &po->sk;
if (po->stats.stats3.tp_drops)
status |= TP_STATUS_LOSING;
@@ -809,6 +812,8 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
/* Flush the block */
prb_flush_block(pkc1, pbd1, status);
+ sk->sk_data_ready(sk);
+
pkc1->kactive_blk_num = GET_NEXT_PRB_BLK_NUM(pkc1);
}
@@ -2052,12 +2057,12 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
smp_wmb();
#endif
- if (po->tp_version <= TPACKET_V2)
+ if (po->tp_version <= TPACKET_V2) {
__packet_set_status(po, h.raw, status);
- else
+ sk->sk_data_ready(sk);
+ } else {
prb_clear_blk_fill_status(&po->rx_ring);
-
- sk->sk_data_ready(sk);
+ }
drop_n_restore:
if (skb_head != skb->data && skb_shared(skb)) {
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2014-12-18 21:39 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix NBMA tunnel mac header handling in GRE, from Timo Teräs.
2) Fix a NAPI race in the fec driver, from Nimrod Andy.
3) The new IFF_VNET_LE bit is outside the size of the flags
member it is stored in (which is 16-bits), store the state
locally in the drivers. From Michael S. Tsirkin.
4) We are kicking the tires with the new wireless maintainership
situation. Bluetooth fixes via Johan Hedberg, and mac80211
fixes from Johannes Berg.
5) Fix locking and leaks in geneve driver, from Jesse Gross.
6) Make netlink TX mmap code always copy, so we don't have to
be potentially exposed to the user changing the underlying
contents from underneath us.
Please pull, thank a lot!
The following changes since commit 67e2c3883828b39548cee2091b36656787775d95:
Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security (2014-12-14 20:36:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 86c8fc4bbe14b8950e62d379bb57722427ad3d67:
Merge tag 'mac80211-for-davem-2014-12-18' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-12-18 15:33:49 -0500)
----------------------------------------------------------------
Andreas Müller (1):
mac80211: fix multicast LED blinking and counter
Arik Nemtsov (2):
cfg80211: avoid mem leak on driver hint set
cfg80211: correctly check ad-hoc channels
Asaf Vertz (1):
cirrus: cs89x0: fix time comparison
Brian Norris (1):
brcmsmac: don't leak kernel memory via printk()
Cyrille Pitchen (2):
net/macb: fix misplaced call of free_netdev() in macb_remove()
net/macb: remove useless calls of devm_free_irq()
David Miller (1):
netlink: Always copy on mmap TX.
David S. Miller (8):
Merge branch 'mlx4'
Merge branch 'macb'
Merge branch 'fixed_phy'
Merge branch 'vnet_le'
net: Allow FIXED_PHY to be modular.
Merge tag 'master-2014-12-15' of git://git.kernel.org/.../linville/wireless
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth
Merge tag 'mac80211-for-davem-2014-12-18' of git://git.kernel.org/.../jberg/mac80211
David Vrabel (2):
xen-netfront: use napi_complete() correctly to prevent Rx stalling
xen-netback: support frontends without feature-rx-notify again
Duan Jiong (1):
fib_trie.txt: fix typo
Emmanuel Grumbach (2):
mac80211: update the channel context after channel switch
cfg80211: don't WARN about two consecutive Country IE hint
Fengguang Wu (1):
Bluetooth: fix err_cast.cocci warnings
Florian Fainelli (3):
net: bcmgenet: always select FIXED_PHY
net: systemport: always select FIXED_PHY
net: dsa: bcm_sf2: always select FIXED_PHY
Geert Uytterhoeven (2):
net: stmmac: sti: Fix uninitialized pointer dereference if !OF
rds: Fix min() warning in rds_message_inc_copy_to_user()
Hariprasad Shenai (1):
cxgb4: Fix decoding QSA module for ethtool get settings
Ido Shamay (1):
net/mlx4: Cache line CQE/EQE stride fixes
Jaganath Kanakkassery (2):
Bluetooth: Fix missing hci_dev_lock/unlock in mgmt req_complete()
Bluetooth: Fix missing hci_dev_lock/unlock in hci_event
Janne Heikkinen (1):
Bluetooth: Add USB device 04ca:3010 as Atheros AR3012
Jes Sorensen (1):
mac80211: avoid using uninitialized stack data
Jesse Gross (2):
geneve: Remove socket and offload handlers at destruction.
geneve: Fix races between socket add and release.
Jiri Benc (1):
bnx2x: fix typos in "configure"
Johan Hedberg (5):
Bluetooth: Fix calling hci_conn_put too early
Bluetooth: Fix incorrect pending cmd removal in pairing_complete()
Bluetooth: Fix notifying mgmt power off before flushing connection list
Bluetooth: Fix enabling BR/EDR SC when powering on
Bluetooth: Fix mgmt response status when removing adapter
Johannes Berg (1):
mac80211: free management frame keys when removing station
John W. Linville (2):
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next
MAINTAINERS: changes for wireless
Jouni Malinen (1):
cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz drivers
Julia Lawall (3):
zd1211rw: fix misspelling of current function in string
hostap_cs: fix misspelling of current function in string
rtlwifi: rtl8821ae: fix misspelling of current function in string
Larry Finger (1):
rtlwifi: rtl8192ce: Set fw_ready flag
Luciano Coelho (1):
nl80211: check matches array length before acessing it
Marcel Holtmann (5):
Bluetooth: Check for force_lesc_support when enabling SMP over BR/EDR
Bluetooth: Check for force_lesc_support before rejecting SMP over BR/EDR
Bluetooth: Fix generation of non-resolvable private addresses
Bluetooth: Fix check for support for page scan related commands
Bluetooth: Fix bug with filter in service discovery optimization
Matan Barak (1):
net/mlx4_core: Fixed memory leak and incorrect refcount in mlx4_load_one
Michael S. Tsirkin (5):
macvtap: fix uninitialized access on TUNSETIFF
if_tun: add TUNSETVNETLE/TUNGETVNETLE
tun: drop broken IFF_VNET_LE
macvtap: drop broken IFF_VNET_LE
if_tun: drop broken IFF_VNET_LE
Nimrod Andy (1):
net: fec: Fix NAPI race
Or Gerlitz (2):
net/mlx4_core: Avoid double dumping of the PF device capabilities
net: Disallow providing non zero VLAN ID for NIC drivers FDB add flow
Sriharsha Basavapatna (1):
be2net: Fix incorrect setting of tunnel offload flag in netdev features
Thomas Graf (3):
ip_tunnel: Add sanity checks to ip_tunnel_encap_add_ops()
ip_tunnel: Add missing validation of encap type to ip_tunnel_encap_setup()
netlink: Don't reorder loads/stores before marking mmap netlink frame as available
Timo Teräs (1):
gre: fix the inner mac header in nbma tunnel xmit path
Tobias Klauser (1):
net: smc91x: Fix build without gpiolib
Wei Yongjun (1):
rtlwifi: rtl8192cu: Fix sparse non static symbol warning
Documentation/networking/fib_trie.txt | 4 +--
MAINTAINERS | 19 ++++++--------
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
drivers/net/dsa/Kconfig | 2 +-
drivers/net/ethernet/broadcom/Kconfig | 4 +--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 +--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h | 4 +--
drivers/net/ethernet/cadence/macb.c | 25 +++++++-----------
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 2 +-
drivers/net/ethernet/cirrus/cs89x0.c | 27 ++++++++++----------
drivers/net/ethernet/emulex/benet/be_main.c | 2 ++
drivers/net/ethernet/freescale/fec_main.c | 19 ++++++--------
drivers/net/ethernet/intel/i40e/i40e_main.c | 5 ++++
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 11 ++++++--
drivers/net/ethernet/mellanox/mlx4/fw.c | 30 ++++++++++++----------
drivers/net/ethernet/mellanox/mlx4/fw.h | 1 +
drivers/net/ethernet/mellanox/mlx4/main.c | 62 ++++++++++++++++++++++++---------------------
drivers/net/ethernet/smsc/Kconfig | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 10 ++++----
drivers/net/macvtap.c | 30 +++++++++++++++++-----
drivers/net/phy/Kconfig | 4 +--
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/{fixed.c => fixed_phy.c} | 0
drivers/net/tun.c | 26 ++++++++++++++++---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
drivers/net/wireless/hostap/hostap_cs.c | 15 ++++-------
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 2 ++
drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8821ae/dm.c | 11 ++++----
drivers/net/wireless/zd1211rw/zd_chip.c | 6 ++---
drivers/net/xen-netback/common.h | 4 ++-
drivers/net/xen-netback/interface.c | 4 ++-
drivers/net/xen-netback/netback.c | 27 ++++++++++----------
drivers/net/xen-netback/xenbus.c | 12 ++++++---
drivers/net/xen-netfront.c | 11 +++-----
include/linux/phy_fixed.h | 2 +-
include/uapi/linux/if_tun.h | 3 ++-
net/bluetooth/hci_conn.c | 2 +-
net/bluetooth/hci_core.c | 60 ++++++++++++++++++++++++++------------------
net/bluetooth/hci_event.c | 20 +++++++++++++++
net/bluetooth/l2cap_core.c | 5 ++--
net/bluetooth/mgmt.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++----------------------
net/bluetooth/smp.c | 5 ++--
net/core/rtnetlink.c | 5 ++++
net/ipv4/geneve.c | 30 +++++++++++++++++-----
net/ipv4/ip_gre.c | 9 ++++---
net/ipv4/ip_tunnel.c | 9 +++++++
net/mac80211/chan.c | 4 +++
net/mac80211/key.c | 2 +-
net/mac80211/mlme.c | 1 +
net/mac80211/rx.c | 11 ++++----
net/netlink/af_netlink.c | 54 +++++++++++++--------------------------
net/rds/message.c | 3 ++-
net/wireless/chan.c | 9 ++++---
net/wireless/nl80211.c | 2 +-
net/wireless/reg.c | 20 +++++++++------
58 files changed, 454 insertions(+), 297 deletions(-)
rename drivers/net/phy/{fixed.c => fixed_phy.c} (100%)
^ permalink raw reply
* Re: pull-request: mac80211 2014-12-18
From: Johannes Berg @ 2014-12-18 20:54 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev
In-Reply-To: <20141218.153520.221364366280641527.davem@davemloft.net>
On Thu, 2014-12-18 at 15:35 -0500, David Miller wrote:
> 1) Don't put things into a merge commit, I take the text from your
> pull request email and that becomes the merge commit contents.
> Put it in your pull request email.
Hmm, ok - not sure I fully understand. I don't think I created a merge
commit, so did you mean the tag? I thought a (signed) tag with contents
was now the preferred way to send pull requests, but I can also send a
signed email without a tag for you to merge a branch? Or would you
prefer a signed tag but empty (is that even possible?) with the text in
the email?
> 2) I want every pull request I get at least CC:'d to netdev.
Ok, sure.
Thanks,
johannes
^ permalink raw reply
* Re: [iwlwifi] BUG: unable to handle kernel
From: Fengguang Wu @ 2014-12-18 21:07 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, lkp@01.org,
linux-leds@vger.kernel.org
In-Reply-To: <1418931737.4679.1.camel@egrumbacBox>
On Fri, Dec 19, 2014 at 03:42:17AM +0800, Grumbach, Emmanuel wrote:
> On Thu, 2014-12-18 at 09:13 -0800, Fengguang Wu wrote:
> > Hi All,
> >
> > I don't see any relationship between the BUG and this bisected commit.
> > Anyway, it's better to report it to the lists than to ignore.
>
> Right - but I have to say that I have no clue how this comment can cause
> the bug you are seeing...
s?comment?commit?
> Do you even have an Intel Wireless device the VM could access?
Nope. It's simple QEMU virtual machine boot test.
Thanks,
Fengguang
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git master
> >
> > commit 03d6c3b0fa4f5f0379cede079ec828a6c999fe43
> > Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > AuthorDate: Wed Dec 3 10:39:07 2014 +0200
> > Commit: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > CommitDate: Sun Dec 14 10:20:29 2014 +0200
> >
> > iwlwifi: pcie: re-ACK all interrupts after device reset
> >
> > When we reset the device, the CSR_INT gets cleared as well
> > as CSR_INT_MASK. Meaning that we shouldn't get any interrupt
> > but, due to a hardware bug, recent devices will keep sending
> > interrupts. This leads to an interrupt storm while stopping
> > the device.
> > The way to fix this is to ACK all the interrupts after the
> > device is reset so that the value of CSR_INT will stay
> > 0xffffffff.
> >
> > Fixes: 522713c81e4e ("iwlwifi: pcie: properly reset the device")
> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> >
> > +------------------------------------------+------------+------------+------------+
> > | | 0a79a0c011 | 03d6c3b0fa | iwlwifi-fi |
> > +------------------------------------------+------------+------------+------------+
> > | boot_successes | 60 | 19 | 3 |
> > | boot_failures | 0 | 1 | 9 |
> > | BUG:unable_to_handle_kernel | 0 | 1 | 9 |
> > | Oops | 0 | 1 | 9 |
> > | RIP:strcmp | 0 | 1 | 9 |
> > | Kernel_panic-not_syncing:Fatal_exception | 0 | 1 | 9 |
> > | backtrace:led_trigger_register_simple | 0 | 1 | 9 |
> > | backtrace:ledtrig_usb_init | 0 | 1 | 9 |
> > | backtrace:kernel_init_freeable | 0 | 1 | 9 |
> > +------------------------------------------+------------+------------+------------+
> >
> > [ 5.345018] g_serial gadget: Gadget Serial v2.4
> > [ 5.345927] g_serial gadget: g_serial ready
> > [ 5.345927] g_serial gadget: g_serial ready
> > [ 5.346777] BUG: unable to handle kernel
> > [ 5.346777] BUG: unable to handle kernel paging requestpaging request at ffff88000004e5f0
> > at ffff88000004e5f0
> > [ 5.348183] IP:
> > [ 5.348183] IP: [<ffffffff81446a68>] strcmp+0x6/0x20
> > [<ffffffff81446a68>] strcmp+0x6/0x20
> > [ 5.349183] PGD 37f1067
> > [ 5.349183] PGD 37f1067 PUD 37f2067 PUD 37f2067 PMD 37f3067 PMD 37f3067 PTE 800000000004e060PTE 800000000004e060
> >
> > [ 5.350498] Oops: 0000 [#1]
> > [ 5.350498] Oops: 0000 [#1] DEBUG_PAGEALLOCDEBUG_PAGEALLOC
> >
> > [ 5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> > [ 5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> > [ 5.352660] task: ffff880012060000 ti: ffff88001204c000 task.ti: ffff88001204c000
> > [ 5.352660] task: ffff880012060000 ti: ffff88001204c000 task.ti: ffff88001204c000
> > [ 5.354143] RIP: 0010:[<ffffffff81446a68>]
> > [ 5.354143] RIP: 0010:[<ffffffff81446a68>] [<ffffffff81446a68>] strcmp+0x6/0x20
> > [<ffffffff81446a68>] strcmp+0x6/0x20
> > [ 5.354451] RSP: 0000:ffff88001204fe28 EFLAGS: 00010246
> > [ 5.354451] RSP: 0000:ffff88001204fe28 EFLAGS: 00010246
> > [ 5.354451] RAX: 0000000000000000 RBX: ffff88000c08fe00 RCX: ffffffff81d35310
> > [ 5.354451] RAX: 0000000000000000 RBX: ffff88000c08fe00 RCX: ffffffff81d35310
> > [ 5.354451] RDX: ffff88000c08fe68 RSI: ffffffff826d05be RDI: ffff88000004e5f0
> > [ 5.354451] RDX: ffff88000c08fe68 RSI: ffffffff826d05be RDI: ffff88000004e5f0
> > [ 5.354451] RBP: ffff88001204fe28 R08: 0000000000000001 R09: 000000000000033a
> > [ 5.354451] RBP: ffff88001204fe28 R08: 0000000000000001 R09: 000000000000033a
> > [ 5.354451] R10: 0000000000000000 R11: ffffffff82531cd1 R12: ffff88000c19fa00
> > [ 5.354451] R10: 0000000000000000 R11: ffffffff82531cd1 R12: ffff88000c19fa00
> > [ 5.354451] R13: 0000000000000000 R14: ffffffff837958b8 R15: 0000000000000000
> > [ 5.354451] R13: 0000000000000000 R14: ffffffff837958b8 R15: 0000000000000000
> > [ 5.354451] FS: 0000000000000000(0000) GS:ffffffff82789000(0000) knlGS:0000000000000000
> > [ 5.354451] FS: 0000000000000000(0000) GS:ffffffff82789000(0000) knlGS:0000000000000000
> > [ 5.354451] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 5.354451] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 5.354451] CR2: ffff88000004e5f0 CR3: 0000000002776000 CR4: 00000000000006b0
> > [ 5.354451] CR2: ffff88000004e5f0 CR3: 0000000002776000 CR4: 00000000000006b0
> > [ 5.354451] Stack:
> > [ 5.354451] Stack:
> > [ 5.354451] ffff88001204fe58
> > [ 5.354451] ffff88001204fe58 ffffffff81d35334 ffffffff81d35334 0000000000000000 0000000000000000 ffff88000c19fa00 ffff88000c19fa00
> >
> > [ 5.354451] ffffffff826d05be
> > [ 5.354451] ffffffff826d05be 0000000000000000 0000000000000000 ffff88001204fe88 ffff88001204fe88 ffffffff81d35648 ffffffff81d35648
> >
> > [ 5.354451] ffff88000e3bbcc0
> > [ 5.354451] ffff88000e3bbcc0 ffffffff82b3fe61 ffffffff82b3fe61 0000000000000000 0000000000000000 ffffffff82b98910 ffffffff82b98910
> >
> > [ 5.354451] Call Trace:
> > [ 5.354451] Call Trace:
> > [ 5.354451] [<ffffffff81d35334>] led_trigger_register+0x63/0x129
> > [ 5.354451] [<ffffffff81d35334>] led_trigger_register+0x63/0x129
> > [ 5.354451] [<ffffffff81d35648>] led_trigger_register_simple+0x35/0x79
> > [ 5.354451] [<ffffffff81d35648>] led_trigger_register_simple+0x35/0x79
> > [ 5.354451] [<ffffffff82b3fe61>] ? gs_bind+0xea/0xea
> > [ 5.354451] [<ffffffff82b3fe61>] ? gs_bind+0xea/0xea
> > [ 5.354451] [<ffffffff82b3fe78>] ledtrig_usb_init+0x17/0x2e
> > [ 5.354451] [<ffffffff82b3fe78>] ledtrig_usb_init+0x17/0x2e
> > [ 5.354451] [<ffffffff82b00044>] do_one_initcall+0xe6/0x171
> > [ 5.354451] [<ffffffff82b00044>] do_one_initcall+0xe6/0x171
> > [ 5.354451] [<ffffffff82b001c7>] kernel_init_freeable+0xf8/0x180
> > [ 5.354451] [<ffffffff82b001c7>] kernel_init_freeable+0xf8/0x180
> > [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> > [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> > [ 5.354451] [<ffffffff8206079a>] kernel_init+0x9/0xd0
> > [ 5.354451] [<ffffffff8206079a>] kernel_init+0x9/0xd0
> > [ 5.354451] [<ffffffff8207d2ba>] ret_from_fork+0x7a/0xb0
> > [ 5.354451] [<ffffffff8207d2ba>] ret_from_fork+0x7a/0xb0
> > [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> > [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> > [ 5.354451] Code:
> > [ 5.354451] Code: c0 c0 eb eb f5 f5 31 31 c9 c9 40 40 8a 8a 3c 3c 0e 0e 4d 4d 8d 8d 0c 0c 08 08 40 40 84 84 ff ff 41 41 88 88 3c 3c 08 08 74 74 0d 0d 48 48 ff ff c1 c1 48 48 39 39 ca ca 75 75 e7 e7 41 41 c6 c6 41 41 01 01 00 00 5d 5d c3 c3 55 55 31 31 c0 c0 48 48 89 89 e5 e5 <8a> <8a> 14 14 07 07 3a 3a 14 14 06 06 74 74 07 07 19 19 c0 c0 83 83 c8 c8 01 01 eb eb 09 09 48 48 ff ff c0 c0 84 84 d2 d2 75 75
> >
> > [ 5.354451] RIP
> > [ 5.354451] RIP [<ffffffff81446a68>] strcmp+0x6/0x20
> > [<ffffffff81446a68>] strcmp+0x6/0x20
> > [ 5.354451] RSP <ffff88001204fe28>
> > [ 5.354451] RSP <ffff88001204fe28>
> > [ 5.354451] CR2: ffff88000004e5f0
> > [ 5.354451] CR2: ffff88000004e5f0
> > [ 5.354451] ---[ end trace 8f9377b34c860a0c ]---
> > [ 5.354451] ---[ end trace 8f9377b34c860a0c ]---
> >
> > git bisect start baa21e834941ee5fbe4bd421c871f7c0c5f9a086 70e71ca0af244f48a5dcf56dc435243792e3a495 --
> > git bisect bad 03d6c3b0fa4f5f0379cede079ec828a6c999fe43 # 16:23 0- 1 iwlwifi: pcie: re-ACK all interrupts after device reset
> > git bisect good 0a79a0c011cb291675e3b80760a452fcba5c59d9 # 16:28 20+ 0 iwlwifi: mvm: clear IN_HW_RESTART flag on stop()
> > # first bad commit: [03d6c3b0fa4f5f0379cede079ec828a6c999fe43] iwlwifi: pcie: re-ACK all interrupts after device reset
> > git bisect good 0a79a0c011cb291675e3b80760a452fcba5c59d9 # 16:30 60+ 0 iwlwifi: mvm: clear IN_HW_RESTART flag on stop()
> > # extra tests on HEAD of iwlwifi-fixes/master
> > git bisect bad baa21e834941ee5fbe4bd421c871f7c0c5f9a086 # 16:30 0- 9 iwlwifi: pcie: limit fw chunk sizes given to fh
> > # extra tests on tree/branch iwlwifi-fixes/master
> > git bisect bad baa21e834941ee5fbe4bd421c871f7c0c5f9a086 # 16:30 0- 9 iwlwifi: pcie: limit fw chunk sizes given to fh
> > # extra tests on tree/branch linus/master
> > git bisect good 44e8967d591686463e84a88b46b03beba3ab49fb # 16:32 60+ 0 Ceph: remove left-over reject file
> > # extra tests on tree/branch next/master
> > git bisect good cfaa3a95dd2b402599b1d8122dc3107478db8717 # 16:35 60+ 1 Add linux-next specific files for 20141218
> >
> >
> > This script may reproduce the error.
> >
> > ----------------------------------------------------------------------------
> > #!/bin/bash
> >
> > kernel=$1
> > initrd=quantal-core-x86_64.cgz
> >
> > wget --no-clobber https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
> >
> > kvm=(
> > qemu-system-x86_64
> > -cpu kvm64
> > -enable-kvm
> > -kernel $kernel
> > -initrd $initrd
> > -m 320
> > -smp 2
> > -net nic,vlan=1,model=e1000
> > -net user,vlan=1
> > -boot order=nc
> > -no-reboot
> > -watchdog i6300esb
> > -rtc base=localtime
> > -serial stdio
> > -display none
> > -monitor null
> > )
> >
> > append=(
> > hung_task_panic=1
> > earlyprintk=ttyS0,115200
> > debug
> > apic=debug
> > sysrq_always_enabled
> > rcupdate.rcu_cpu_stall_timeout=100
> > panic=-1
> > softlockup_panic=1
> > nmi_watchdog=panic
> > oops=panic
> > load_ramdisk=2
> > prompt_ramdisk=0
> > console=ttyS0,115200
> > console=tty0
> > vga=normal
> > root=/dev/ram0
> > rw
> > drbd.minor_count=8
> > )
> >
> > "${kvm[@]}" --append "${append[*]}"
> > ----------------------------------------------------------------------------
> >
> > Thanks,
> > Fengguang
> > _______________________________________________
> > LKP mailing list
> > LKP@linux.intel.com
>
^ permalink raw reply
* Re: pull-request: mac80211 2014-12-18
From: David Miller @ 2014-12-18 21:01 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev
In-Reply-To: <1418936069.10864.1.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 18 Dec 2014 21:54:29 +0100
> On Thu, 2014-12-18 at 15:35 -0500, David Miller wrote:
>
>> 1) Don't put things into a merge commit, I take the text from your
>> pull request email and that becomes the merge commit contents.
>> Put it in your pull request email.
>
> Hmm, ok - not sure I fully understand. I don't think I created a merge
> commit, so did you mean the tag? I thought a (signed) tag with contents
> was now the preferred way to send pull requests, but I can also send a
> signed email without a tag for you to merge a branch? Or would you
> prefer a signed tag but empty (is that even possible?) with the text in
> the email?
Anything you do I guess is fine with me, but I'm going to edit the
content that ends up in the merge commit regardless.
>> 2) I want every pull request I get at least CC:'d to netdev.
>
> Ok, sure.
Thanks.
^ permalink raw reply
* Re: [PATCH net] net: drop the packet when fails to do software segmentation or header check
From: David Miller @ 2014-12-18 20:39 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, eric.dumazet
In-Reply-To: <1418882239-6720-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 18 Dec 2014 13:57:19 +0800
> Fixes cecda693a969816bac5e470e1d9c9c0ef5567bca
Please correct this fixes tag, it should be of the form:
Fixes: $(SHA1) ("header text of commit message")
The SHA1 ID should be reduced to 12 digits of significance.
^ permalink raw reply
* Re: [PATCH] stmmac: Don't init ptp again when resume from suspend/hibernation
From: David Miller @ 2014-12-18 20:36 UTC (permalink / raw)
To: chenhc; +Cc: peppe.cavallaro, vbridgers2013, netdev, stable
In-Reply-To: <1418884794-15483-1-git-send-email-chenhc@lemote.com>
Two problems:
1) This post did not reach netdev and therefore did not make it into
patchwork for tracking. You need to correct this.
2) Do not CC: stable on networking changes, instead ask me explicitly
to queue them up for -stable submission and to which trees.
^ permalink raw reply
* Re: pull-request: mac80211 2014-12-18
From: David Miller @ 2014-12-18 20:35 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev
In-Reply-To: <1418911822.6134.13.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 18 Dec 2014 15:10:22 +0100
> Also from me a first pull request - we have a number of really old
> issues that happened to crop up now with new work (or just more testing)
> in the right areas as well as some small bugs newly introduced in 3.19.
>
> Let me know if there are any problems.
Pulled, but:
1) Don't put things into a merge commit, I take the text from your
pull request email and that becomes the merge commit contents.
Put it in your pull request email.
2) I want every pull request I get at least CC:'d to netdev.
> The following changes since commit 5fbea33740aeb948422d7b7e8aafbeac362264b2:
>
> r8169:update rtl8168g pcie ephy parameter (2014-12-11 21:38:52 -0500)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2014-12-18
>
> for you to fetch changes up to 28a9bc68124c319b2b3dc861e80828a8865fd1ba:
>
> mac80211: free management frame keys when removing station (2014-12-17 14:00:17 +0100)
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Marcelo Ricardo Leitner @ 2014-12-18 20:33 UTC (permalink / raw)
To: Prashant Sreedharan, Bjorn Helgaas
Cc: Michael Chan, Rajat Jain, Nils Holland, David Miller, netdev,
linux-pci@vger.kernel.org, Rafael Wysocki
In-Reply-To: <54933491.7020204@gmail.com>
On 18-12-2014 18:09, Marcelo Ricardo Leitner wrote:
> On 18-12-2014 17:28, Prashant Sreedharan wrote:
>> On Thu, 2014-12-18 at 12:15 -0700, Bjorn Helgaas wrote:
>>> On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@broadcom.com> wrote:
>>>> On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
>>>>> It's a
>>>>> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
>>>>> Gigabit Ethernet PCI Express
>>>>> over here
>>>>>
>>>>> I put a WARN_ON(1) after those printks, and this is what I got:
>>>>>
>>>>> [ 1.550640] pci 0000:02:00.0: 1st 1 1
>>>>> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
>>>>> [ 1.550645] ------------[ cut here ]------------
>>>>> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
>>>>> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
>>>>> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
>>>>> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
>>>>> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
>>>>> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
>>>>> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
>>>>> [ 1.550669] Call Trace:
>>>>> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
>>>>> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
>>>>> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
>>>>> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
>>>>> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
>>>>> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
>>>>> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
>>>>> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
>>>>
>>>> So does it work if you use a non-zero crs_timeout? The driver has
>>>> called tg3_halt() which may affect configuration read responses. I need
>>>> to check with the hardware team to see if the 5722 will return CRS in
>>>> this scenario.
>>>
>>> Any updates from the hardware team?
>>>
>>> This is a pretty serious regression, but as far as I can tell, it is
>>> not a PCI bug. The device should respond to a config read of vendor
>>> ID. If the driver does something that make the read return CRS
>>> status, I think the driver is responsible for doing whatever delay or
>>> other fixup is required.
>>>
>>> I'm inclined to reassign this bug to the tg3 driver unless you think
>>> the PCI core is doing something wrong here.
>>>
>>> Bjorn
>>
>> We were not able to reproduce this issue, could you please check what is
>> the value of reg 0x70, before the pci_device_is_present call is made ?
>> if bit 15 is set config access will be retried.
>>
>> --- a/drivers/net/ethernet/broadcom/tg3.c
>> +++ b/drivers/net/ethernet/broadcom/tg3.c
>> @@ -9025,6 +9025,7 @@ static int tg3_chip_reset(struct tg3 *tp)
>> void (*write_op)(struct tg3 *, u32, u32);
>> int i, err;
>>
>> + printk(KERN_ERR "config state: %x\n", tr32(TG3PCI_PCISTATE));
>> if (!pci_device_is_present(tp->pdev))
>> return -ENODEV;
>>
>
> With that PCI patch applied and my debugs, without the timeout hack (so crs_timeout=0):
>
> [ 1.545554] config state: 12b2
> [ 1.548636] pci 0000:02:00.0: 1st 1 1
> [ 1.548637] pci 0000:02:00.0: crs_timeout: 0
> [ 1.548783] tg3 0000:02:00.0 eth0: Tigon3 [partno(BCM95722) rev a200] (PCI Express) MAC address 00:0a:f7:2b:9b:39
> [ 1.548785] tg3 0000:02:00.0 eth0: attached PHY is 5722/5756 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> [ 1.548786] tg3 0000:02:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> [ 1.548787] tg3 0000:02:00.0 eth0: dma_rwctrl[76180000] dma_mask[64-bit]
> [ 1.554389] tg3 0000:02:00.0 p1p1: renamed from eth0
> ...
>
> That's the only time your printk got printed.
My bad, I forgot I had configured the system to not bring that iface up
anymore.. when doing so, just like Nils had too:
[ 1743.678714] tg3 0000:02:00.0: irq 32 for MSI/MSI-X
[ 1745.554039] tg3 0000:02:00.0 p1p1: No firmware running
[ 1745.554724] config state: 12b2
[ 1745.557822] pci 0000:02:00.0: 1st 1 1
[ 1745.557827] pci 0000:02:00.0: crs_timeout: 0
[ 1745.559383] config state: 12b2
[ 1745.562470] pci 0000:02:00.0: 1st 1 1
[ 1745.562471] pci 0000:02:00.0: crs_timeout: 0
Marcelo
^ permalink raw reply
* Re: pull request: bluetooth 2014-12-17
From: David Miller @ 2014-12-18 20:32 UTC (permalink / raw)
To: johan.hedberg; +Cc: netdev, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20141217204614.GA15480@t440s.P-661HNU-F1>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Wed, 17 Dec 2014 22:46:14 +0200
> Here's the first direct (i.e. skipping the wireless tree) bluetooth pull
> request for you, intended for 3.19. It's just one patch: a fix from
> Marcel for for remote service discovery filtering which also fixes a
> 'used uninitialized' compiler warning.
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Nils Holland @ 2014-12-18 20:26 UTC (permalink / raw)
To: Prashant Sreedharan
Cc: Bjorn Helgaas, Marcelo Ricardo Leitner, Michael Chan, Rajat Jain,
David Miller, netdev, linux-pci@vger.kernel.org, Rafael Wysocki
In-Reply-To: <1418930889.3433.8.camel@prashant>
On Thu, Dec 18, 2014 at 11:28:09AM -0800, Prashant Sreedharan wrote:
> On Thu, 2014-12-18 at 12:15 -0700, Bjorn Helgaas wrote:
> >
> > Any updates from the hardware team?
> >
> > This is a pretty serious regression, but as far as I can tell, it is
> > not a PCI bug. The device should respond to a config read of vendor
> > ID. If the driver does something that make the read return CRS
> > status, I think the driver is responsible for doing whatever delay or
> > other fixup is required.
> >
> > I'm inclined to reassign this bug to the tg3 driver unless you think
> > the PCI core is doing something wrong here.
> >
> > Bjorn
>
> We were not able to reproduce this issue, could you please check what is
> the value of reg 0x70, before the pci_device_is_present call is made ?
> if bit 15 is set config access will be retried.
>
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -9025,6 +9025,7 @@ static int tg3_chip_reset(struct tg3 *tp)
> void (*write_op)(struct tg3 *, u32, u32);
> int i, err;
>
> + printk(KERN_ERR "config state: %x\n", tr32(TG3PCI_PCISTATE));
> if (!pci_device_is_present(tp->pdev))
> return -ENODEV;
No problem, I gave this a try and here is what I get:
[ 2.185190] libphy: tg3 mdio bus: probed
[ 2.229357] tsc: Refined TSC clocksource calibration: 2399.999 MHz
[ 2.244993] config state: 1292
[ 2.247136] tg3 0000:02:00.0 eth0: Tigon3 [partno(BCM57780) rev 57780001]
(PCI Express) MAC address 00:19:99:ce:13:a6
[ 2.249279] tg3 0000:02:00.0 eth0: attached PHY driver [Broadcom BCM57780]
(mii_bus:phy_addr=200:01)
[ 2.251460] tg3 0000:02:00.0 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[0] TSOcap[1]
[ 2.253672] tg3 0000:02:00.0 eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[...]
[ 12.204692] tg3 0000:02:00.0
enp2s0: No firmware running
[ 12.206653] config state: 1292
[ 12.208655] config state: 1292
That's all of the three times the new debugging line gets hit when I
boot my system using the supplied diagnostic patch.
Hope that helps - of course, I'd gladly test any further
(diagnostic) patches if required! Also, if I can provide any
additional information that might be of value, just ask:-)
Greetings,
Nils
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: changes for wireless
From: Luca Coelho @ 2014-12-18 20:14 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, John W. Linville
In-Reply-To: <1418836025-9035-1-git-send-email-linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Wed, 2014-12-17 at 12:07 -0500, John W. Linville wrote:
> http://marc.info/?l=linux-wireless&m=141883202530292&w=2
>
> This makes it official... :-)
>
> Signed-off-by: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> ---
> MAINTAINERS | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
[...]
> +NETWORKING DRIVERS (WIRELESS)
> +M: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> +L: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Q: http://patchwork.kernel.org/project/linux-wireless/list/
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/
> +S: Maintained
> +F: drivers/net/wireless/
Kalle, welcome to your new role! I'm sure you're the right person for
the job. You've been the person to thank (or to blame? ;) for getting
me into the Linux Wireless community and you've also been a mentor,
guide and friend along the way. I'm very happy for you and for the
community as a whole, which will certainly benefit from your work!
Thanks for taking the position!
--
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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