* [PATCH net] qmi_wwan: Support dynamic config on Quectel EP06
From: Kristian Evensen @ 2018-09-08 11:50 UTC (permalink / raw)
To: netdev, bjorn; +Cc: Kristian Evensen
Quectel EP06 (and EM06/EG06) supports dynamic configuration of USB
interfaces, without the device changing VID/PID or configuration number.
When the configuration is updated and interfaces are added/removed, the
interface numbers change. This means that the current code for matching
EP06 does not work.
This patch removes the current EP06 interface number match, and replaces
it with a match on class, subclass and protocol. Unfortunately, matching
on those three alone is not enough, as the diag interface exports the
same values as QMI. The other serial interfaces + adb export different
values and do not match.
The diag interface only has two endpoints, while the QMI interface has
three. I have therefore added a check for number of interfaces, and we
ignore the interface if the number of endpoints equals two.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
---
drivers/net/usb/qmi_wwan.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 31684f338..e4bb6083f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -967,6 +967,13 @@ static const struct usb_device_id products[] = {
USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0x581d, USB_CLASS_VENDOR_SPEC, 1, 7),
.driver_info = (unsigned long)&qmi_wwan_info,
},
+ { /* Quectel EP06/EG06/EM06 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x2c7c, 0x0306,
+ USB_CLASS_VENDOR_SPEC,
+ USB_SUBCLASS_VENDOR_SPEC,
+ 0xff),
+ .driver_info = (unsigned long)&qmi_wwan_info_quirk_dtr,
+ },
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x0408, 0xea42, 4)}, /* Yota / Megafon M100-1 */
@@ -1254,7 +1261,6 @@ static const struct usb_device_id products[] = {
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0191, 4)}, /* Quectel EG91 */
{QMI_FIXED_INTF(0x2c7c, 0x0296, 4)}, /* Quectel BG96 */
- {QMI_QUIRK_SET_DTR(0x2c7c, 0x0306, 4)}, /* Quectel EP06 Mini PCIe */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
@@ -1330,6 +1336,19 @@ static bool quectel_ec20_detected(struct usb_interface *intf)
return false;
}
+static bool quectel_ep06_diag_detected(struct usb_interface *intf)
+{
+ struct usb_device *dev = interface_to_usbdev(intf);
+ struct usb_interface_descriptor intf_desc = intf->cur_altsetting->desc;
+
+ if (le16_to_cpu(dev->descriptor.idVendor) == 0x2c7c &&
+ le16_to_cpu(dev->descriptor.idProduct) == 0x0306 &&
+ intf_desc.bNumEndpoints == 2)
+ return true;
+
+ return false;
+}
+
static int qmi_wwan_probe(struct usb_interface *intf,
const struct usb_device_id *prod)
{
@@ -1364,6 +1383,15 @@ static int qmi_wwan_probe(struct usb_interface *intf,
return -ENODEV;
}
+ /* Quectel EP06/EM06/EG06 supports dynamic interface configuration, so
+ * we need to match on class/subclass/protocol. These values are
+ * identical for the diagnostic- and QMI-interface, but bNumEndpoints is
+ * different. Ignore the current interface if the number of endpoints
+ * the number for the diag interface (two).
+ */
+ if (quectel_ep06_diag_detected(intf))
+ return -ENODEV;
+
return usbnet_probe(intf, id);
}
--
2.14.1
^ permalink raw reply related
* [PATCH] cfg80211: remove unnecessary null pointer check in cfg80211_netdev_notifier_call
From: zhong jiang @ 2018-09-08 11:21 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, netdev, linux-kernel
The iterator in list_for_each_entry_safe is never null, therefore, remove
the redundant null pointer check.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/wireless/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index a88551f..4d5215e 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1238,7 +1238,7 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
list_for_each_entry_safe(pos, tmp,
&rdev->sched_scan_req_list, list) {
- if (WARN_ON(pos && pos->dev == wdev->netdev))
+ if (WARN_ON(pos->dev == wdev->netdev))
cfg80211_stop_sched_scan_req(rdev, pos, false);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2] ethernet: hnae: drop adhoc assert() macros
From: Igor Stoppa @ 2018-09-08 15:01 UTC (permalink / raw)
To: David S . Miller
Cc: igor.stoppa, Igor Stoppa, huangdaode, Yisen Zhuang, Salil Mehta,
netdev, linux-kernel
Replace assert() with a less misleading test_condition() using WARN()
Drop one check which had bitrotted and didn't compile anymore.
Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com>
Cc: huangdaode <huangdaode@hisilicon.com>
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Cc: Salil Mehta <salil.mehta@huawei.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/hisilicon/hns/hnae.c | 7 ++--
drivers/net/ethernet/hisilicon/hns/hnae.h | 34 +++++--------------
.../net/ethernet/hisilicon/hns/hns_ae_adapt.c | 16 ++++-----
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 12 +++----
4 files changed, 25 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c b/drivers/net/ethernet/hisilicon/hns/hnae.c
index a051e582d541..bd64e6092e4b 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.c
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
@@ -203,11 +203,12 @@ hnae_init_ring(struct hnae_queue *q, struct hnae_ring *ring, int flags)
ring->flags = flags;
spin_lock_init(&ring->lock);
ring->coal_param = q->handle->coal_param;
- assert(!ring->desc && !ring->desc_cb && !ring->desc_dma_addr);
+ test_condition(!ring->desc && !ring->desc_cb &&
+ !ring->desc_dma_addr);
/* not matter for tx or rx ring, the ntc and ntc start from 0 */
- assert(ring->next_to_use == 0);
- assert(ring->next_to_clean == 0);
+ test_condition(ring->next_to_use == 0);
+ test_condition(ring->next_to_clean == 0);
ring->desc_cb = kcalloc(ring->desc_num, sizeof(ring->desc_cb[0]),
GFP_KERNEL);
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h b/drivers/net/ethernet/hisilicon/hns/hnae.h
index 08a750fb60c4..47dec7590079 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -43,23 +43,9 @@
#define HNAE_DEFAULT_DEVICE_DESCR "Hisilicon Network Subsystem"
#ifdef DEBUG
-
-#ifndef assert
-#define assert(expr) \
-do { \
- if (!(expr)) { \
- pr_err("Assertion failed! %s, %s, %s, line %d\n", \
- #expr, __FILE__, __func__, __LINE__); \
- } \
-} while (0)
-#endif
-
+#define test_condition(expr) WARN_ON_ONCE(!(expr))
#else
-
-#ifndef assert
-#define assert(expr)
-#endif
-
+#define test_condition(expr)
#endif
#define AE_VERSION_1 ('6' << 16 | '6' << 8 | '0')
@@ -314,16 +300,16 @@ enum hns_desc_type {
DESC_TYPE_PAGE,
};
-#define assert_is_ring_idx(ring, idx) \
- assert((idx) >= 0 && (idx) < (ring)->desc_num)
+#define is_ring_idx(ring, idx) \
+ test_condition((idx) >= 0 && (idx) < (ring)->desc_num)
/* the distance between [begin, end) in a ring buffer
* note: there is a unuse slot between the begin and the end
*/
static inline int ring_dist(struct hnae_ring *ring, int begin, int end)
{
- assert_is_ring_idx(ring, begin);
- assert_is_ring_idx(ring, end);
+ is_ring_idx(ring, begin);
+ is_ring_idx(ring, end);
return (end - begin + ring->desc_num) % ring->desc_num;
}
@@ -336,8 +322,8 @@ static inline int ring_space(struct hnae_ring *ring)
static inline int is_ring_empty(struct hnae_ring *ring)
{
- assert_is_ring_idx(ring, ring->next_to_use);
- assert_is_ring_idx(ring, ring->next_to_clean);
+ is_ring_idx(ring, ring->next_to_use);
+ is_ring_idx(ring, ring->next_to_clean);
return ring->next_to_use == ring->next_to_clean;
}
@@ -592,10 +578,6 @@ int hnae_reinit_handle(struct hnae_handle *handle);
#define hnae_queue_xmit(q, buf_num) writel_relaxed(buf_num, \
(q)->tx_ring.io_base + RCB_REG_TAIL)
-#ifndef assert
-#define assert(cond)
-#endif
-
static inline int hnae_reserve_buffer_map(struct hnae_ring *ring,
struct hnae_desc_cb *cb)
{
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index b52029e26d15..6ff391ccdd7a 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -264,7 +264,7 @@ static int hns_ae_set_multicast_one(struct hnae_handle *handle, void *addr)
struct hns_mac_cb *mac_cb = hns_get_mac_cb(handle);
u8 port_num;
- assert(mac_cb);
+ test_condition(mac_cb);
if (mac_cb->mac_type != HNAE_PORT_SERVICE)
return 0;
@@ -494,7 +494,7 @@ static void hns_ae_get_pauseparam(struct hnae_handle *handle,
static int hns_ae_set_autoneg(struct hnae_handle *handle, u8 enable)
{
- assert(handle);
+ test_condition(handle);
return hns_mac_set_autoneg(hns_get_mac_cb(handle), enable);
}
@@ -511,7 +511,7 @@ static int hns_ae_get_autoneg(struct hnae_handle *handle)
{
u32 auto_neg;
- assert(handle);
+ test_condition(handle);
hns_mac_get_autoneg(hns_get_mac_cb(handle), &auto_neg);
@@ -618,7 +618,7 @@ static void hns_ae_get_coalesce_range(struct hnae_handle *handle,
{
struct dsaf_device *dsaf_dev;
- assert(handle);
+ test_condition(handle);
dsaf_dev = hns_ae_get_dsaf_dev(handle->dev);
@@ -767,7 +767,7 @@ static void hns_ae_get_strings(struct hnae_handle *handle,
u8 *p = data;
struct hnae_vf_cb *vf_cb;
- assert(handle);
+ test_condition(handle);
vf_cb = hns_ae_get_vf_cb(handle);
port = vf_cb->port_index;
@@ -795,7 +795,7 @@ static int hns_ae_get_sset_count(struct hnae_handle *handle, int stringset)
struct hns_mac_cb *mac_cb;
struct dsaf_device *dsaf_dev = hns_ae_get_dsaf_dev(handle->dev);
- assert(handle);
+ test_condition(handle);
mac_cb = hns_get_mac_cb(handle);
@@ -839,7 +839,7 @@ static void hns_ae_update_led_status(struct hnae_handle *handle)
{
struct hns_mac_cb *mac_cb;
- assert(handle);
+ test_condition(handle);
mac_cb = hns_get_mac_cb(handle);
if (mac_cb->media_type != HNAE_MEDIA_TYPE_FIBER)
return;
@@ -852,7 +852,7 @@ static int hns_ae_cpld_set_led_id(struct hnae_handle *handle,
{
struct hns_mac_cb *mac_cb;
- assert(handle);
+ test_condition(handle);
mac_cb = hns_get_mac_cb(handle);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index f56855e63c96..8ba0d44742d1 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -366,7 +366,7 @@ netdev_tx_t hns_nic_net_xmit_hw(struct net_device *ndev,
ndev->stats.tx_packets++;
wmb(); /* commit all data before submit */
- assert(skb->queue_mapping < priv->ae_handle->q_num);
+ test_condition(skb->queue_mapping < priv->ae_handle->q_num);
hnae_queue_xmit(priv->ae_handle->qs[skb->queue_mapping], buf_num);
ring->stats.tx_pkts++;
ring->stats.tx_bytes += skb->len;
@@ -937,9 +937,9 @@ static int is_valid_clean_head(struct hnae_ring *ring, int h)
if (unlikely(h > ring->desc_num))
return 0;
- assert(u > 0 && u < ring->desc_num);
- assert(c > 0 && c < ring->desc_num);
- assert(u != c && h != c); /* must be checked before call this func */
+ test_condition(u > 0 && u < ring->desc_num);
+ test_condition(c > 0 && c < ring->desc_num);
+ test_condition(u != c && h != c); /* must be checked before call this func */
return u > c ? (h > c && h <= u) : (h > c || h <= u);
}
@@ -1515,8 +1515,6 @@ static netdev_tx_t hns_nic_net_xmit(struct sk_buff *skb,
{
struct hns_nic_priv *priv = netdev_priv(ndev);
- assert(skb->queue_mapping < ndev->ae_handle->q_num);
-
return hns_nic_net_xmit_hw(ndev, skb,
&tx_ring_data(priv, skb->queue_mapping));
}
@@ -2249,7 +2247,7 @@ static int hns_nic_notifier_action(struct notifier_block *nb,
struct hns_nic_priv *priv =
container_of(nb, struct hns_nic_priv, notifier_block);
- assert(action == HNAE_AE_REGISTER);
+ test_condition(action == HNAE_AE_REGISTER);
if (!hns_nic_try_get_ae(priv->netdev)) {
hnae_unregister_notifier(&priv->notifier_block);
--
2.17.1
^ permalink raw reply related
* [PATCH net] powerpc: use big endian to hash len and proto in csum_ipv6_magic
From: Xin Long @ 2018-09-08 10:15 UTC (permalink / raw)
To: network dev, linuxppc-dev
Cc: Christophe Leroy, Michael Ellerman, Roopa Prabhu
The function csum_ipv6_magic doesn't convert len and proto to big
endian before doing ipv6 csum hash, which is not consistent with
RFC and other arches.
Jianlin found it when ICMPv6 packets from other hosts were dropped
in the powerpc64 system.
This patch is to fix it by using instruction 'lwbrx' to do this
conversion in powerpc32/64 csum_ipv6_magic.
Fixes: e9c4943a107b ("powerpc: Implement csum_ipv6_magic in assembly")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
arch/powerpc/lib/checksum_32.S | 4 ++++
arch/powerpc/lib/checksum_64.S | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S
index aa22406..7d3446e 100644
--- a/arch/powerpc/lib/checksum_32.S
+++ b/arch/powerpc/lib/checksum_32.S
@@ -325,6 +325,10 @@ _GLOBAL(csum_ipv6_magic)
adde r0, r0, r9
lwz r11, 12(r4)
adde r0, r0, r10
+ STWX_BE r5, 0, r1
+ lwz r5, 0(r1)
+ STWX_BE r6, 0, r1
+ lwz r6, 0(r1)
add r5, r5, r6 /* assumption: len + proto doesn't carry */
adde r0, r0, r11
adde r0, r0, r5
diff --git a/arch/powerpc/lib/checksum_64.S b/arch/powerpc/lib/checksum_64.S
index 886ed94..302e732 100644
--- a/arch/powerpc/lib/checksum_64.S
+++ b/arch/powerpc/lib/checksum_64.S
@@ -439,6 +439,10 @@ EXPORT_SYMBOL(csum_partial_copy_generic)
_GLOBAL(csum_ipv6_magic)
ld r8, 0(r3)
ld r9, 8(r3)
+ STWX_BE r5, 0, r1
+ lwz r5, 0(r1)
+ STWX_BE r6, 0, r1
+ lwz r6, 0(r1)
add r5, r5, r6
addc r0, r8, r9
ld r10, 0(r4)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] ethernet: hnae: add unlikely() to assert()
From: Igor Stoppa @ 2018-09-08 15:00 UTC (permalink / raw)
To: David Miller
Cc: huangdaode, igor.stoppa, yisen.zhuang, salil.mehta, netdev,
linux-kernel
In-Reply-To: <20180907.144659.284526279757617907.davem@davemloft.net>
On 08/09/18 00:46, David Miller wrote:
> From: Igor Stoppa <igor.stoppa@gmail.com>
> Date: Fri, 7 Sep 2018 20:26:50 +0300
>
>> The assert() condition is likely to be true.
>
> Worse than that is that drivers should not be definiting their own
> private "assert()" macro.
>
> I'd rather have that fixed instead. We have tons of standard kernel
> facilities that do what they are trying to do here, without overloading
> the standard C namespace in this way.
I've converted into WARN() what passed the compile test.
In one case it didn't even compile :-(
I could only compile-test.
--
igor
^ permalink raw reply
* [PATCH 04/11] compat_ioctl: remove isdn ioctl translation
From: Arnd Bergmann @ 2018-09-08 14:28 UTC (permalink / raw)
To: viro
Cc: Arnd Bergmann, Karsten Keil, Paul Bolle, netdev, linux-kernel,
gigaset307x-common, linux-fsdevel
In-Reply-To: <20180908142837.2819693-1-arnd@arndb.de>
Neither the old isdn4linux interface nor the newer mISDN stack
ever had working 32-bit compat mode as far as I can tell.
However, the CAPI stack and the Gigaset ISDN driver (implemented
on top of either CAPI or i4l) have some ioctl commands that are
correctly listed in fs/compat_ioctl.c.
We can trivially move all of those into the two corresponding
files that implement the native handlers by adding a compat_ioctl
redirect to that.
I did notice that treating CAPI_MANUFACTURER_CMD() as compatible
is broken, so I'm also adding a handler for that, realizing that
in all likelyhood, nobody is ever going to call it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/isdn/capi/capi.c | 31 +++++++++++++++++++++++++++++++
drivers/isdn/gigaset/interface.c | 10 ++++++++++
fs/compat_ioctl.c | 22 ----------------------
3 files changed, 41 insertions(+), 22 deletions(-)
diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
index ef5560b848ab..4851dc3941eb 100644
--- a/drivers/isdn/capi/capi.c
+++ b/drivers/isdn/capi/capi.c
@@ -942,6 +942,34 @@ capi_unlocked_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
return ret;
}
+#ifdef CONFIG_COMPAT
+static long
+capi_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+ int ret;
+
+ if (cmd == CAPI_MANUFACTURER_CMD) {
+ struct {
+ unsigned long cmd;
+ compat_uptr_t data;
+ } mcmd32;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ if (copy_from_user(&mcmd32, compat_ptr(arg), sizeof(mcmd32)))
+ return -EFAULT;
+
+ mutex_lock(&capi_mutex);
+ ret = capi20_manufacturer(mcmd32.cmd, compat_ptr(mcmd32.data));
+ mutex_unlock(&capi_mutex);
+
+ return ret;
+ }
+
+ return capi_unlocked_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
+}
+#endif
+
static int capi_open(struct inode *inode, struct file *file)
{
struct capidev *cdev;
@@ -988,6 +1016,9 @@ static const struct file_operations capi_fops =
.write = capi_write,
.poll = capi_poll,
.unlocked_ioctl = capi_unlocked_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = capi_compat_ioctl,
+#endif
.open = capi_open,
.release = capi_release,
};
diff --git a/drivers/isdn/gigaset/interface.c b/drivers/isdn/gigaset/interface.c
index 600c79b030cd..faae8ae54802 100644
--- a/drivers/isdn/gigaset/interface.c
+++ b/drivers/isdn/gigaset/interface.c
@@ -233,6 +233,13 @@ static int if_ioctl(struct tty_struct *tty,
return retval;
}
+#ifdef CONFIG_COMPAT
+static long if_compat_ioctl(struct tty_struct *tty, unsigned int cmd, unsigned long arg)
+{
+ return if_ioctl(tty, cmd, (unsigned long)compat_ptr(arg));
+}
+#endif
+
static int if_tiocmget(struct tty_struct *tty)
{
struct cardstate *cs = tty->driver_data;
@@ -472,6 +479,9 @@ static const struct tty_operations if_ops = {
.open = if_open,
.close = if_close,
.ioctl = if_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = if_compat_ioctl,
+#endif
.write = if_write,
.write_room = if_write_room,
.chars_in_buffer = if_chars_in_buffer,
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 875516658c39..7d8c5722fd0a 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -61,9 +61,6 @@
#include <net/bluetooth/hci_sock.h>
#include <net/bluetooth/rfcomm.h>
-#include <linux/capi.h>
-#include <linux/gigaset_dev.h>
-
#ifdef CONFIG_BLOCK
#include <linux/cdrom.h>
#include <linux/fd.h>
@@ -670,25 +667,6 @@ COMPATIBLE_IOCTL(HIDPCONNADD)
COMPATIBLE_IOCTL(HIDPCONNDEL)
COMPATIBLE_IOCTL(HIDPGETCONNLIST)
COMPATIBLE_IOCTL(HIDPGETCONNINFO)
-/* CAPI */
-COMPATIBLE_IOCTL(CAPI_REGISTER)
-COMPATIBLE_IOCTL(CAPI_GET_MANUFACTURER)
-COMPATIBLE_IOCTL(CAPI_GET_VERSION)
-COMPATIBLE_IOCTL(CAPI_GET_SERIAL)
-COMPATIBLE_IOCTL(CAPI_GET_PROFILE)
-COMPATIBLE_IOCTL(CAPI_MANUFACTURER_CMD)
-COMPATIBLE_IOCTL(CAPI_GET_ERRCODE)
-COMPATIBLE_IOCTL(CAPI_INSTALLED)
-COMPATIBLE_IOCTL(CAPI_GET_FLAGS)
-COMPATIBLE_IOCTL(CAPI_SET_FLAGS)
-COMPATIBLE_IOCTL(CAPI_CLR_FLAGS)
-COMPATIBLE_IOCTL(CAPI_NCCI_OPENCOUNT)
-COMPATIBLE_IOCTL(CAPI_NCCI_GETUNIT)
-/* Siemens Gigaset */
-COMPATIBLE_IOCTL(GIGASET_REDIR)
-COMPATIBLE_IOCTL(GIGASET_CONFIG)
-COMPATIBLE_IOCTL(GIGASET_BRKCHARS)
-COMPATIBLE_IOCTL(GIGASET_VERSION)
/* Misc. */
COMPATIBLE_IOCTL(0x41545900) /* ATYIO_CLKR */
COMPATIBLE_IOCTL(0x41545901) /* ATYIO_CLKW */
--
2.18.0
^ permalink raw reply related
* [PATCH] wireless: remove unnecessary condition check before kfree
From: zhong jiang @ 2018-09-08 14:12 UTC (permalink / raw)
To: davem, johannes; +Cc: linux-wireless, netdev, linux-kernel
kfree has taken the null pointer into account. Just remove the
redundant condition check before kfree.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/wireless/reg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5ad5b9f..dc87e3d 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1086,7 +1086,7 @@ int reg_reload_regdb(void)
}
rtnl_lock();
- if (!IS_ERR_OR_NULL(regdb))
+ if (!IS_ERR(regdb))
kfree(regdb);
regdb = db;
rtnl_unlock();
@@ -3920,7 +3920,7 @@ void regulatory_exit(void)
kfree(reg_request);
}
- if (!IS_ERR_OR_NULL(regdb))
+ if (!IS_ERR(regdb))
kfree(regdb);
free_regdb_keyring();
--
1.7.12.4
^ permalink raw reply related
* [PATCH net] ipv6: use rt6_info members when dst is set in rt6_fill_node
From: Xin Long @ 2018-09-08 9:24 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, Roopa Prabhu
In inet6_rtm_getroute, since Commit 93531c674315 ("net/ipv6: separate
handling of FIB entries from dst based routes"), it has used rt->from
to dump route info instead of rt.
However for some route like cache, its information is not the same as
that of the 'from' one. It caused 'ip -6 route get' to dump the wrong
route information.
In Jianlin's testing, the output information even lost the expiration
time for a pmtu route cache due to the wrong fib6_flags.
So change to use rt6_info members when it tries to dump a route entry
without fibmatch set.
Note that we will fix the gw/nh dump in another patch.
Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv6/route.c | 39 ++++++++++++++++++++++++++-------------
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 18e00ce..e554922 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4670,20 +4670,33 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
int iif, int type, u32 portid, u32 seq,
unsigned int flags)
{
- struct rtmsg *rtm;
+ struct rt6key *fib6_prefsrc, *fib6_dst, *fib6_src;
+ struct rt6_info *rt6 = (struct rt6_info *)dst;
+ u32 *pmetrics, table, fib6_flags;
struct nlmsghdr *nlh;
+ struct rtmsg *rtm;
long expires = 0;
- u32 *pmetrics;
- u32 table;
nlh = nlmsg_put(skb, portid, seq, type, sizeof(*rtm), flags);
if (!nlh)
return -EMSGSIZE;
+ if (rt6) {
+ fib6_dst = &rt6->rt6i_dst;
+ fib6_src = &rt6->rt6i_src;
+ fib6_flags = rt6->rt6i_flags;
+ fib6_prefsrc = &rt6->rt6i_prefsrc;
+ } else {
+ fib6_dst = &rt->fib6_dst;
+ fib6_src = &rt->fib6_src;
+ fib6_flags = rt->fib6_flags;
+ fib6_prefsrc = &rt->fib6_prefsrc;
+ }
+
rtm = nlmsg_data(nlh);
rtm->rtm_family = AF_INET6;
- rtm->rtm_dst_len = rt->fib6_dst.plen;
- rtm->rtm_src_len = rt->fib6_src.plen;
+ rtm->rtm_dst_len = fib6_dst->plen;
+ rtm->rtm_src_len = fib6_src->plen;
rtm->rtm_tos = 0;
if (rt->fib6_table)
table = rt->fib6_table->tb6_id;
@@ -4698,7 +4711,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
rtm->rtm_scope = RT_SCOPE_UNIVERSE;
rtm->rtm_protocol = rt->fib6_protocol;
- if (rt->fib6_flags & RTF_CACHE)
+ if (fib6_flags & RTF_CACHE)
rtm->rtm_flags |= RTM_F_CLONED;
if (dest) {
@@ -4706,7 +4719,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
goto nla_put_failure;
rtm->rtm_dst_len = 128;
} else if (rtm->rtm_dst_len)
- if (nla_put_in6_addr(skb, RTA_DST, &rt->fib6_dst.addr))
+ if (nla_put_in6_addr(skb, RTA_DST, &fib6_dst->addr))
goto nla_put_failure;
#ifdef CONFIG_IPV6_SUBTREES
if (src) {
@@ -4714,12 +4727,12 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
goto nla_put_failure;
rtm->rtm_src_len = 128;
} else if (rtm->rtm_src_len &&
- nla_put_in6_addr(skb, RTA_SRC, &rt->fib6_src.addr))
+ nla_put_in6_addr(skb, RTA_SRC, &fib6_src->addr))
goto nla_put_failure;
#endif
if (iif) {
#ifdef CONFIG_IPV6_MROUTE
- if (ipv6_addr_is_multicast(&rt->fib6_dst.addr)) {
+ if (ipv6_addr_is_multicast(&fib6_dst->addr)) {
int err = ip6mr_get_route(net, skb, rtm, portid);
if (err == 0)
@@ -4737,9 +4750,9 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
goto nla_put_failure;
}
- if (rt->fib6_prefsrc.plen) {
+ if (fib6_prefsrc->plen) {
struct in6_addr saddr_buf;
- saddr_buf = rt->fib6_prefsrc.addr;
+ saddr_buf = fib6_prefsrc->addr;
if (nla_put_in6_addr(skb, RTA_PREFSRC, &saddr_buf))
goto nla_put_failure;
}
@@ -4777,7 +4790,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
goto nla_put_failure;
}
- if (rt->fib6_flags & RTF_EXPIRES) {
+ if (fib6_flags & RTF_EXPIRES) {
expires = dst ? dst->expires : rt->expires;
expires -= jiffies;
}
@@ -4785,7 +4798,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
if (rtnl_put_cacheinfo(skb, dst, 0, expires, dst ? dst->error : 0) < 0)
goto nla_put_failure;
- if (nla_put_u8(skb, RTA_PREF, IPV6_EXTRACT_PREF(rt->fib6_flags)))
+ if (nla_put_u8(skb, RTA_PREF, IPV6_EXTRACT_PREF(fib6_flags)))
goto nla_put_failure;
--
2.1.0
^ permalink raw reply related
* [PATCH] xen-netback: remove unecessary condition check before debugfs_remove_recursive
From: zhong jiang @ 2018-09-08 13:53 UTC (permalink / raw)
To: davem, paul.durrant, wei.liu2; +Cc: xen-devel, netdev, linux-kernel
debugfs_remove_recursive has taken IS_ERR_OR_NULL into account. So just
remove the condition check before debugfs_remove_recursive.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/xen-netback/netback.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3621e05..80aae3a 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1660,8 +1660,7 @@ static int __init netback_init(void)
static void __exit netback_fini(void)
{
#ifdef CONFIG_DEBUG_FS
- if (!IS_ERR_OR_NULL(xen_netback_dbg_root))
- debugfs_remove_recursive(xen_netback_dbg_root);
+ debugfs_remove_recursive(xen_netback_dbg_root);
#endif /* CONFIG_DEBUG_FS */
xenvif_xenbus_fini();
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH] ieee802154: remove unecessary condition check before debugfs_remove_recursive
From: zhong jiang @ 2018-09-08 13:44 UTC (permalink / raw)
To: davem, alex.aring, michael.hennerich, stefan
Cc: linux-wpan, netdev, linux-kernel
debugfs_remove_recursive has taken IS_ERR_OR_NULL into account. So just
remove the condition check before debugfs_remove_recursive.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ieee802154/adf7242.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index 23a52b9..cd1d8fa 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -1308,8 +1308,7 @@ static int adf7242_remove(struct spi_device *spi)
{
struct adf7242_local *lp = spi_get_drvdata(spi);
- if (!IS_ERR_OR_NULL(lp->debugfs_root))
- debugfs_remove_recursive(lp->debugfs_root);
+ debugfs_remove_recursive(lp->debugfs_root);
cancel_delayed_work_sync(&lp->work);
destroy_workqueue(lp->wqueue);
--
1.7.12.4
^ permalink raw reply related
* [PATCH net-next] net: dsa: b53: Uninitialized variable in b53_adjust_link()
From: Dan Carpenter @ 2018-09-08 8:39 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Vivien Didelot, David S. Miller, netdev,
kernel-janitors
The "pause" variable is only initialized on BCM5301x.
Fixes: 5e004460f874 ("net: dsa: b53: Add helper to set link parameters")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index ea4256cd628b..dbf5b86a07fe 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1025,7 +1025,7 @@ static void b53_adjust_link(struct dsa_switch *ds, int port,
struct b53_device *dev = ds->priv;
struct ethtool_eee *p = &dev->ports[port].eee;
u8 rgmii_ctrl = 0, reg = 0, off;
- int pause;
+ int pause = 0;
if (!phy_is_pseudo_fixed_link(phydev))
return;
^ permalink raw reply related
* Re: Containers and checkpoint/restart micro-conference at LPC2018
From: Amir Goldstein @ 2018-09-08 7:41 UTC (permalink / raw)
To: Stephane Graber
Cc: lxc-devel, lxc-users, containers, LSM List, linux-fsdevel, Netdev,
overlayfs, Miklos Szeredi, Vivek Goyal
In-Reply-To: <20180908045935.GA9201@castiana>
On Sat, Sep 8, 2018 at 8:00 AM Stéphane Graber <stgraber@ubuntu.com> wrote:
>
> On Mon, Aug 13, 2018 at 12:10:15PM -0400, Stéphane Graber wrote:
> > Hello,
> >
> > This year's edition of the Linux Plumbers Conference will once again
> > have a containers micro-conference but this time around we'll have twice
> > the usual amount of time and will include the content that would
> > traditionally go into the checkpoint/restore micro-conference.
> >
> > LPC2018 will be held in Vancouver, Canada from the 13th to the 15th of
> > November, co-located with the Linux Kernel Summit.
> >
> >
> > We're looking for discussion topics around kernel work related to
> > containers and namespacing, resource control, access control,
> > checkpoint/restore of kernel structures, filesystem/mount handling for
> > containers and any related userspace work.
> >
> >
> > The format of the event will mostly be discussions where someone
> > introduces a given topic/problem and it then gets discussed for 20-30min
> > before moving on to something else. There will also be limited room for
> > short demos of recent work with shorter 15min slots.
> >
> >
> > Details can be found here:
> >
> > https://discuss.linuxcontainers.org/t/containers-micro-conference-at-linux-plumbers-2018/2417
> >
> >
> > Looking forward to seeing you in Vancouver!
>
> Hello,
>
> We've added an extra week to the CFP, new deadline is Friday 14th of September.
>
> If you were thinking about sending something bug then forgot or just
> missed the deadline, now is your chance to send it!
>
[cc: overlayfs developers]
Hi Stéphane!
I am not planing to travel to LPC this year, so this is more of an FYI than
a CFP, but maybe another overlayfs developer can pick up this glove??
For the past two years I have participated in the effort to fix overlayfs
"non-standard" behavior:
https://github.com/amir73il/overlayfs/wiki/Overlayfs-non-standard-behavior
Allegedly, this effort went underway to improve the experience of overlayfs
users, who are mostly applications running inside containers. For backward
compatibility reasons, container runtimes will need to opt-in for fixing some
of the legacy behavior.
In reality, I have seen very little cross list interaction between linux-unionfs
and containers mailing lists. The only interaction I recall in the
past two years
ended up in a fix in overlayfs to require opt-in for fixing yet another backward
compatible bad behavior, although docker did follow up shortly after to fix
bad practice in container runtime:
https://github.com/moby/moby/issues/34672
So the questions I would like to relay to the micro-conf participants w.r.t the
new opt-in overlayfs behavior:
1. Did you know?
2. Do you care?
Cheers,
Amir.
^ permalink raw reply
* Re: [PATCH] PCI: Reprogram bridge prefetch registers on resume
From: Peter Wu @ 2018-09-08 12:14 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Daniel Drake, bhelgaas, linux-pci, linux, nouveau, linux-pm,
kherbst, andriy.shevchenko, rafael.j.wysocki, keith.busch,
mika.westerberg, jonathan.derrick, kugel, davem, hkallweit1,
netdev, nic_swsd, linux-kernel, Dave Jones, Luming Yu
In-Reply-To: <20180907222647.GD250890@bhelgaas-glaptop.roam.corp.google.com>
On Fri, Sep 07, 2018 at 05:26:47PM -0500, Bjorn Helgaas wrote:
> [+cc LKML, Dave, Luming]
>
> On Fri, Sep 07, 2018 at 05:05:15PM +0200, Peter Wu wrote:
> > On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
> > <..>
> > > Thomas Martitz reports that this workaround also solves an issue where
> > > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive
> > > after S3 suspend/resume.
> >
> > Where was this claimed? It is not stated in the linked bug:
> > (https://bugs.freedesktop.org/show_bug.cgi?id=105760
> >
> > > On resume, reprogram the PCI bridge prefetch registers, including the
> > > magic register mentioned above.
> > >
> > > This matches Win10 behaviour, which also rewrites these registers
> > > during S3 resume (checked with qemu tracing).
> >
> > Windows 10 unconditionally rewrites these registers (BAR, I/O Base +
> > Limit, Memory Base + Limit, etc. from top to bottom), see annotations:
> > https://www.spinics.net/lists/linux-pci/msg75856.html
> >
> > Linux has a generic "restore" operation that works backwards from the
> > end of the PCI config space to the beginning, see
> > pci_restore_config_space. Do you have a dmesg where you see the
> > "restoring config space at offset" messages?
> >
> > Would it be reasonable to unconditionally write these registers in
> > pci_restore_config_dword, like Windows does?
>
> That sounds reasonable to me.
>
> We did write them unconditionally, prior to 04d9c1a1100b ("[PATCH]
> PCI: Improve PCI config space writeback") [1]. That commit apparently
> fixed suspend on some laptop.
>
> But at that time, we restored the config space in order of dword 0, 1,
> 2, ... 15, which means we restored the command register before the
> BARs and windows, and it's conceivable that the problem was the
> ordering, not the rewriting of the same value.
>
> Only a week later, we reversed the order with 8b8c8d280ab2 ("[PATCH]
> PCI: reverse pci config space restore order") [2], which seems like a
> good idea and even includes a spec reference. I found similar
> language in the Intel ICH 10 datasheet, sec 14.1.3 [3].
>
> So it seems reasonable to me to try writing them unconditionally in
> reverse order (the same order we use today).
Some fields are readonly (device/vendor ID), others have side-effects
(write-to-clear semantics like Master Data Parity Error in the Status
register).
So in addition to always write the registers, what about writing only a
subset? Following the logic applied by Windows, for Type-1:
- Restore memory-related stuff:
- Restore BAR0 (offset 0x10, dword).
- Restore BAR1 (offset 0x14, dword).
- Restore I/O Base + Limit (offset 0x1c, WORD, not dword).
- Restore Memory Base + Limit (offset 0x20, dword).
- Restore Prefetchable Memory Base + Limit (offset 0x24, dword).
- Restore Prefetchable Base Upper 32 bits (offset 0x28, dword).
(+wait for 500us, why?)
- Restore Prefetchable Limit Upper 32 bits (offset 0x2c, dword).
(+wait for 500us, why?)
- Restore I/O Base + Limit Upper 32 bits (offset 0x30, dword).
(+wait for 500us, why?)
- Restore Expansion ROM Address (offset 0x38, dword).
- Restore at offset 0x3c:
- Restore Interrupt Line (offset 0x3c, byte).
- Restore Bridge Control (offset 0x3e, word).
(+read value again, why? Some kind of flush?)
- Restore at offset 0x18:
- Restore Primary Bus Number (offset 0x18, byte).
- Restore Secondary Bus Number (offset 0x19, byte).
- Restore Subordinate Bus Number (offset 0x1a, byte).
- (Restore Secondary Status (offset 0x1b, byte)? Not seen in Windows.)
- Restore at offset 0x0c:
- Cacheline Size (offset 0x0c, byte).
- Primary Latency Timer (offset 0x0d, byte).
- Restore at offset 0x04:
- Restore command register.
(+wait for 500us)
- (Actually Windows clears BM+Mem+I/O bits, then sets
PCIE.DeviceControl=7, PCIE.DeviceControl2=0 and then enables
BM+Mem+I/O again).
- Restore (or write to clear?) Status (offset 0x06, word).
- Note that the following fields are omitted (mostly readonly):
- Device ID + Vendor ID (offset 0x00, dword).
- Revision ID + Class Code (offset 0x08, dword).
- Header Type + BIST (offset 0x0e, byte + byte).
- Capabilities Pointer + Reserved (offset 0x34, dword).
- Interrupt Pin (offset 0x3d, byte).
This is more complicated than the current loop, but the logic of writing
addresses first and then configuring others sound reasonable to me.
Kind regards,
Peter
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=04d9c1a1100b
> [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8b8c8d280ab2
> [3] Intel ICH 10 IBL 373635
^ permalink raw reply
* Re: [PATCH] PCI: Reprogram bridge prefetch registers on resume
From: Thomas Martitz @ 2018-09-08 11:05 UTC (permalink / raw)
To: Peter Wu, Daniel Drake
Cc: nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w,
keith.busch-ral2JQCrhuEAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
linux-6IF/jdPJHihWk0Htik3J/w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20180907150515.GA28739@al>
Am 07.09.18 um 17:05 schrieb Peter Wu:
> On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
> <..>
>> Thomas Martitz reports that this workaround also solves an issue where
>> the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive
>> after S3 suspend/resume.
>
> Where was this claimed? It is not stated in the linked bug:
> (https://bugs.freedesktop.org/show_bug.cgi?id=105760
>
Actually, I reported that https://patchwork.kernel.org/patch/10583229/
works. I updated the bug now, I didn't do so yet because it's closed.
However, I did not actually test the exact patch *this* thread is about.
Do you want me to give it a spin?
Best regards.
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* Re: [PATCH] tcp: really ignore MSG_ZEROCOPY if no SO_ZEROCOPY
From: David Miller @ 2018-09-08 6:11 UTC (permalink / raw)
To: vincent.whitchurch; +Cc: netdev, willemb, rabinv
In-Reply-To: <20180906135459.15529-1-vincent.whitchurch@axis.com>
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date: Thu, 6 Sep 2018 15:54:59 +0200
> According to the documentation in msg_zerocopy.rst, the SO_ZEROCOPY
> flag was introduced because send(2) ignores unknown message flags and
> any legacy application which was accidentally passing the equivalent of
> MSG_ZEROCOPY earlier should not see any new behaviour.
>
> Before commit f214f915e7db ("tcp: enable MSG_ZEROCOPY"), a send(2) call
> which passed the equivalent of MSG_ZEROCOPY without setting SO_ZEROCOPY
> would succeed. However, after that commit, it fails with -ENOBUFS. So
> it appears that the SO_ZEROCOPY flag fails to fulfill its intended
> purpose. Fix it.
>
> Fixes: f214f915e7db ("tcp: enable MSG_ZEROCOPY")
> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: impose mandatory VLAN usage when non-zero TAG ID
From: David Miller @ 2018-09-08 6:06 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, dt, leedom
In-Reply-To: <1536316173-29168-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Fri, 7 Sep 2018 15:59:33 +0530
> From: Casey Leedom <leedom@chelsio.com>
>
> When a non-zero VLAN Tag ID is passed to t4_set_vlan_acl()
> then impose mandatory VLAN Usage with that VLAN ID.
> I.e any other VLAN ID should result in packets getting
> dropped.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [Patch net] net_sched: properly cancel netlink dump on failure
From: David Miller @ 2018-09-08 6:05 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, dcaratti, simon.horman
In-Reply-To: <20180906215016.399-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 6 Sep 2018 14:50:16 -0700
> When nla_put*() fails after nla_nest_start(), we need
> to call nla_nest_cancel() to cancel the message, otherwise
> we end up calling nla_nest_end() like a success.
>
> Fixes: 0ed5269f9e41 ("net/sched: add tunnel option support to act_tunnel_key")
> Cc: Davide Caratti <dcaratti@redhat.com>
> Cc: Simon Horman <simon.horman@netronome.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] nfp: replace spin_lock_bh with spin_lock in tasklet callback
From: David Miller @ 2018-09-08 5:56 UTC (permalink / raw)
To: hangdianqj
Cc: jakub.kicinski, dirk.vandermerwe, daniel, quentin.monnet,
oss-drivers, netdev, linux-kernel
In-Reply-To: <20180907170109.48150-1-hangdianqj@163.com>
From: jun qian <hangdianqj@163.com>
Date: Fri, 7 Sep 2018 10:01:09 -0700
> As you are already in a tasklet, it is unnecessary to call spin_lock_bh.
>
> Signed-off-by: jun qian <hangdianqj@163.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: Expose tagging protocol to user-space
From: Jiri Pirko @ 2018-09-08 9:43 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Andrew Lunn, Vivien Didelot, David S. Miller, open list
In-Reply-To: <20180907180908.3223-1-f.fainelli@gmail.com>
Fri, Sep 07, 2018 at 08:09:02PM CEST, f.fainelli@gmail.com wrote:
>There is no way for user-space to know what a given DSA network device's
>tagging protocol is. Expose this information through a dsa/tagging
>attribute which reflects the tagging protocol currently in use.
>
>This is helpful for configuration (e.g: none behaves dramatically
>different wrt. bridges) as well as for packet capture tools when there
>is not a proper Ethernet type available.
Hmm, I wonder. It this something that varies between ports of an
individual ASIC? Or is it rather something defined per-ASIC. If so, this
looks more like a devlink-api material.
^ permalink raw reply
* Re: RE packet: fix reserve calculation - net/packet/af_packet.c
From: James Sakalaukus @ 2018-09-08 3:18 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Willem de Bruijn
In-Reply-To: <20180907.103402.1676027167656921237.davem@davemloft.net>
On Fri, Sep 7, 2018 at 1:34 PM, David Miller <davem@davemloft.net> wrote:
> From: Willem de Bruijn <willemb@google.com>
> Date: Fri, 7 Sep 2018 11:50:02 -0400
>
>> If you are not seeing these problems with other protocols, I must be
>> misreading that code.
>
> Right, the ethernet header is only guaranteed to be 2 byte aligned on
> transmit.
>
> Nothing ever gave larger alignment guarantees.
>
> This is the _only_ reasonable situation.
>
> If we made the ethernet header to be 4 byte aligned, that means the
> ipv4 addresses in the ipv4 header are not 4 byte aligned so we would
> do unaligned memory accesses when building the headers which are
> either expensive or trap depending upon the architecture.
Understood.
I thought SOCK_RAW made no assumptions with respect to the network
layer headers. Previously, the buffer was allocated and then data was
copied into it without giving thought to alignment. Sounds like I got
lucky with the alignment and I should have expected 2-bytes from day
1.
I've been using this device with only SOCK_RAW on a real time network,
and I have not even tried to use SOCK_STREAM or SOCK_DGRAM.
So, I just tried to use TCP on the device, and the buffer alignment is
in fact 2-bytes inside my transmit function, and my DMA core does not
work. So...I guess I need to bring my hardware into the 21st century
or do a copy in the driver transmit function.
Thanks for your time
^ permalink raw reply
* Re: [PATCH] mt76: another missing 'select' in Kconfig
From: Lorenzo Bianconi @ 2018-09-08 7:46 UTC (permalink / raw)
To: valdis.kletnieks-PjAqaU27lzQ
Cc: Kalle Valo, Network Development, linux-wireless
In-Reply-To: <30971.1536347293-+bZmOdGhbsPr6rcHtW+onFJE71vCis6O@public.gmane.org>
>
> commit b40b15e1521f7764ea8c68d5a00ecc971b673d21
> Author: Lorenzo Bianconi <lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date: Tue Jul 31 10:09:19 2018 +0200
>
> mt76: add usb support to mt76 layer
>
> add a new mt76-usb.c for MT76x2U USB devices, but failed to wire
> it up for MT76x0U USB devices.
>
> Signed-off-by: Valdis Kletnieks <valdis.kletnieks-PjAqaU27lzQ@public.gmane.org>
> ---
> diff --git a/drivers/net/wireless/mediatek/mt76/Kconfig b/drivers/net/wireless/mediatek/mt76/Kconfig
> index 6a270e759006..cec977b81305 100644
> --- a/drivers/net/wireless/mediatek/mt76/Kconfig
> +++ b/drivers/net/wireless/mediatek/mt76/Kconfig
> @@ -17,6 +17,7 @@ config MT76x2_COMMON
> config MT76x0U
> tristate "MediaTek MT76x0U (USB) support"
> select MT76_CORE
> + select MT76_USB
> depends on MAC80211
This fix is contained in latest series sent by Stanislaw:
https://patchwork.kernel.org/patch/10590265/
Regards,
Lorenzo
^ permalink raw reply
* Re: RE packet: fix reserve calculation - net/packet/af_packet.c
From: James Sakalaukus @ 2018-09-08 2:59 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: David Miller, netdev
In-Reply-To: <CA+FuTSdiO_L8mOC_urUz24RQ5AMD=Ntyi1vcMQ+QpuKCV3Y9Sg@mail.gmail.com>
On Fri, Sep 7, 2018 at 11:50 AM, Willem de Bruijn <willemb@google.com> wrote:
> Hi James,
>
> Thanks for the report. In the future please always include
> netdev@vger.kernel.org in technical discussions.
>
> On Fri, Sep 7, 2018 at 1:00 AM James Sakalaukus <james@sakalaukus.com> wrote:
>>
>> Hello Willem and David,
>>
>> I have an unpolished Ethernet driver for a PCIe FPGA subsystem, and
>> the following commit has the side effect of moving the data alignment
>> for SOCK_RAW packets.
>>
>>
>> commit b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba
>> net/packet/af_packet.c
>>
>> These changes to packet_snd() moves the data and tail pointers
>> backwards by net_device->hard_header_len, which is nominally ETH_HLEN.
>> The .ndo_start_xmit driver function now gets a struct sk_buff with
>> data alignment on a 2-byte boundary. My DMA core is not happy about
>> it.
>>
>>
>> commit 9aad13b087ab0a588cd68259de618f100053360e
>>
>> This commit changed the previous fix from a skb_push to skb_reserve.
>> The functionality from my end did not change though. .ndo_start_xmit
>> still gets a struct sk_buff with 2 byte alignment.
>>
>>
>> This may be causing problems for other network drivers with DMA
>> alignment requirements, but maybe its just me.
>
> This is the crux of the question.
>
>
> Did the PACKET_TX_RING variant work with your device?
>
> A quick scan seems to indicate that it is common to allocate a linear
> buffer and then reserve hard_header_len aligned up to 16B
> (HH_MOD_LEN). The actual alignment of both link layer and network
> header then depends on the alignment with which kmalloc returned. It
> is probably safe to assume that the buddy allocator returns a multiple
> of 4B at least for allocations of this size. Then the network layer
> header is 4B aligned. But for Ethernet, the skb_push in eth_header()
> would make the link layer header 2B aligned.
>
> If you are not seeing these problems with other protocols, I must be
> misreading that code.
>
> I will take a closer look.
>
I actually have not tested the device with any protocols other than
SOCK_RAW. This device is on a real time network that does not use
standard network layer protocols.
PACKET_TX_RING is something I haven't had time to delve into.
It may be the case that other protocols always hand over a 2-byte
aligned buffer. All I know for sure is that I was getting a 4-byte
aligned buffer before the update.
>> I've only been working
>> on the driver for about 6 months, so its not released, though I would
>> like to put it out there for others. I updated my distro kernel this
>> week, and then proceeded to beat my head against the wall trying to
>> figure out why my driver mysteriously stopped working.
>>
>>
>> Thanks for your time,
>>
>> James Sakalaukus
>> james@sakalaukus.com
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: b53: Fix build with B53_SRAB enabled and not B53_SERDES
From: David Miller @ 2018-09-08 6:12 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20180906184245.31442-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 6 Sep 2018 11:42:45 -0700
> In case B53_SRAB is enabled, but not B53_SERDES, we can get the
> following linking error:
>
> ERROR: "b53_serdes_init" [drivers/net/dsa/b53/b53_srab.ko] undefined!
>
> We also need to ifdef the body of b53_srab_serdes_map_lane() since it
> would not be used when B53_SERDES is disabled and that would produce a
> warning.
>
> Fixes: 0e01491de646 ("net: dsa: b53: Add SerDes support")
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xen/netfront: fix waiting for xenbus state change
From: David Miller @ 2018-09-08 6:03 UTC (permalink / raw)
To: jgross; +Cc: linux-kernel, xen-devel, netdev, boris.ostrovsky, stable
In-Reply-To: <20180907122130.30810-1-jgross@suse.com>
From: Juergen Gross <jgross@suse.com>
Date: Fri, 7 Sep 2018 14:21:30 +0200
> Commit 822fb18a82aba ("xen-netfront: wait xenbus state change when load
> module manually") added a new wait queue to wait on for a state change
> when the module is loaded manually. Unfortunately there is no wakeup
> anywhere to stop that waiting.
>
> Instead of introducing a new wait queue rename the existing
> module_unload_q to module_wq and use it for both purposes (loading and
> unloading).
>
> As any state change of the backend might be intended to stop waiting
> do the wake_up_all() in any case when netback_changed() is called.
>
> Fixes: 822fb18a82aba ("xen-netfront: wait xenbus state change when load module manually")
> Cc: <stable@vger.kernel.org> #4.18
> Signed-off-by: Juergen Gross <jgross@suse.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/4] of: Convert to using %pOFn instead of device_node.name
From: Joe Perches @ 2018-09-08 0:30 UTC (permalink / raw)
To: Thierry Reding, Rob Herring
Cc: Frank Rowand, devicetree, linux-kernel, Andrew Lunn,
Florian Fainelli, netdev
In-Reply-To: <20180907122928.GA5821@ulmo>
On Fri, 2018-09-07 at 14:29 +0200, Thierry Reding wrote:
> On Tue, Aug 28, 2018 at 10:52:53AM -0500, Rob Herring wrote:
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> >
> > Cc: Frank Rowand <frowand.list@gmail.com>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Florian Fainelli <f.fainelli@gmail.com>
> > Cc: devicetree@vger.kernel.org
> > Cc: netdev@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > drivers/of/device.c | 4 ++--
> > drivers/of/of_mdio.c | 12 ++++++------
> > drivers/of/of_numa.c | 4 ++--
> > drivers/of/overlay.c | 4 ++--
> > drivers/of/platform.c | 8 ++++----
> > drivers/of/unittest.c | 12 ++++++------
> > 6 files changed, 22 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > index 5957cd4fa262..daa075d87317 100644
> > --- a/drivers/of/device.c
> > +++ b/drivers/of/device.c
> > @@ -219,7 +219,7 @@ static ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len
> > return -ENODEV;
> >
> > /* Name & Type */
> > - csize = snprintf(str, len, "of:N%sT%s", dev->of_node->name,
> > + csize = snprintf(str, len, "of:N%pOFnT%s", dev->of_node,
> > dev->of_node->type);
> > tsize = csize;
> > len -= csize;
>
> This seems to cause the modalias to be improperly constructed. As a
> consequence, automatic module loading at boot time is now broken. I
> think the reason why this fails is because vsnprintf() will skip all
> alpha-numeric characters after a call to pointer(). Presumably this
> is meant to be a generic way of skipping whatever specifiers we throw
> at it.
>
> Unfortunately for the case of OF modaliases, this means that the 'T'
> character gets eaten, so we end up with something like this:
>
> # udevadm info /sys/bus/platform/devices/54200000.dc
> [...]
> E: MODALIAS=of:Ndc<NULL>Cnvidia,tegra124-dc
> [...]
>
> instead of this:
>
> # udevadm info /sys/bus/platform/devices/54200000.dc
> [...]
> E: MODALIAS=of:NdcT<NULL>Cnvidia,tegra124-dc
> [...]
>
> Everything is back to normal if I revert this patch. However, since
> that's obviously not what we want, I think perhaps what we need is a
> way for pointer() (and its implementations) to report back how many
> characters in the format string it consumed so that we can support
> these kinds of back-to-back strings.
>
> If nobody else has the time I can look into coding up a fix, but in the
> meantime it might be best to back this one out until we can handle the
> OF modalias format string.
Or just use 2 consecutive snprintf calls
csize = snprintf(str, len, "of:N%pOFn", dev->of_node);
csize += snprintf(str + csize, len - csize, "T%s",
dev->of_node->type);
^ 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