* [PATCH net] ipv6: correctly add local routes when lo goes up
From: Nicolas Dichtel @ 2016-10-12 8:10 UTC (permalink / raw)
To: davem
Cc: netdev, Nicolas Dichtel, Balakumaran Kannan, Maruthi Thotad,
Sabrina Dubroca, Hannes Frederic Sowa, Weilong Chen, Gao feng
The goal of the patch is to fix this scenario:
ip link add dummy1 type dummy
ip link set dummy1 up
ip link set lo down ; ip link set lo up
After that sequence, the local route to the link layer address of dummy1 is
not there anymore.
When the loopback is set down, all local routes are deleted by
addrconf_ifdown()/rt6_ifdown(). At this time, the rt6_info entry still
exists, because the corresponding idev has a reference on it. After the rcu
grace period, dst_rcu_free() is called, and thus ___dst_free(), which will
set obsolete to DST_OBSOLETE_DEAD.
In this case, init_loopback() is called before dst_rcu_free(), thus
obsolete is still sets to something <= 0. So, the function doesn't add the
route again. To avoid that race, let's check the rt6 refcnt instead.
Fixes: 25fb6ca4ed9c ("net IPv6 : Fix broken IPv6 routing table after loopback down-up")
Fixes: a881ae1f625c ("ipv6: don't call addrconf_dst_alloc again when enable lo")
Fixes: 33d99113b110 ("ipv6: reallocate addrconf router for ipv6 address when lo device up")
Reported-by: Francesco Santoro <francesco.santoro@6wind.com>
Reported-by: Samuel Gauthier <samuel.gauthier@6wind.com>
CC: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com>
CC: Maruthi Thotad <Maruthi.Thotad@ap.sony.com>
CC: Sabrina Dubroca <sd@queasysnail.net>
CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
CC: Weilong Chen <chenweilong@huawei.com>
CC: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index d8983e15f859..9faafe58516a 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3018,7 +3018,7 @@ static void init_loopback(struct net_device *dev)
* lo device down, release this obsolete dst and
* reallocate a new router for ifa.
*/
- if (sp_ifa->rt->dst.obsolete > 0) {
+ if (!atomic_read(&sp_ifa->rt->rt6i_ref)) {
ip6_rt_put(sp_ifa->rt);
sp_ifa->rt = NULL;
} else {
--
2.8.1
^ permalink raw reply related
* Re: [PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-12 8:13 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Florian Fainelli, Tony Lindgren, netdev,
Sekhar Nori, linux-kernel, Russell King, linux-omap, David Miller,
linux-arm-kernel
In-Reply-To: <20161010131841.GA8391@rob-hp-laptop>
On Monday 10 October 2016 06:48 PM, Rob Herring wrote:
> On Thu, Oct 06, 2016 at 10:43:52AM +0530, Mugunthan V N wrote:
>> Add documention of ti,impedance-control which can be used to
>
> Needs updating.
Oops, will update this in next version.
>
>> correct MAC impedance mismatch using phy extended registers.
>>
>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> ---
>> Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> index 5d21141..85bf945 100644
>> --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> @@ -9,6 +9,18 @@ Required properties:
>> - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
>> for applicable values
>>
>> +Optional property:
>> + - ti,min-output-impedance - MAC Interface Impedance control to set
>> + the programmable output impedance to
>> + minimum value (35 ohms).
>> + - ti,max-output-impedance - MAC Interface Impedance control to set
>> + the programmable output impedance to
>> + maximum value (70 ohms).
>
> Define what are valid range of values for these.
The values are already mentioned in documentation as 35/70 ohms.
Are you mentioning about the register values?
Regards
Mugunthan V N
^ permalink raw reply
* Re: [patch] netfilter: nf_tables: underflow in nft_parse_u32_check()
From: Liping Zhang @ 2016-10-12 7:27 UTC (permalink / raw)
To: Dan Carpenter
Cc: Pablo Neira Ayuso, Laura Garcia Liebana, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller,
Netfilter Developer Mailing List, coreteam,
Linux Kernel Network Developers, kernel-janitors
In-Reply-To: <20161012060811.GE12841@mwanda>
2016-10-12 14:08 GMT+08:00 Dan Carpenter <dan.carpenter@oracle.com>:
> We don't want to allow negatives here.
>
> Fixes: 36b701fae12a ('netfilter: nf_tables: validate maximum value of u32 netlink attributes')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
> index b70d3ea..dd55187 100644
> --- a/net/netfilter/nf_tables_api.c
> +++ b/net/netfilter/nf_tables_api.c
> @@ -4423,7 +4423,7 @@ static int nf_tables_check_loops(const struct nft_ctx *ctx,
> */
I think it's better if you can convert it to follows:
> unsigned int nft_parse_u32_check(const struct nlattr *attr, int max, u32 *dest)
int nft_parse_u32_check(const struct nlattr *attr, u32 max, u32 *dest)
> {
> - int val;
> + uint val;
u32 val;
>
> val = ntohl(nla_get_be32(attr));
> if (val > max)
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Luca Coelho @ 2016-10-12 6:25 UTC (permalink / raw)
To: Chris Rorvick, Paul Bolle
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAEUsAPYDPCP0NBaTmy4xqFJhAS4xFQYinoNTknxFT23ef0dk4w@mail.gmail.com>
Hi Chris,
On Tue, 2016-10-11 at 09:09 -0500, Chris Rorvick wrote:
> On Tue, Oct 11, 2016 at 5:11 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> > > This is not coming from the NIC itself, but from the platform's ACPI
> > > tables. Can you tell us which platform you are using?
>
>
> Interesting. I'm running a Dell XPS 13 9350. I replaced the
> factory-provided Broadcom card with an AC 8260. I can update the
> commit log to reflect this.
Okay, so this makes sense. Those entries are probably formatted for
the Broadcom card, which the iwlwifi driver obviously doesn't
understand. The best we can do, as I already said, is to ignore values
we don't understand.
I will also check what is the correct procedure in such cases, because
it is possible, in theory, that the format *matches* but applies only
to another device.
> > > If this is really bothering you, I guess I could apply this patch for
> > > now. But as I said, this is not solving the actual problem.
> >
> >
> > Bikeshedding: I think IWL_INFO() is more appropriate, as info doesn't
> > imply one needs to act on this message, while warn does imply that
> > action is needed.
>
>
> Agreed. I still think making this a warning is appropriate, but it
> seems pretty clear this is not an error. This has nothing to do with
> how much it bothers me. An error tells the user something needs to be
> fixed, but in this case the interface is working fine. Making it a
> warning with an improved message will result in fewer people wasting
> their time.
Yes, so I'll try to stop wasting people's timing by trying to do the
correct thing without bothering the user at all. :)
Thanks for pointing this all out!
^ permalink raw reply
* Re: igb driver can cause cache invalidation of non-owned memory?
From: Nikita Yushchenko @ 2016-10-12 6:55 UTC (permalink / raw)
To: Alexander Duyck, Eric Dumazet
Cc: David Miller, Jeff Kirsher, intel-wired-lan, Netdev,
linux-kernel@vger.kernel.org, cphealy
In-Reply-To: <CAKgT0UcSkG1Nws1kcUp-QV0jnwdXcXrOZ2m0vsWRziETA-11sw@mail.gmail.com>
>>> The main reason why this isn't a concern for the igb driver is because
>>> we currently pass the page up as read-only. We don't allow the stack
>>> to write into the page by keeping the page count greater than 1 which
>>> means that the page is shared. It isn't until we unmap the page that
>>> the page count is allowed to drop to 1 indicating that it is writable.
>>
>> Doesn't that mean that sync_to_device() in igb_reuse_rx_page() can be
>> avoided? If page is read only for entire world, then it can't be dirty
>> in cache and thus device can safely write to it without preparation step.
>
> For the sake of correctness we were adding the
> dma_sync_single_range_for_device.
Could you please elaborate this "for sake of correctness"?
If by "correctness" you mean ensuring that buffer gets frame DMAed by
device and that's not broken by cache activity, then:
- on first use of this buffer after page allocation, sync_for_device()
is not needed due to previous dma_page_map() call,
- on later uses of the same buffer, sync_for_device() is not needed due
to buffer being read-only since dma_page_map() call, thus it can't be
dirty in cache and thus no writebacks of this area can be possible.
If by "correctness" you mean strict following "ownership" concept - i.e.
memory area is "owned" either by cpu or by device, and "ownersip" must
be passed to device before DMA and back to cpu after DMA - then, igb
driver already breaks these rules anyway:
- igb calls dma_map_page() at page allocation time, thus entire page
becomes "owned" by device,
- and then, on first use of second buffer inside the page, igb calls
sync_for_device() for buffer area, despite of that area is already
"owned" by device,
- and later, if a buffer within page gets reused, igb calls
sync_for_device() for entire buffer, despite of only part of buffer was
sync_for_cpu()'ed at time of completing receive of previous frame into
this buffer,
- and later, igb calls dma_unmap_page(), despite of that part of page
was sync_for_cpu()'ed and thus is "owned" by CPU.
Given all that, not calling sync_for_device() before reusing buffer
won't make picture much worse :)
> Since it is an DMA_FROM_DEVICE
> mapping calling it should really have no effect for most DMA mapping
> interfaces.
Unfortunately dma_sync_single_range_for_device() *is* slow on imx6q - it
does cache invalidation. I don't really understand why invalidating
cache can be slow - it only removes data from cache, it should not
access slow outer memory - but cache invalidation *is* in top of perf
profiles.
To get some throughput improvement, I propose removal of that
sync_for_device() before reusing buffer. Will you accept such a patch ;)
> Also you may want to try updating to the 4.8 version of the driver.
> It reduces the size of the dma_sync_single_range_for_cpu loops by
> reducing the sync size down to the size that was DMAed into the
> buffer.
Actually that patch came out of the work I'm currently participating in
;). Sure I have it.
> Specifically I believe
> the 0->100% accounting problem is due to the way this is all tracked.
Thanks for this hint - shame on me not realizing this earlier...
> You may want to try pulling the most recent net-next kernel and
> testing that to see if you still see the same behavior as Eric has
> recently added a fix that is meant to allow for better sharing between
> softirq polling and applications when dealing with stuff like UDP
> traffic.
>
> As far as identifying the problem areas your best bet would be to push
> the CPU to 100% and then identify the hot spots.
Thanks for hints
Nikita
^ permalink raw reply
* Re: [PATCH v6] net: ip, diag -- Add diag interface for raw sockets
From: Cyrill Gorcunov @ 2016-10-12 6:53 UTC (permalink / raw)
To: David Miller
Cc: netdev, eric.dumazet, jhs, dsa, linux-kernel, kuznet, jmorris,
yoshfuji, kaber, avagin, stephen
In-Reply-To: <20161012.015022.2273537782016406180.davem@davemloft.net>
On Wed, Oct 12, 2016 at 01:50:22AM -0400, David Miller wrote:
>
> Macros that look like function calls and are also lvalues tend to be
> troublesome.
>
> I know what you're trying to achieve, you want a named way to access
> this so that the intent and semantics are clear.
>
> But I'd rather you do something that provides a way by which normal
> struct member accesses do the job, and your earlier patches achieved
> this.
I can't rename the field, neither a can use union. The only acceptable
option I think is introduce inet_diag_v3 structure, which of course
will require the mode wide patching. If there no objections I could
try to implement it.
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Paul Bolle @ 2016-10-12 6:52 UTC (permalink / raw)
To: Luca Coelho, Chris Rorvick, Intel Linux Wireless,
Emmanuel Grumbach, Johannes Berg, Kalle Valo, Oren Givon
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1476252719.7776.6.camel@coelho.fi>
Luca,
On Wed, 2016-10-12 at 09:11 +0300, Luca Coelho wrote:
> By "platform" I meant the PC you are using. The ACPI table is created
> by the OEM, so different PCs have different tables.
Like Chris I use a Dell XPS 13 (9350), but mine came with an AC 8260
out of it's assembly plant:
Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> In any case, I will rework this code, so I'd prefer if we skip this
> patch entirely.
Feel free to prod me for testing whatever you come up with.
Paul Bolle
^ permalink raw reply
* [PATCH v3] Add support for ethtool operations and statistics to RDC-R6040.
From: VENKAT PRASHANTH B U @ 2016-10-12 6:36 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, fengguang.wu, VENKAT PRASHANTH B U
This is a patch to add support for ethtool operations and keeping
up to date statistics for RDC R6040 fast ethernet MAC driver.
Signed-off-by: Venkat Prashanth B U <venkat.prashanth2498@gmail.com>
---
changelog v3:
-Made the commit message more clear.
-Modified the locking interface used in r6040_get_regs().
-Verified the tabs vs space indentation.
-code cleanup on r6040_get_regs()
-Implemented a get_ethtool_stats callback that fills the shadow copy
of statistics obtained in the software.
changelog v2:
-Made the commit message more clear
-Add enumeration data type RTL_FLAG_MAX
-Modified the locking interface used in r6040_get_regs()
-Initialized mutex dynamically in a function r6040_get_regs()
-Declared u32 msg_enable in struct r6040_private.
---
---
drivers/net/ethernet/rdc/r6040.c | 229 +++++++++++++++++++++++++++++++++++++++
1 file changed, 229 insertions(+)
diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index cb29ee2..83478b1 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -44,6 +44,7 @@
#include <linux/irq.h>
#include <linux/uaccess.h>
#include <linux/phy.h>
+#include <linux/pm_runtime.h>
#include <asm/processor.h>
@@ -172,6 +173,62 @@ MODULE_VERSION(DRV_VERSION " " DRV_RELDATE);
#define TX_INTS (TX_FINISH)
#define INT_MASK (RX_INTS | TX_INTS)
+/* write/read MMIO register */
+#define R6040_W8(reg, val8) writeb ((val8), ioaddr + (reg))
+#define R6040_W16(reg, val16) writew ((val16), ioaddr + (reg))
+#define R6040_W32(reg, val32) writel ((val32), ioaddr + (reg))
+#define R6040_R8(reg) readb (ioaddr + (reg))
+#define R6040_R16(reg) readw (ioaddr + (reg))
+#define R6040_R32(reg) readl (ioaddr + (reg))
+
+enum r6040_flag
+{
+ RTL_FLAG_MAX
+};
+
+enum r6040_registers {
+ CounterAddrLow = 0x10,
+ CounterAddrHigh = 0x14,
+ ChipCmd = 0x37,
+};
+
+enum r6040_register_content {
+ /* ChipCmdBits */
+ StopReq = 0x80,
+ CmdReset = 0x10,
+ CmdRxEnb = 0x08,
+ CmdTxEnb = 0x04,
+ RxBufEmpty = 0x01,
+ /* ResetCounterCommand */
+ CounterReset = 0x1,
+
+ /* DumpCounterCommand */
+ CounterDump = 0x8,
+};
+
+struct r6040_counters {
+ __le64 tx_packets;
+ __le64 rx_packets;
+ __le64 tx_errors;
+ __le32 rx_errors;
+ __le16 rx_missed;
+ __le16 align_errors;
+ __le32 tx_one_collision;
+ __le32 tx_multi_collision;
+ __le64 rx_unicast;
+ __le64 rx_broadcast;
+ __le32 rx_multicast;
+ __le16 tx_aborted;
+ __le16 tx_underun;
+};
+
+struct r6040_tc_offsets {
+ bool inited;
+ __le64 tx_errors;
+ __le32 tx_multi_collision;
+ __le16 tx_aborted;
+};
+
struct r6040_descriptor {
u16 status, len; /* 0-3 */
__le32 buf; /* 4-7 */
@@ -192,10 +249,14 @@ struct r6040_private {
struct r6040_descriptor *tx_remove_ptr;
struct r6040_descriptor *rx_ring;
struct r6040_descriptor *tx_ring;
+ struct r6040_counters *counters;
+ struct r6040_tc_offsets tc_offset;
dma_addr_t rx_ring_dma;
dma_addr_t tx_ring_dma;
+ dma_addr_t counters_phys_addr;
u16 tx_free_desc;
u16 mcr0;
+ u32 msg_enable;
struct net_device *dev;
struct mii_bus *mii_bus;
struct napi_struct napi;
@@ -955,12 +1016,180 @@ static void netdev_get_drvinfo(struct net_device *dev,
strlcpy(info->bus_info, pci_name(rp->pdev), sizeof(info->bus_info));
}
+static int
+r6040_get_regs_len (struct net_device *dev)
+{
+ return R6040_IO_SIZE;
+}
+
+static void
+r6040_get_regs (struct net_device *dev, struct ethtool_regs *regs, void *p)
+{
+ struct r6040_private *tp = netdev_priv (dev);
+ u32 __iomem *data = tp->base;
+ u32 *dw = p;
+ int i;
+
+ spin_lock (&tp->lock);
+ for (i = 0; i < R6040_IO_SIZE; i += 4)
+ memcpy_fromio (dw++, data++, 4);
+ spin_unlock (&tp->lock);
+}
+
+static u32
+r6040_get_msglevel (struct net_device *dev)
+{
+ struct r6040_private *tp = netdev_priv (dev);
+
+ return tp->msg_enable;
+}
+
+static void
+r6040_set_msglevel (struct net_device *dev, u32 value)
+{
+ struct r6040_private *tp = netdev_priv (dev);
+
+ tp->msg_enable = value;
+}
+
+static const char r6040_gstrings[][ETH_GSTRING_LEN] = {
+ "tx_packets",
+ "rx_packets",
+ "tx_errors",
+ "rx_errors",
+ "rx_missed",
+ "align_errors",
+ "tx_single_collisions",
+ "tx_multi_collisions",
+ "unicast",
+ "broadcast",
+ "multicast",
+ "tx_aborted",
+ "tx_underrun",
+};
+
+static int
+r6040_get_sset_count (struct net_device *dev, int sset)
+{
+ switch (sset)
+ {
+ case ETH_SS_STATS:
+ return ARRAY_SIZE (r6040_gstrings);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static bool r6040_do_counters(struct net_device *dev, u32 counter_cmd)
+{
+ struct r6040_private *tp = netdev_priv(dev);
+ void __iomem *ioaddr = tp->base;
+ dma_addr_t paddr = tp->counters_phys_addr;
+ u32 cmd;
+
+ R6040_W32(CounterAddrHigh, (u64)paddr >> 32);
+ cmd = (u64)paddr & DMA_BIT_MASK(32);
+ R6040_W32(CounterAddrLow, cmd);
+ R6040_W32(CounterAddrLow, cmd | counter_cmd);
+
+
+ R6040_W32(CounterAddrLow, 0);
+ R6040_W32(CounterAddrHigh, 0);
+ return 0;
+}
+
+static bool r6040_reset_counters(struct net_device *dev)
+{
+ return r6040_do_counters(dev, CounterReset);
+}
+
+static bool r6040_update_counters(struct net_device *dev)
+{
+ struct r6040_private *tp = netdev_priv(dev);
+ void __iomem *ioaddr = tp->base;
+
+ if ((R6040_R8(ChipCmd) & CmdRxEnb) == 0)
+ return true;
+
+ return r6040_do_counters(dev, CounterDump);
+}
+
+static bool r6040_init_counter_offsets(struct net_device *dev)
+{
+ struct r6040_private *tp = netdev_priv(dev);
+ struct r6040_counters *counters = tp->counters;
+ bool ret = false;
+
+ if (tp->tc_offset.inited)
+ return true;
+
+ /* If both, reset and update fail, propagate to caller. */
+ if (r6040_reset_counters(dev))
+ ret = true;
+
+ if (r6040_update_counters(dev))
+ ret = true;
+
+ tp->tc_offset.tx_errors = counters->tx_errors;
+ tp->tc_offset.tx_multi_collision = counters->tx_multi_collision;
+ tp->tc_offset.tx_aborted = counters->tx_aborted;
+ tp->tc_offset.inited = true;
+
+ return ret;
+}
+
+static void r6040_get_ethtool_stats(struct net_device *dev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct r6040_private *tp = netdev_priv(dev);
+ struct device *d = &tp->pdev->dev;
+ struct r6040_counters *counters = tp->counters;
+
+ pm_runtime_get_noresume(d);
+
+ if (pm_runtime_active(d))
+ r6040_update_counters(dev);
+ pm_runtime_put_noidle(d);
+
+ data[0] = le64_to_cpu(counters->tx_packets);
+ data[1] = le64_to_cpu(counters->rx_packets);
+ data[2] = le64_to_cpu(counters->tx_errors);
+ data[3] = le32_to_cpu(counters->rx_errors);
+ data[4] = le16_to_cpu(counters->rx_missed);
+ data[5] = le16_to_cpu(counters->align_errors);
+ data[6] = le32_to_cpu(counters->tx_one_collision);
+ data[7] = le32_to_cpu(counters->tx_multi_collision);
+ data[8] = le64_to_cpu(counters->rx_unicast);
+ data[9] = le64_to_cpu(counters->rx_broadcast);
+ data[10] = le32_to_cpu(counters->rx_multicast);
+ data[11] = le16_to_cpu(counters->tx_aborted);
+ data[12] = le16_to_cpu(counters->tx_underun);
+}
+
+static void
+r6040_get_strings (struct net_device *dev, u32 stringset, u8 * data)
+{
+ switch (stringset)
+ {
+ case ETH_SS_STATS:
+ memcpy (data, *r6040_gstrings, sizeof (r6040_gstrings));
+ break;
+ }
+}
+
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo = netdev_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_ts_info = ethtool_op_get_ts_info,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = phy_ethtool_set_link_ksettings,
+ .get_regs_len = r6040_get_regs_len,
+ .get_msglevel = r6040_get_msglevel,
+ .set_msglevel = r6040_set_msglevel,
+ .get_regs = r6040_get_regs,
+ .get_strings = r6040_get_strings,
+ .get_sset_count = r6040_get_sset_count,
+ .get_ethtool_stats=r6040_get_ethtool_stats,
};
static const struct net_device_ops r6040_netdev_ops = {
--
1.9.2
^ permalink raw reply related
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Luca Coelho @ 2016-10-12 6:11 UTC (permalink / raw)
To: Paul Bolle, Chris Rorvick, Intel Linux Wireless,
Emmanuel Grumbach, Johannes Berg, Kalle Valo, Oren Givon
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1476180668.17022.21.camel@tiscali.nl>
Hi Paul,
On Tue, 2016-10-11 at 12:11 +0200, Paul Bolle wrote:
> On Mon, 2016-10-10 at 17:02 +0300, Luca Coelho wrote:
> > On Mon, 2016-10-10 at 02:19 -0500, Chris Rorvick wrote:
> > This is not coming from the NIC itself, but from the platform's ACPI
> > tables. Can you tell us which platform you are using?
>
>
> On my machine I'm seeing the same error as Chris. So what exactly do
> you mean with "platform" here?
By "platform" I meant the PC you are using. The ACPI table is created
by the OEM, so different PCs have different tables.
>
> > > Name (SPLX, Package (0x04)
> > > {
> > > Zero,
> > > Package (0x03)
> > > {
> > > 0,
> > > 1200,
> > > 1000
> > > },
> > > Package (0x03)
> > > {
> > > 0,
> > > 1200,
> > > 1000
> > > },
> > > Package (0x03)
> > > {
> > > 0,
> > > 1200,
> > > 1000
> > > }
> > > })
> >
> >
> > This is not the structure that we are expecting. We expect this:
> >
> > Name (SPLX, Package (0x02)
> > {
> > Zero,
> > Package (0x03)
> > {
> > 0x07,
> > <value>,
> > <value>
> > }
> > })
> >
> > ...as you correctly pointed out. The data in the structure you have is
> > not for WiFi (actually I don't think 0 is a valid value, but I'll
> > double-check).
>
>
> For what it's worth, on my machine I have twenty (!) SPLX entries, all
> reading:
> Name (SPLX, Package (0x04)
> {
> Zero,
> Package (0x03)
> {
> 0x80000000,
> 0x80000000,
> 0x80000000
> },
>
> Package (0x03)
> {
> 0x80000000,
> 0x80000000,
> 0x80000000
> },
>
> Package (0x03)
> {
> 0x80000000,
> 0x80000000,
> 0x80000000
> }
> })
Thanks. So this is another case where the first value doesn't match
what we are expecting and we should just ignore that.
> > There are other things that look a bit inconsistent in this code...
> > I'll try to find the official ACPI table definitions for this entries
> > to make sure it's correct.
>
>
> When I looked into this error, some time ago, I searched around a bit
> for documentation on this splx stuff. Sadly, commit bcb079a14d75
> ("iwlwifi: pcie: retrieve and parse ACPI power limitations") provides
> very few clues and my searches turned up nothing useful. So a pointer
> or two would be really appreciated.
Yeah, I looked into that commit too and there's not much there. I'll
try to find the documentation and, if I can, I'll share it with you.
> > > --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
> > > +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
> > > @@ -540,7 +540,7 @@ static u64 splx_get_pwr_limit(struct iwl_trans *trans, union acpi_object *splx)
> > > splx->package.count != 2 ||
> > > splx->package.elements[0].type != ACPI_TYPE_INTEGER ||
> > > splx->package.elements[0].integer.value != 0) {
> > > - IWL_ERR(trans, "Unsupported splx structure\n");
> > > + IWL_WARN(trans, "Unsupported splx structure, not limiting WiFi power\n");
> > > return 0;
> > > }
> >
> >
> > If this is really bothering you, I guess I could apply this patch for
> > now. But as I said, this is not solving the actual problem.
>
>
> Bikeshedding: I think IWL_INFO() is more appropriate, as info doesn't
> imply one needs to act on this message, while warn does imply that
> action is needed.
Right, but in fact, the code considers that if the SPLX method exists,
it must return a value iwlwifi can understand, thus the error. That
assumption is wrong, so we should just ignore entries that don't match
and continue without printing anything out (as would happen if the splx
method were not even there).
In any case, I will rework this code, so I'd prefer if we skip this
patch entirely.
^ permalink raw reply
* [patch] netfilter: nft_exthdr: fix error handling in nft_exthdr_init()
From: Dan Carpenter @ 2016-10-12 6:09 UTC (permalink / raw)
To: Pablo Neira Ayuso, Laura Garcia Liebana
Cc: Patrick McHardy, Jozsef Kadlecsik, David S. Miller,
netfilter-devel, coreteam, netdev, kernel-janitors
"err" needs to be signed for the error handling to work.
Fixes: 36b701fae12a ('netfilter: nf_tables: validate maximum value of u32 netlink attributes')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/netfilter/nft_exthdr.c b/net/netfilter/nft_exthdr.c
index a84cf3d..47beb3a 100644
--- a/net/netfilter/nft_exthdr.c
+++ b/net/netfilter/nft_exthdr.c
@@ -59,7 +59,8 @@ static int nft_exthdr_init(const struct nft_ctx *ctx,
const struct nlattr * const tb[])
{
struct nft_exthdr *priv = nft_expr_priv(expr);
- u32 offset, len, err;
+ u32 offset, len;
+ int err;
if (tb[NFTA_EXTHDR_DREG] == NULL ||
tb[NFTA_EXTHDR_TYPE] == NULL ||
^ permalink raw reply related
* [patch] netfilter: nf_tables: underflow in nft_parse_u32_check()
From: Dan Carpenter @ 2016-10-12 6:08 UTC (permalink / raw)
To: Pablo Neira Ayuso, Laura Garcia Liebana
Cc: Patrick McHardy, Jozsef Kadlecsik, David S. Miller,
netfilter-devel, coreteam, netdev, kernel-janitors
We don't want to allow negatives here.
Fixes: 36b701fae12a ('netfilter: nf_tables: validate maximum value of u32 netlink attributes')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index b70d3ea..dd55187 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -4423,7 +4423,7 @@ static int nf_tables_check_loops(const struct nft_ctx *ctx,
*/
unsigned int nft_parse_u32_check(const struct nlattr *attr, int max, u32 *dest)
{
- int val;
+ uint val;
val = ntohl(nla_get_be32(attr));
if (val > max)
^ permalink raw reply related
* Re: HSO driver patch again [2/2]
From: David Miller @ 2016-10-12 5:58 UTC (permalink / raw)
To: matej.kupljen; +Cc: gregkh, linux-usb, netdev
In-Reply-To: <CAHMF36GL_6RZyhtUikM8EpS5rWp4Q+=P8g8i6huijG5vtnnwAQ@mail.gmail.com>
"HSO driver patch again ..." is not an appropriate Subject line when
submitting patches.
Please read Documentation/SubmittingPatches for how to do things
properly, and in a way that will actually lead to your patches
being applied.
Thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] s390: af_iucv patches
From: David Miller @ 2016-10-12 5:56 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens
In-Reply-To: <cover.1475846599.git.ursula.braun@de.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Fri, 7 Oct 2016 15:51:46 +0200
> here are 2 patches for the s390-only af_iucv socket family code.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] strparser: Propagate correct error code in strp_recv()
From: David Miller @ 2016-10-12 5:52 UTC (permalink / raw)
To: geert; +Cc: tom, netdev, linux-kernel
In-Reply-To: <1475761309-13481-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Thu, 6 Oct 2016 15:41:49 +0200
> With m68k-linux-gnu-gcc-4.1:
>
> net/strparser/strparser.c: In function ‘strp_recv’:
> net/strparser/strparser.c:98: warning: ‘err’ may be used uninitialized in this function
>
> Pass "len" (which is an error code when negative) instead of the
> uninitialized "err" variable to fix this.
>
> Fixes: 43a0c6751a322847 ("strparser: Stream parser for messages")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] drivers: net: xgene: fix: Use GPIO to get link status
From: David Miller @ 2016-10-12 5:54 UTC (permalink / raw)
To: isubramanian; +Cc: netdev, patches, arnd, linux-arm-kernel, qnguyen
In-Reply-To: <1475789758-5196-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Thu, 6 Oct 2016 14:35:56 -0700
> Since the link value reported by the link status register is not
> reliable if no SPF module inserted, this patchset fixes the issue by
> using GPIO to determine the link status when no module inserted.
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
> Signed-off-by: Quan Nguyen <qnguyen@apm.com>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v6] net: ip, diag -- Add diag interface for raw sockets
From: David Miller @ 2016-10-12 5:50 UTC (permalink / raw)
To: gorcunov
Cc: netdev, eric.dumazet, jhs, dsa, linux-kernel, kuznet, jmorris,
yoshfuji, kaber, avagin, stephen
In-Reply-To: <20161006100055.GA1941@uranus.lan>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Thu, 6 Oct 2016 13:00:55 +0300
> v6:
> - use sdiag_raw_protocol() helper which will access @pad
> structure used for raw sockets protocol specification:
> we can't simply rename this member without breaking uapi.
Macros that look like function calls and are also lvalues tend to be
troublesome.
I know what you're trying to achieve, you want a named way to access
this so that the intent and semantics are clear.
But I'd rather you do something that provides a way by which normal
struct member accesses do the job, and your earlier patches achieved
this.
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: correctly fragment packet with mpls headers
From: David Miller @ 2016-10-12 5:45 UTC (permalink / raw)
To: jbenc; +Cc: netdev, dsa, pshelar
In-Reply-To: <502ca56422930442a91db61f975f829c62b27c7f.1475672359.git.jbenc@redhat.com>
From: Jiri Benc <jbenc@redhat.com>
Date: Wed, 5 Oct 2016 15:01:57 +0200
> If mpls headers were pushed to a defragmented packet, the refragmentation no
> longer works correctly after 48d2ab609b6b ("net: mpls: Fixups for GSO"). The
> network header has to be shifted after the mpls headers for the
> fragmentation and restored afterwards.
>
> Fixes: 48d2ab609b6b ("net: mpls: Fixups for GSO")
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: dsa: slave: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-10-12 5:41 UTC (permalink / raw)
To: tremyfr; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <1476025253-5571-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 9 Oct 2016 17:00:53 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: usb: lan78xx: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-10-12 5:41 UTC (permalink / raw)
To: tremyfr; +Cc: woojung.huh, UNGLinuxDriver, netdev, linux-usb, linux-kernel
In-Reply-To: <1476007624-9676-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 9 Oct 2016 12:07:04 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ti: netcp_ethss: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-10-12 5:41 UTC (permalink / raw)
To: tremyfr; +Cc: w-kwok2, m-karicheri2, netdev, linux-kernel
In-Reply-To: <1475948895-27614-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sat, 8 Oct 2016 19:48:15 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ti: cpsw: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-10-12 5:41 UTC (permalink / raw)
To: tremyfr; +Cc: mugunthanvnm, grygorii.strashko, linux-omap, netdev, linux-kernel
In-Reply-To: <1475941575-26590-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sat, 8 Oct 2016 17:46:15 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] net: stmmac: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-10-12 5:41 UTC (permalink / raw)
To: tremyfr; +Cc: peppe.cavallaro, alexandre.torgue, netdev, linux-kernel
In-Reply-To: <1475476100-28219-2-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Mon, 3 Oct 2016 08:28:20 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/2] net: stmmac: use phydev from struct net_device
From: David Miller @ 2016-10-12 5:41 UTC (permalink / raw)
To: tremyfr; +Cc: peppe.cavallaro, alexandre.torgue, netdev, linux-kernel
In-Reply-To: <1475476100-28219-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Mon, 3 Oct 2016 08:28:19 +0200
> The private structure contain a pointer to phydev, but the structure
> net_device already contain such pointer. So we can remove the pointer
> phydev in the private structure, and update the driver to use the
> one contained in struct net_device.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: mv643xx_eth: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-10-12 5:41 UTC (permalink / raw)
To: tremyfr; +Cc: sebastian.hesselbarth, netdev, linux-kernel
In-Reply-To: <1475402809-11593-2-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 2 Oct 2016 12:06:49 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: mv643xx_eth: use phydev from struct net_device
From: David Miller @ 2016-10-12 5:40 UTC (permalink / raw)
To: tremyfr; +Cc: sebastian.hesselbarth, netdev, linux-kernel
In-Reply-To: <1475402809-11593-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 2 Oct 2016 12:06:48 +0200
> The private structure contain a pointer to phydev, but the structure
> net_device already contain such pointer. So we can remove the pointer
> phydev in the private structure, and update the driver to use the
> one contained in struct net_device.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ 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