* [PATCH] iproute2: Nr. of packets and octets for macsec tx stats were swapped.
From: Daniel.Hopf @ 2016-11-22 13:24 UTC (permalink / raw)
To: netdev
Signed-off-by: Daniel Hopf <daniel.hopf@continental-corporation.com>
---
ip/ipmacsec.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/ip/ipmacsec.c b/ip/ipmacsec.c
index c9252bb..aa89a00 100644
--- a/ip/ipmacsec.c
+++ b/ip/ipmacsec.c
@@ -634,10 +634,10 @@ static void print_one_stat(const char **names,
struct rtattr **attr, int idx,
}
static const char *txsc_stats_names[NUM_MACSEC_TXSC_STATS_ATTR] = {
- [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_PROTECTED] =
"OutOctetsProtected",
- [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_ENCRYPTED] =
"OutOctetsEncrypted",
- [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_PROTECTED] =
"OutPktsProtected",
- [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_ENCRYPTED] =
"OutPktsEncrypted",
+ [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_PROTECTED] = "OutPktsProtected",
+ [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_ENCRYPTED] = "OutPktsEncrypted",
+ [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_PROTECTED] =
"OutOctetsProtected",
+ [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_ENCRYPTED] =
"OutOctetsEncrypted",
};
static void print_txsc_stats(const char *prefix, struct rtattr *attr)
^ permalink raw reply related
* Re: [PATCH] iproute2: Nr. of packets and octets for macsec tx stats were swapped.
From: Sabrina Dubroca @ 2016-11-22 13:56 UTC (permalink / raw)
To: Daniel.Hopf; +Cc: netdev
In-Reply-To: <OFDC737720.EA272892-ONC1258073.00458CA2-C1258073.0049AC0D@continental-corporation.com>
Hi Daniel,
Thanks for fixing this. I noticed it some time ago but it seems
I forgot to send the patch :(
Acked-by: Sabrina Dubroca <sd@queasysnail.net>
Your subject line should be:
Subject: [PATCH iproute2] macsec: Nr.of packets and octets for macsec tx stats were swapped.
with "iproute2" between the brackets.
2016-11-22, 14:24:40 +0100, Daniel.Hopf@continental-corporation.com wrote:
> Signed-off-by: Daniel Hopf <daniel.hopf@continental-corporation.com>
> ---
> ip/ipmacsec.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/ip/ipmacsec.c b/ip/ipmacsec.c
> index c9252bb..aa89a00 100644
> --- a/ip/ipmacsec.c
> +++ b/ip/ipmacsec.c
> @@ -634,10 +634,10 @@ static void print_one_stat(const char **names,
> struct rtattr **attr, int idx,
> }
>
> static const char *txsc_stats_names[NUM_MACSEC_TXSC_STATS_ATTR] = {
> - [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_PROTECTED] =
> "OutOctetsProtected",
> - [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_ENCRYPTED] =
> "OutOctetsEncrypted",
> - [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_PROTECTED] =
> "OutPktsProtected",
> - [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_ENCRYPTED] =
> "OutPktsEncrypted",
> + [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_PROTECTED] = "OutPktsProtected",
> + [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_ENCRYPTED] = "OutPktsEncrypted",
> + [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_PROTECTED] =
> "OutOctetsProtected",
> + [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_ENCRYPTED] =
> "OutOctetsEncrypted",
> };
Your patch was corrupted, probably by your email client, you have
extra newlines everywhere.
Can you send a v2 of this patch? Thanks!
--
Sabrina
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-22 14:16 UTC (permalink / raw)
To: Lars Persson, Giuseppe CAVALLARO
Cc: Joao Pinto, Rayagond Kokatanur, Rabin Vincent, mued dib,
David Miller, Jeff Kirsher, jiri@mellanox.com,
saeedm@mellanox.com, idosch@mellanox.com, netdev,
linux-kernel@vger.kernel.org, CARLOS.PALMINHA@synopsys.com,
Andreas Irestål, alexandre.torgue@st.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <7c7798b5-8cd4-ba99-f526-22d3e06e05db@synopsys.com>
Hi Lars and Peppe,
On 21-11-2016 16:11, Joao Pinto wrote:
> On 21-11-2016 15:43, Lars Persson wrote:
>>
>>
>>> 21 nov. 2016 kl. 16:06 skrev Joao Pinto <Joao.Pinto@synopsys.com>:
>>>
>>>> On 21-11-2016 14:25, Giuseppe CAVALLARO wrote:
>>>>> On 11/21/2016 2:28 PM, Lars Persson wrote:
>>>>>
>>>>>
>>>>>> 21 nov. 2016 kl. 13:53 skrev Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>>>>>>
>>>>>> Hello Joao
>>>>>>
>>>>>>> On 11/21/2016 1:32 PM, Joao Pinto wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>>>>>>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>>>>>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>>>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>>>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a
>>>>>>>>>> single file
>>>>>>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and
>
snip (...)
>>>>>>
>>>>>> Peppe
>>>>>>
>>>>>
>>>>> Hello Joao and others,
>>>>>
>>>
>>> Hi Lars,
>>>
>>>>> As the maintainer of dwc_eth_qos.c I prefer also that we put efforts on the
>>>>> most mature driver, the stmmac.
>>>>>
>>>>> I hope that the code can migrate into an ethernet/synopsys folder to keep the
>>>>> convention of naming the folder after the vendor. This makes it easy for
>>>>> others to find the driver.
>>>>>
>>>>> The dwc_eth_qos.c will eventually be removed and its DT binding interface can
>>>>> then be implemented in the stmmac driver.
>>>
>>> So your ideia is to pick the ethernet/stmmac and rename it to ethernet/synopsys
>>> and try to improve the structure and add the missing QoS features to it?
>>
>> Indeed this is what I prefer.
>
> Ok, it makes sense.
> Just for curiosity the target setup is the following:
> https://www.youtube.com/watch?v=8V-LB5y2Cos
> but instead of using internal drivers, we desire to use mainline drivers only.
>
> Thanks!
Regarding this subject, I am thinking of making the following adaption:
a) delete ethernet/synopsys
b) rename ethernet/stmicro/stmmac to ethernet/synopsys
and send you a patch for you to evaluate. Both agree with the approach?
To have a new work base would be important, because I will add to the "new"
structure some missing QoS features like Multichannel support, CBS and later TSN.
Thanks.
>
>>
>>>
>>>>
>>>> Thanks Lars, I will be happy to support all you on this transition
>>>> and I agree on renaming all.
>>>>
>>>> peppe
>>>>
>>>>
>>>>> - Lars
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> (See http://lists.openwall.net/netdev/2016/02/29/127)
>>>>>>>>>
>>>>>>>>> The former only supports 4.x of the hardware.
>>>>>>>>>
>>>>>>>>> The later supports 4.x and 3.x and already has a platform glue driver
>>>>>>>>> with support for several platforms, a PCI glue driver, and a core driver
>>>>>>>>> with several features not present in the former (for example: TX/RX
>>>>>>>>> interrupt coalescing, EEE, PTP).
>>>>>>>>>
>>>>>>>>> Have you evaluated both drivers? Why have you decided to work on the
>>>>>>>>> former rather than the latter?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
^ permalink raw reply
* [PATCH net] net/mlx4_en: Free netdev resources under state lock
From: Tariq Toukan @ 2016-11-22 14:20 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Eran Ben Elisha, Saeed Mahameed, Sagi Grimberg,
Tariq Toukan, Brenden Blanco
Make sure mlx4_en_free_resources is called under the netdev state lock.
This is needed since RCU dereference of XDP prog should be protected.
Fixes: 326fe02d1ed6 ("net/mlx4_en: protect ring->xdp_prog with rcu_read_lock")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Reported-by: Sagi Grimberg <sagi@grimberg.me>
CC: Brenden Blanco <bblanco@plumgrid.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 3a47e83d3e07..a60f635da78b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -129,6 +129,9 @@ static enum mlx4_net_trans_rule_id mlx4_ip_proto_to_trans_rule_id(u8 ip_proto)
}
};
+/* Must not acquire state_lock, as its corresponding work_sync
+ * is done under it.
+ */
static void mlx4_en_filter_work(struct work_struct *work)
{
struct mlx4_en_filter *filter = container_of(work,
@@ -2189,13 +2192,13 @@ void mlx4_en_destroy_netdev(struct net_device *dev)
mutex_lock(&mdev->state_lock);
mdev->pndev[priv->port] = NULL;
mdev->upper[priv->port] = NULL;
- mutex_unlock(&mdev->state_lock);
#ifdef CONFIG_RFS_ACCEL
mlx4_en_cleanup_filters(priv);
#endif
mlx4_en_free_resources(priv);
+ mutex_unlock(&mdev->state_lock);
kfree(priv->tx_ring);
kfree(priv->tx_cq);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] marvell: mark mvneta and mvpp2 32-bit only
From: Arnd Bergmann @ 2016-11-22 14:21 UTC (permalink / raw)
To: David S. Miller
Cc: Arnd Bergmann, Gregory CLEMENT, Florian Fainelli, Marcin Wojtas,
netdev, linux-kernel
Both of these drivers won't work on 64-bit architectures unless they
are redesigned, since they store a virtual address pointer in a 32-bit
field of the descriptors:
drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_construct':
drivers/net/ethernet/marvell/mvneta_bm.c:103:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_vlan_init':
drivers/net/ethernet/marvell/mvpp2.c:2563:32: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
This limits the COMPILE_TEST option for the two drivers again to
only build them on 32-bit. This seems nicer than shutting up the
warnings, in case we ever actually want to use them on 64-bit,
as the warnings indicate which parts of the driver are currently
broken there.
Fixes: a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/marvell/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index d74d4e6f0b34..66fd9dbb2ca7 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -58,6 +58,7 @@ config MVNETA
tristate "Marvell Armada 370/38x/XP network interface support"
depends on PLAT_ORION || COMPILE_TEST
depends on HAS_DMA
+ depends on !64BIT
select MVMDIO
select FIXED_PHY
---help---
@@ -81,6 +82,7 @@ config MVPP2
tristate "Marvell Armada 375 network interface support"
depends on MACH_ARMADA_375 || COMPILE_TEST
depends on HAS_DMA
+ depends on !64BIT
select MVMDIO
---help---
This driver supports the network interface units in the
--
2.9.0
^ permalink raw reply related
* [PATCH net-next] net/sched: cls_flower: verify root pointer before dereferncing it
From: Roi Dayan @ 2016-11-22 14:25 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Jiri Pirko, Cong Wang, Or Gerlitz, Roi Dayan, Cong Wang
tp->root is being allocated in init() time and kfreed in destroy()
however it is being dereferenced in classify() path.
We could be in classify() path after destroy() was called and thus
tp->root is null. Verifying if tp->root is null in classify() path
is enough because it's being freed with kfree_rcu() and classify()
path is under rcu_read_lock().
Fixes: 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone")
Signed-off-by: Roi Dayan <roid@mellanox.com>
Cc: Cong Wang <cwang@twopensource.com>
---
Hi Cong, all
As stated above, the issue was introduced with commit 1e052be69d04 ("net_sched: destroy
proto tp when all filters are gone"). This patch provides a fix only for cls_flower where
I succeeded in reproducing the issue. Cong, if you can/want to come up with a fix that
will be applicable for all the others classifiners, I am fine with that.
Thanks,
Roi
net/sched/cls_flower.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index e8dd09a..88a26c4 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -135,7 +135,7 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
struct fl_flow_key skb_mkey;
struct ip_tunnel_info *info;
- if (!atomic_read(&head->ht.nelems))
+ if (!head || !atomic_read(&head->ht.nelems))
return -1;
fl_clear_masked_range(&skb_key, &head->mask);
--
2.7.4
^ permalink raw reply related
* Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
From: Valo, Kalle @ 2016-11-22 14:55 UTC (permalink / raw)
To: Bjorn Andersson
Cc: k.eugene.e@gmail.com, Andy Gross, wcn36xx@lists.infradead.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
In-Reply-To: <20161118183541.GI28340@tuxbot>
Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>
>> Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
>> > The correct include file for getting errno constants and ERR_PTR() is
>> > linux/err.h, rather than linux/errno.h, so fix the include.
>> >
>> > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled smem_state")
>> > Acked-by: Andy Gross <andy.gross@linaro.org>
>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>
>> For some reason this fails to compile now. Can you take a look, please?
>>
>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko] undefined!
>> make[1]: *** [__modpost] Error 1
>> make: *** [modules] Error 2
>>
>> 5 patches set to Changes Requested.
>>
>> 9429045 [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
>> 9429047 [v5,2/5] wcn36xx: Transition driver to SMD client
>
> This patch was updated with the necessary depends in Kconfig to catch
> this exact issue and when I pull in your .config (which has QCOM_SMD=n,
> QCOM_WCNSS_CTRL=n and WCN36XX=y) I can build this just fine.
>
> I've tested the various combinations and it seems to work fine. Do you
> have any other patches in your tree?
This was with the pending branch of my ath.git tree. There are other
wireless patches (ath10k etc) but I would guess they don't affect here.
> Any stale objects?
Not sure what you mean with this question, but I didn't run 'make clean'
if that's what you are asking.
> Would you mind retesting this, before I invest more time in trying to
> reproduce the issue you're seeing?
Sure, I'll take a look but that might take few days.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] net/phy: add trace events for mdio accesses
From: Steven Rostedt @ 2016-11-22 14:55 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Florian Fainelli, Ingo Molnar, netdev
In-Reply-To: <20161122100127.5940-1-uwe@kleine-koenig.org>
On Tue, 22 Nov 2016 11:01:27 +0100
Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> diff --git a/include/trace/events/mdio.h b/include/trace/events/mdio.h
> new file mode 100644
> index 000000000000..468e2d095d19
> --- /dev/null
> +++ b/include/trace/events/mdio.h
> @@ -0,0 +1,42 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM mdio
> +
> +#if !defined(_TRACE_MDIO_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_MDIO_H
> +
> +#include <linux/tracepoint.h>
> +
> +TRACE_EVENT_CONDITION(mdio_access,
> +
> + TP_PROTO(struct mii_bus *bus, int read,
> + unsigned addr, unsigned regnum, u16 val, int err),
> +
> + TP_ARGS(bus, read, addr, regnum, val, err),
> +
> + TP_CONDITION(err >= 0),
> +
> + TP_STRUCT__entry(
> + __array(char, busid, MII_BUS_ID_SIZE)
> + __field(int, read)
read is just a 0 or 1. What about making it a char? That way we can
pack this better. If I'm not mistaken, MII_BUS_ID_SIZE is (20 - 3) or
17. If read is just one byte, then it can fit in one of those three
bytes, and you save 4 extra bytes (assuming addr will be 4 byte
aligned).
-- Steve
> + __field(unsigned, addr)
> + __field(unsigned, regnum)
> + __field(u16, val)
> + ),
> +
> + TP_fast_assign(
> + strncpy(__entry->busid, bus->id, MII_BUS_ID_SIZE);
> + __entry->read = read;
> + __entry->addr = addr;
> + __entry->regnum = regnum;
> + __entry->val = val;
> + ),
> +
> + TP_printk("%s %-5s phy:0x%02x reg:0x%02x val:0x%04hx",
> + __entry->busid, __entry->read ? "read" : "write",
> + __entry->addr, __entry->regnum, __entry->val)
> +);
> +
> +#endif /* if !defined(_TRACE_MDIO_H) || defined(TRACE_HEADER_MULTI_READ) */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
^ permalink raw reply
* Re: [PATCHv2 net-next 00/11] Start adding support for mv88e6390
From: David Miller @ 2016-11-22 14:56 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, netdev
In-Reply-To: <1479767225-13789-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Mon, 21 Nov 2016 23:26:54 +0100
> This is the first patchset implementing support for the mv88e6390
> family. This is a new generation of switch devices and has numerous
> incompatible changes to the registers. These patches allow the switch
> to the detected during probe, and makes the statistics unit work.
>
> These patches are insufficient to make the mv88e6390 functional. More
> patches will follow.
>
> v2:
> Move stats code into global1
> Change DT compatible string to mv88e6190
> Fixed mv88e6351 stats which v1 had broken
Series applied, thanks Andrew.
^ permalink raw reply
* Re: [net-next PATCH v2 3/5] virtio_net: Add XDP support
From: Michael S. Tsirkin @ 2016-11-22 14:58 UTC (permalink / raw)
To: John Fastabend
Cc: daniel, eric.dumazet, kubakici, shm, davem, alexei.starovoitov,
netdev, bblanco, john.r.fastabend, brouer, tgraf
In-Reply-To: <58340157.8060103@gmail.com>
On Tue, Nov 22, 2016 at 12:27:03AM -0800, John Fastabend wrote:
> On 16-11-21 03:20 PM, Michael S. Tsirkin wrote:
> > On Sat, Nov 19, 2016 at 06:50:33PM -0800, John Fastabend wrote:
> >> From: Shrijeet Mukherjee <shrijeet@gmail.com>
> >>
> >> This adds XDP support to virtio_net. Some requirements must be
> >> met for XDP to be enabled depending on the mode. First it will
> >> only be supported with LRO disabled so that data is not pushed
> >> across multiple buffers. The MTU must be less than a page size
> >> to avoid having to handle XDP across multiple pages.
> >>
> >> If mergeable receive is enabled this first series only supports
> >> the case where header and data are in the same buf which we can
> >> check when a packet is received by looking at num_buf. If the
> >> num_buf is greater than 1 and a XDP program is loaded the packet
> >> is dropped and a warning is thrown. When any_header_sg is set this
> >> does not happen and both header and data is put in a single buffer
> >> as expected so we check this when XDP programs are loaded. Note I
> >> have only tested this with Linux vhost backend.
> >>
> >> If big packets mode is enabled and MTU/LRO conditions above are
> >> met then XDP is allowed.
> >>
> >> A follow on patch can be generated to solve the mergeable receive
> >> case with num_bufs equal to 2. Buffers greater than two may not
> >> be handled has easily.
> >
> >
> > I would very much prefer support for other layouts without drops
> > before merging this.
> > header by itself can certainly be handled by skipping it.
> > People wanted to use that e.g. for zero copy.
>
> OK fair enough I'll do this now rather than push it out.
>
> >
> > Anything else can be handled by copying the packet.
>
> This though I'm not so sure about. The copy is going to be slow and
> I wonder if someone could craft a packet to cause this if it could
> be used to slow down a system.
Device can always linearize if it wants to. If device is malicious
it's hard for OS to defend itself.
> Also I can't see what would cause this to happen. With mergeable
> buffers and LRO off the num_bufs is either 1 or 2 depending on where
> the header is. Otherwise with LRO off it should be in a single page.
> At least this is the Linux vhost implementation, I guess other
> implementation might meet spec but use num_buf > 2 or multiple pages
> even in the non LRO case.
Me neither but then not a long time ago we always placed
header in a separate entry until we saw the extra s/g has
measureable overhead.
network broken is kind of a heavy handed thing, making debugging
impossible for many people.
> I tend to think dropping the packet out right is better than copying
> it around. At very least if we do this we need to put in warnings so
> users can see something is mis-configured.
>
> .John
Yes, I think that's a good idea.
--
MST
^ permalink raw reply
* Re: [net-next PATCH v2 4/5] virtio_net: add dedicated XDP transmit queues
From: Michael S. Tsirkin @ 2016-11-22 14:59 UTC (permalink / raw)
To: John Fastabend
Cc: daniel, eric.dumazet, kubakici, shm, davem, alexei.starovoitov,
netdev, bblanco, john.r.fastabend, brouer, tgraf
In-Reply-To: <5833FF24.2010800@gmail.com>
On Tue, Nov 22, 2016 at 12:17:40AM -0800, John Fastabend wrote:
> On 16-11-21 03:13 PM, Michael S. Tsirkin wrote:
> > On Sat, Nov 19, 2016 at 06:51:04PM -0800, John Fastabend wrote:
> >> XDP requires using isolated transmit queues to avoid interference
> >> with normal networking stack (BQL, NETDEV_TX_BUSY, etc). This patch
> >> adds a XDP queue per cpu when a XDP program is loaded and does not
> >> expose the queues to the OS via the normal API call to
> >> netif_set_real_num_tx_queues(). This way the stack will never push
> >> an skb to these queues.
> >>
> >> However virtio/vhost/qemu implementation only allows for creating
> >> TX/RX queue pairs at this time so creating only TX queues was not
> >> possible. And because the associated RX queues are being created I
> >> went ahead and exposed these to the stack and let the backend use
> >> them. This creates more RX queues visible to the network stack than
> >> TX queues which is worth mentioning but does not cause any issues as
> >> far as I can tell.
> >>
> >> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> >
> > FYI what's supposed to happen is packets from the same
> > flow going in the reverse direction will go on the
> > same queue.
> >
> > This might come in handy when implementing RX XDP.
> >
>
> Yeah but if its the first packet not part of a flow then presumably it
> can pick any queue but its worth keeping in mind certainly.
>
> .John
Oh I agree, absolutely. This was just a FYI in case it comes useful
as an optimization down the road.
--
MST
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: egress all frames
From: Andrew Lunn @ 2016-11-22 15:03 UTC (permalink / raw)
To: Stefan Eichenberger
Cc: vivien.didelot, f.fainelli, netdev, Stefan Eichenberger
In-Reply-To: <20161122103944.31381-1-stefan.eichenberger@netmodule.com>
On Tue, Nov 22, 2016 at 11:39:44AM +0100, Stefan Eichenberger wrote:
> Egress multicast and egress unicast is only enabled for CPU/DSA ports
> but for switching operation it seems it should be enabled for all ports.
> Do I miss something here?
>
> I did the following test:
> brctl addbr br0
> brctl addif br0 lan0
> brctl addif br0 lan1
>
> In this scenario the unicast and multicast packets were not forwarded,
> therefore ARP requests were not resolved, and no connection could be
> established.
Hi Stefan
This is probably specific to the 6097 family. It works fine without
this on other devices. Creating a bridge like above and pinging across
it is one of my standard tests. But i only test modern devices like
the 6165, 6352, 6351, 6390 families.
In fact, you might need to review all the code and look where
mv88e6xxx_6095_family(chip) is used and consider if you need to add
mv88e6xxx_6097_family(chip). e.g.
if (mv88e6xxx_6095_family(chip) || mv88e6xxx_6185_family(chip)) {
/* Set the upstream port this port should use */
reg |= dsa_upstream_port(ds);
/* enable forwarding of unknown multicast addresses to
* the upstream port
*/
if (port == dsa_upstream_port(ds))
reg |= PORT_CONTROL_2_FORWARD_UNKNOWN;
}
Maybe this is your problem?
Andrew
^ permalink raw reply
* Re: [patch net-next 0/2] mlxsw: core: Implement thermal zone
From: David Miller @ 2016-11-22 15:04 UTC (permalink / raw)
To: jiri; +Cc: netdev, cera, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz
In-Reply-To: <1479810253-9114-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 22 Nov 2016 11:24:11 +0100
> Implement thermal zone for mlxsw based HW.
> The first patch is just a register dependency for the second patch.
Looks good, series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net/sched: cls_flower: verify root pointer before dereferncing it
From: Jiri Pirko @ 2016-11-22 14:48 UTC (permalink / raw)
To: Roi Dayan
Cc: David S. Miller, netdev, Jiri Pirko, Cong Wang, Or Gerlitz,
Cong Wang
In-Reply-To: <1479824726-62607-1-git-send-email-roid@mellanox.com>
Tue, Nov 22, 2016 at 03:25:26PM CET, roid@mellanox.com wrote:
>tp->root is being allocated in init() time and kfreed in destroy()
>however it is being dereferenced in classify() path.
>
>We could be in classify() path after destroy() was called and thus
>tp->root is null. Verifying if tp->root is null in classify() path
>is enough because it's being freed with kfree_rcu() and classify()
>path is under rcu_read_lock().
>
>Fixes: 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone")
>Signed-off-by: Roi Dayan <roid@mellanox.com>
>Cc: Cong Wang <cwang@twopensource.com>
This is correct
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
The other way to fix this would be to move tp->ops->destroy call to
call_rcu phase. That would require bigger changes though. net-next
perhaps?
>---
>
>Hi Cong, all
>
>As stated above, the issue was introduced with commit 1e052be69d04 ("net_sched: destroy
>proto tp when all filters are gone"). This patch provides a fix only for cls_flower where
>I succeeded in reproducing the issue. Cong, if you can/want to come up with a fix that
>will be applicable for all the others classifiners, I am fine with that.
>
>Thanks,
>Roi
>
>
> net/sched/cls_flower.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
>index e8dd09a..88a26c4 100644
>--- a/net/sched/cls_flower.c
>+++ b/net/sched/cls_flower.c
>@@ -135,7 +135,7 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
> struct fl_flow_key skb_mkey;
> struct ip_tunnel_info *info;
>
>- if (!atomic_read(&head->ht.nelems))
>+ if (!head || !atomic_read(&head->ht.nelems))
> return -1;
>
> fl_clear_masked_range(&skb_key, &head->mask);
>--
>2.7.4
>
^ permalink raw reply
* Re: [PATCH] ipv6:ipv6_pinfo dereferenced after NULL check
From: David Miller @ 2016-11-22 15:06 UTC (permalink / raw)
To: hannes
Cc: manjeet.p, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
pankaj.m, ajeet.y, r.thapliyal
In-Reply-To: <611c167e-cef4-691b-f154-1b6b6aa86e53@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 22 Nov 2016 13:26:45 +0100
> On 22.11.2016 07:27, Manjeet Pawar wrote:
>> From: Rohit Thapliyal <r.thapliyal@samsung.com>
>>
>> np checked for NULL and then dereferenced. It should be modified
>> for NULL case.
>>
>> Signed-off-by: Rohit Thapliyal <r.thapliyal@samsung.com>
>> Signed-off-by: Manjeet Pawar <manjeet.p@samsung.com>
>> ---
>> net/ipv6/ip6_output.c | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>> index 1dfc402..c2afa14 100644
>> --- a/net/ipv6/ip6_output.c
>> +++ b/net/ipv6/ip6_output.c
>> @@ -205,14 +205,15 @@ int ip6_xmit(const struct sock *sk, struct sk_buff *skb, struct flowi6 *fl6,
>> /*
>> * Fill in the IPv6 header
>> */
>> - if (np)
>> + if (np) {
>> hlimit = np->hop_limit;
>> + ip6_flow_hdr(
>> + hdr, tclass, ip6_make_flowlabel(
>> + net, skb, fl6->flowlabel,
>> + np->autoflowlabel, fl6));
>> + }
>> if (hlimit < 0)
>> hlimit = ip6_dst_hoplimit(dst);
>>
>> - ip6_flow_hdr(hdr, tclass, ip6_make_flowlabel(net, skb, fl6->flowlabel,
>> - np->autoflowlabel, fl6));
>> -
>> hdr->payload_len = htons(seg_len);
>> hdr->nexthdr = proto;
>> hdr->hop_limit = hlimit;
>>
>
>
> We always should initialize hdr and not skip the ip6_flow_hdr call.
>
> Do you saw a bug or did you find this by code review? I wonder if np can
> actually be NULL at this point. Maybe we can just eliminate the NULL check.
Also the indentation is really off.
^ permalink raw reply
* Re: [PATCH] fec: Always write MAC address to controller register
From: David Miller @ 2016-11-22 15:07 UTC (permalink / raw)
To: daniel.krueger; +Cc: fugang.duan, netdev, alexander.stein
In-Reply-To: <038ccd3c-6d77-d9e1-92e1-c41572684812@systec-electronic.com>
This change is already in the tree via commit
b82d44d78480faff7456e9e0999acb9d38666057 made nearly
two months ago:
commit b82d44d78480faff7456e9e0999acb9d38666057
Author: Gavin Schenk <g.schenk@eckelmann.de>
Date: Fri Sep 30 11:46:10 2016 +0200
net: fec: set mac address unconditionally
If the mac address origin is not dt, you can only safely assign a mac
address after "link up" of the device. If the link is off the clocks are
disabled and because of issues assigning registers when clocks are off the
new mac address cannot be written in .ndo_set_mac_address() on some soc's.
This fix sets the mac address unconditionally in fec_restart(...) and
ensures consistency between fec registers and the network layer.
Signed-off-by: Gavin Schenk <g.schenk@eckelmann.de>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 9638d19e4816 ("net: fec: add netif status check before set mac address")
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 1fa2d87..48a033e 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -913,13 +913,11 @@ fec_restart(struct net_device *ndev)
* enet-mac reset will reset mac address registers too,
* so need to reconfigure it.
*/
- if (fep->quirks & FEC_QUIRK_ENET_MAC) {
- memcpy(&temp_mac, ndev->dev_addr, ETH_ALEN);
- writel((__force u32)cpu_to_be32(temp_mac[0]),
- fep->hwp + FEC_ADDR_LOW);
- writel((__force u32)cpu_to_be32(temp_mac[1]),
- fep->hwp + FEC_ADDR_HIGH);
- }
+ memcpy(&temp_mac, ndev->dev_addr, ETH_ALEN);
+ writel((__force u32)cpu_to_be32(temp_mac[0]),
+ fep->hwp + FEC_ADDR_LOW);
+ writel((__force u32)cpu_to_be32(temp_mac[1]),
+ fep->hwp + FEC_ADDR_HIGH);
/* Clear any outstanding interrupt. */
writel(0xffffffff, fep->hwp + FEC_IEVENT);
^ permalink raw reply related
* Re: [PATCH] net: dsa: mv88e6xxx: add MV88E6097 switch
From: Andrew Lunn @ 2016-11-22 15:07 UTC (permalink / raw)
To: Stefan Eichenberger
Cc: vivien.didelot, f.fainelli, netdev, Stefan Eichenberger
In-Reply-To: <20161122102836.23980-1-stefan.eichenberger@netmodule.com>
On Tue, Nov 22, 2016 at 11:28:36AM +0100, Stefan Eichenberger wrote:
> Add support for the MV88E6097 switch. The change was tested on an Armada
> based platform with a MV88E6097 switch.
Hi Stefan
Please can you based your patches on net-next. You will then find the
ops structure has gained a few more entries.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] marvell: mark mvneta and mvpp2 32-bit only
From: Gregory CLEMENT @ 2016-11-22 15:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Florian Fainelli, Marcin Wojtas, netdev,
linux-kernel
In-Reply-To: <20161122142136.1690096-1-arnd@arndb.de>
Hi Arnd,
On mar., nov. 22 2016, Arnd Bergmann <arnd@arndb.de> wrote:
> Both of these drivers won't work on 64-bit architectures unless they
> are redesigned, since they store a virtual address pointer in a 32-bit
> field of the descriptors:
>
> drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_construct':
> drivers/net/ethernet/marvell/mvneta_bm.c:103:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_vlan_init':
> drivers/net/ethernet/marvell/mvpp2.c:2563:32: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
>
> This limits the COMPILE_TEST option for the two drivers again to
> only build them on 32-bit. This seems nicer than shutting up the
> warnings, in case we ever actually want to use them on 64-bit,
> as the warnings indicate which parts of the driver are currently
Actually we are using these drivers on 64-bits so obviously there are
not 32 bits only!
For mvneta currently we do not use BM on the 64-bits version. I agree
that there is a problem with mvneta_bm.c when building in 64-bits but it
should not prevent us to use the mvneta driver.
Gregory
> broken there.
>
> Fixes: a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ethernet/marvell/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
> index d74d4e6f0b34..66fd9dbb2ca7 100644
> --- a/drivers/net/ethernet/marvell/Kconfig
> +++ b/drivers/net/ethernet/marvell/Kconfig
> @@ -58,6 +58,7 @@ config MVNETA
> tristate "Marvell Armada 370/38x/XP network interface support"
> depends on PLAT_ORION || COMPILE_TEST
> depends on HAS_DMA
> + depends on !64BIT
> select MVMDIO
> select FIXED_PHY
> ---help---
> @@ -81,6 +82,7 @@ config MVPP2
> tristate "Marvell Armada 375 network interface support"
> depends on MACH_ARMADA_375 || COMPILE_TEST
> depends on HAS_DMA
> + depends on !64BIT
> select MVMDIO
> ---help---
> This driver supports the network interface units in the
> --
> 2.9.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net-next] marvell: mark mvneta and mvpp2 32-bit only
From: David Miller @ 2016-11-22 15:09 UTC (permalink / raw)
To: arnd; +Cc: gregory.clement, f.fainelli, mw, netdev, linux-kernel
In-Reply-To: <20161122142136.1690096-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 22 Nov 2016 15:21:22 +0100
> Both of these drivers won't work on 64-bit architectures unless they
> are redesigned, since they store a virtual address pointer in a 32-bit
> field of the descriptors:
>
> drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_construct':
> drivers/net/ethernet/marvell/mvneta_bm.c:103:16: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_vlan_init':
> drivers/net/ethernet/marvell/mvpp2.c:2563:32: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
>
> This limits the COMPILE_TEST option for the two drivers again to
> only build them on 32-bit. This seems nicer than shutting up the
> warnings, in case we ever actually want to use them on 64-bit,
> as the warnings indicate which parts of the driver are currently
> broken there.
>
> Fixes: a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Ok, this is a reasonable thing to do for now until the 64-bit patches
are sorted out.
Applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCH v2] net/phy: add trace events for mdio accesses
From: Andrew Lunn @ 2016-11-22 15:19 UTC (permalink / raw)
To: Steven Rostedt
Cc: Uwe Kleine-König, Florian Fainelli, Ingo Molnar, netdev
In-Reply-To: <20161122095521.73d9c746@gandalf.local.home>
On Tue, Nov 22, 2016 at 09:55:21AM -0500, Steven Rostedt wrote:
> On Tue, 22 Nov 2016 11:01:27 +0100
> Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
>
> > diff --git a/include/trace/events/mdio.h b/include/trace/events/mdio.h
> > new file mode 100644
> > index 000000000000..468e2d095d19
> > --- /dev/null
> > +++ b/include/trace/events/mdio.h
> > @@ -0,0 +1,42 @@
> > +#undef TRACE_SYSTEM
> > +#define TRACE_SYSTEM mdio
> > +
> > +#if !defined(_TRACE_MDIO_H) || defined(TRACE_HEADER_MULTI_READ)
> > +#define _TRACE_MDIO_H
> > +
> > +#include <linux/tracepoint.h>
> > +
> > +TRACE_EVENT_CONDITION(mdio_access,
> > +
> > + TP_PROTO(struct mii_bus *bus, int read,
> > + unsigned addr, unsigned regnum, u16 val, int err),
> > +
> > + TP_ARGS(bus, read, addr, regnum, val, err),
> > +
> > + TP_CONDITION(err >= 0),
> > +
> > + TP_STRUCT__entry(
> > + __array(char, busid, MII_BUS_ID_SIZE)
> > + __field(int, read)
>
> read is just a 0 or 1. What about making it a char? That way we can
> pack this better. If I'm not mistaken, MII_BUS_ID_SIZE is (20 - 3) or
> 17. If read is just one byte, then it can fit in one of those three
> bytes, and you save 4 extra bytes (assuming addr will be 4 byte
> aligned).
addr could also be cast into a u8. There are a maximum of 32
addresses on an MDIO bus. Because of clause 45 MDIO, regnum needs to
remain a u32.
Andrew
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Michal Kazior @ 2016-11-22 15:22 UTC (permalink / raw)
To: Pali Rohár
Cc: Kalle Valo, Pavel Machek, Ivaylo Dimitrov, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161121155153.GM13735@pali>
On 21 November 2016 at 16:51, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
>> Hi! I will open discussion about mac address and calibration data for
>> wl1251 wireless chip again...
>>
>> Problem: Mac address & calibration data for wl1251 chip on Nokia N900
>> are stored on second nand partition (mtd1) in special proprietary format
>> which is used only for Nokia N900 (probably on N8x0 and N9 too).
>> Wireless driver wl1251.ko cannot work without mac address and
>> calibration data.
Same problem applies to some ath9k/ath10k supported routers. Some even
carry mac address as implicit offset from ethernet mac address. As far
as I understand OpenWRT cooks cal blobs on first boot prior to loading
modules.
>> Absence of mac address cause that driver generates random mac address at
>> every kernel boot which has couple of problems (unstable identifier of
>> wireless device due to udev permanent storage rules; unpredictable
>> behaviour for dhcp mac address assignment, mac address filtering, ...).
>>
>> Currently there is no way to set (permanent) mac address for network
>> interface from userspace. And it does not make sense to implement in
>> linux kernel large parser for proprietary format of second nand
>> partition where is mac address stored only for one device -- Nokia N900.
>>
>> Driver wl1251.ko loads calibration data via request_firmware() for file
>> wl1251-nvs.bin. There are some "example" calibration file in linux-
>> firmware repository, but it is not suitable for normal usage as real
>> calibration data are per-device specific.
You could hook up a script that cooks up the cal/mac file via
modprobe's install hook, no?
Michał
^ permalink raw reply
* Re: [RFC net-next 0/3] net: bridge: Allow CPU port configuration
From: Vivien Didelot @ 2016-11-22 15:29 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: idosch, andrew, Florian Fainelli, bridge, jiri, davem
In-Reply-To: <20161121190925.14530-1-f.fainelli@gmail.com>
Hi Florian,
Florian Fainelli <f.fainelli@gmail.com> writes:
> This patch series allows using the bridge master interface to configure
> an Ethernet switch port's CPU/management port with different VLAN attributes than
> those of the bridge downstream ports/members.
>
> Jiri, Ido, Andrew, Vivien, please review the impact on mlxsw and mv88e6xxx, I
> tested this with b53 and a mockup DSA driver.
Patchset looks fine to me overall. I'm cooking a patch similar to 3/3
for mv88e6xxx to put on top of this patchset.
Minor comments in individual patchs will follow.
> Open questions:
>
> - if we have more than one bridge on top of a physical switch, the driver
> should keep track of that and verify that we are not going to change
> the CPU port VLAN attributes in a way that results in incompatible settings
> to be applied
In mv88e6xxx, mv88e6xxx_port_check_hw_vlan() does that. It needs a small
adjustment though.
> - if the default behavior is to have all VLANs associated with the CPU port
> be ingressing/egressing tagged to the CPU, is this really useful?
I have no strong opinion on this. Intuitively I'd expect the CPU port to
be excluded until I add it myself, but I didn't think much about it.
Thanks,
Vivien
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-22 15:31 UTC (permalink / raw)
To: Michal Kazior
Cc: Kalle Valo, Pavel Machek, Ivaylo Dimitrov, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <CA+BoTQm5yZYccMherMnmxZ0_b2PqkCWf_0nBoRLzsro-Ujz1eQ@mail.gmail.com>
On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
> On 21 November 2016 at 16:51, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
> >> Hi! I will open discussion about mac address and calibration data for
> >> wl1251 wireless chip again...
> >>
> >> Problem: Mac address & calibration data for wl1251 chip on Nokia N900
> >> are stored on second nand partition (mtd1) in special proprietary format
> >> which is used only for Nokia N900 (probably on N8x0 and N9 too).
> >> Wireless driver wl1251.ko cannot work without mac address and
> >> calibration data.
>
> Same problem applies to some ath9k/ath10k supported routers. Some even
> carry mac address as implicit offset from ethernet mac address. As far
> as I understand OpenWRT cooks cal blobs on first boot prior to loading
> modules.
So... wl1251 on Nokia N900 is not alone and this problem is there for
more drivers and devices. Which means we should come up with some
generic solution.
> >> Absence of mac address cause that driver generates random mac address at
> >> every kernel boot which has couple of problems (unstable identifier of
> >> wireless device due to udev permanent storage rules; unpredictable
> >> behaviour for dhcp mac address assignment, mac address filtering, ...).
> >>
> >> Currently there is no way to set (permanent) mac address for network
> >> interface from userspace. And it does not make sense to implement in
> >> linux kernel large parser for proprietary format of second nand
> >> partition where is mac address stored only for one device -- Nokia N900.
> >>
> >> Driver wl1251.ko loads calibration data via request_firmware() for file
> >> wl1251-nvs.bin. There are some "example" calibration file in linux-
> >> firmware repository, but it is not suitable for normal usage as real
> >> calibration data are per-device specific.
>
> You could hook up a script that cooks up the cal/mac file via
> modprobe's install hook, no?
Via modprobe hook I can either pass custom module parameter or call any
other system (shell) commands.
As wl1251.ko does not accept mac_address as module parameter, such
modprobe hook does not help -- as there is absolutely no way from
userspace to set or change (permanent) mac address.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH v3 3/5] net: asix: Fix AX88772x resume failures
From: Jon Hunter @ 2016-11-22 15:34 UTC (permalink / raw)
To: allan, robert.foss, freddy, Dean_Jenkins, Mark_Craske, davem,
ivecera, john.stultz, vpalatin, stephen, grundler, changchias,
andrew, tremyfr, colin.king, linux-usb, netdev, linux-kernel,
vpalatin
In-Reply-To: <1fff2d2a-7bbe-298c-3d27-7dc44df08675@nvidia.com>
Hi Allan,
On 18/11/16 15:09, Jon Hunter wrote:
> Hi Allan,
>
> On 14/11/16 09:45, ASIX_Allan [Office] wrote:
>> Hi Jon,
>>
>> Please help to double check if the USB host controller of your Terga
>> platform had been powered OFF while running the ax88772_suspend() routine or
>> not?
>
> Sorry for the delay. Today I set up a local board to reproduce this on
> and was able to recreate the same problem. The Tegra xhci driver does
> not power off during suspend and simply calls xhci_suspend(). I also
> checked vbus to see if it was turning off but it is not. Furthermore I
> don't see a new USB device detected after the error and so I don't see
> any evidence that it ever disconnects.
In an attempt to isolate if this is a Tegra issue or not, I recompiled
v4.9-rc6 for x86 and I was able to reproduce the problem on my desktop ...
[ 256.030060] PM: Syncing filesystems ... done.
[ 256.113925] PM: Preparing system for sleep (mem)
[ 256.114119] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 256.116701] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 256.118041] PM: Suspending system (mem)
[ 256.118058] Suspending console(s) (use no_console_suspend to debug)
[ 256.118324] asix 1-1.2:1.0 eth2: Failed to read reg index 0x0000: -19
[ 256.118327] asix 1-1.2:1.0 eth2: Error reading Medium Status register: ffffffed
[ 256.118329] asix 1-1.2:1.0 eth2: Failed to write reg index 0x0000: -19
[ 256.118332] asix 1-1.2:1.0 eth2: Failed to write Medium Mode mode to 0xfeed: ffffffed
[ 256.118374] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 256.118471] sd 0:0:0:0: [sda] Stopping disk
[ 256.152992] hpet1: lost 1 rtc interrupts
[ 256.153893] serial 00:06: disabled
[ 256.153899] serial 00:06: System wakeup disabled by ACPI
[ 256.154068] e1000e: EEE TX LPI TIMER: 00000011
[ 256.628281] PM: suspend of devices complete after 509.782 msecs
[ 256.628620] PM: late suspend of devices complete after 0.336 msecs
[ 256.629366] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
[ 256.629595] tg3 0000:03:00.0: System wakeup enabled by ACPI
[ 256.629601] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
[ 256.629652] e1000e 0000:00:19.0: System wakeup enabled by ACPI
[ 256.629812] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 256.648347] PM: noirq suspend of devices complete after 19.713 msecs
[ 256.648685] ACPI: Preparing to enter system sleep state S3
[ 256.668275] PM: Saving platform NVS memory
[ 256.668283] Disabling non-boot CPUs ...
To reproduce this, I did the following:
1. Connect the asix device and noted the net interface (ie. eth2)
2. Disabled the interface (ie. sudo ifconfig eth2 down)
3. Ran a suspend-resume cycle using rtcwake (eg. sudo rtcwake -d rtc0 -m mem -s 5)
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH net-next] net/sched: cls_flower: verify root pointer before dereferncing it
From: David Miller @ 2016-11-22 15:37 UTC (permalink / raw)
To: jiri; +Cc: roid, netdev, jiri, xiyou.wangcong, ogerlitz, cwang
In-Reply-To: <20161122144844.GB1819@nanopsycho>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 22 Nov 2016 15:48:44 +0100
> Tue, Nov 22, 2016 at 03:25:26PM CET, roid@mellanox.com wrote:
>>tp->root is being allocated in init() time and kfreed in destroy()
>>however it is being dereferenced in classify() path.
>>
>>We could be in classify() path after destroy() was called and thus
>>tp->root is null. Verifying if tp->root is null in classify() path
>>is enough because it's being freed with kfree_rcu() and classify()
>>path is under rcu_read_lock().
>>
>>Fixes: 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone")
>>Signed-off-by: Roi Dayan <roid@mellanox.com>
>>Cc: Cong Wang <cwang@twopensource.com>
>
> This is correct
>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>
> The other way to fix this would be to move tp->ops->destroy call to
> call_rcu phase. That would require bigger changes though. net-next
> perhaps?
This patch is targetted at net-next as per Subj.
^ 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