* Re: [PATCH] brcmfmac: unlink URB when request timed out
From: Arend van Spriel @ 2014-11-10 11:18 UTC (permalink / raw)
To: Mathy Vanhoef, brudley, frankyl, meuleman, linville, pieterpg,
linux-wireless, brcm80211-dev-list, netdev, Oliver Neukum
In-Reply-To: <545FAE05.2030701@gmail.com>
On 09-11-14 19:10, Mathy Vanhoef wrote:
> From: Mathy Vanhoef <vanhoefm@gmail.com>
>
> Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
> assures the URB is never submitted twice, preventing a driver crash.
Hi Mathy,
What driver crash are you referring to? The log only shows the WARNING
ending in a USB disconnect but no actual crash. Does your patch get the
driver running properly or does it only avoid the warning.
With that said, it seems there is some need for improvement, but I also
notice you are running this on a virtual machine so could that affect
the timeout to kick in before completion. Could you try to increase the
timeout. Still when a timeout occurs this needs to be handled properly.
Could you also try the following patch?
Regards,
Arend
---
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
b/drivers/net/wireles
index dc13591..786c40b 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
@@ -640,7 +640,7 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info
*devinf
char *tmpbuf;
u16 size;
- if ((!devinfo) || (devinfo->ctl_urb == NULL))
+ if (!devinfo || !devinfo->ctl_urb || !devinfo->ctl_completed)
return -EINVAL;
tmpbuf = kmalloc(buflen, GFP_ATOMIC);
> Signed-off-by: Mathy Vanhoef <vanhoefm@gmail.com>
> ---
> Currently brcmfmac may crash when a USB device is attached (tested with a LG
> TWFM-B003D). In particular it fails on the second call to brcmf_usb_dl_cmd in
> the while loop of brcmf_usb_resetcfg. The problem is that an URB is being
> submitted twice:
>
> [ 169.861800] brcmfmac: brcmf_usb_dl_writeimage Enter, fw f14db000, len 348160
> [ 171.787791] brcmfmac: brcmf_usb_dl_writeimage Exit, err=0
> [ 171.787797] brcmfmac: brcmf_usb_dlstart Exit, err=0
> [ 171.787799] brcmfmac: brcmf_usb_dlrun Enter
> [ 171.791794] brcmfmac: brcmf_usb_resetcfg Enter
> [ 173.988072] ------------[ cut here ]------------
> [ 173.988083] WARNING: CPU: 0 PID: 369 at drivers/usb/core/urb.c:339 usb_submit_urb+0x4e6/0x500()
> [ 173.988085] URB eaf45f00 submitted while active
> [ 173.988086] Modules linked in: brcmfmac brcmutil vmw_pvscsi pcnet32 mptspi mptscsih mptbase
> [ 173.988100] CPU: 0 PID: 369 Comm: kworker/0:2 Not tainted 3.18.0-rc3-wl #1
> [ 173.988102] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
> [ 173.988106] Workqueue: events request_firmware_work_func
> [ 173.988108] 00000000 00000000 ee747db8 c1711f4a ee747df8 ee747de8 c103edaf c18d1e10
> [ 173.988112] ee747e14 00000171 c18a8b29 00000153 c1490556 c1490556 eaf45f00 eafdc660
> [ 173.988115] f14b8fa0 ee747e00 c103ee4e 00000009 ee747df8 c18d1e10 ee747e14 ee747e50
> [ 173.988119] Call Trace:
> [ 173.988129] [<c1711f4a>] dump_stack+0x41/0x52
> [ 173.988136] [<c103edaf>] warn_slowpath_common+0x7f/0xa0
> [ 173.988139] [<c1490556>] ? usb_submit_urb+0x4e6/0x500
> [ 173.988141] [<c1490556>] ? usb_submit_urb+0x4e6/0x500
> [ 173.988147] [<f14b8fa0>] ? brcmf_usb_ioctl_resp_wake+0x40/0x40 [brcmfmac]
> [ 173.988150] [<c103ee4e>] warn_slowpath_fmt+0x2e/0x30
> [ 173.988152] [<c1490556>] usb_submit_urb+0x4e6/0x500
> [ 173.988156] [<c1123de1>] ? __kmalloc+0x21/0x140
> [ 173.988161] [<f14b91c3>] ? brcmf_usb_dl_cmd+0x33/0x120 [brcmfmac]
> [ 173.988166] [<f14b9243>] brcmf_usb_dl_cmd+0xb3/0x120 [brcmfmac]
> [ 173.988170] [<f14ba6c4>] brcmf_usb_probe_phase2+0x4e4/0x640 [brcmfmac]
> [ 173.988176] [<f14b4900>] brcmf_fw_request_code_done+0xd0/0xf0 [brcmfmac]
> [ 173.988178] [<c1400876>] request_firmware_work_func+0x26/0x50
> [ 173.988182] [<c10513ee>] process_one_work+0x11e/0x360
> [ 173.988184] [<c1051750>] worker_thread+0xf0/0x3c0
> [ 173.988205] [<c106e14a>] ? __wake_up_locked+0x1a/0x20
> [ 173.988208] [<c1051660>] ? process_scheduled_works+0x30/0x30
> [ 173.988211] [<c1055b56>] kthread+0x96/0xb0
> [ 173.988214] [<c1719c81>] ret_from_kernel_thread+0x21/0x30
> [ 173.988217] [<c1055ac0>] ? kthread_worker_fn+0x110/0x110
> [ 173.988219] ---[ end trace 0c88bf46801de083 ]---
> [ 173.988221] brcmf_usb_dl_cmd: usb_submit_urb failed -16
> [ 173.988396] brcmfmac: brcmf_usb_probe_phase2 failed: dev=1-1, err=-19
> [ 173.989503] brcmfmac: brcmf_usb_disconnect Enter
>
> This patch fixes the brcmf_usb_dl_cmd function to prevent an URB from being
> submitted twice. Tested using a LG TWFM-B003D, which now works properly.
>
>
> drivers/net/wireless/brcm80211/brcmfmac/usb.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> index 5265aa7..1bc7858 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> @@ -738,10 +738,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info *devinfo, u8 cmd,
> goto finalize;
> }
>
> - if (!brcmf_usb_ioctl_resp_wait(devinfo))
> + if (!brcmf_usb_ioctl_resp_wait(devinfo)) {
> + usb_unlink_urb(devinfo->ctl_urb);
> ret = -ETIMEDOUT;
> - else
> + } else {
> memcpy(buffer, tmpbuf, buflen);
> + }
>
> finalize:
> kfree(tmpbuf);
>
^ permalink raw reply related
* [PATCH resent] net: ppp: Don't call bpf_prog_create() in ppp_lock
From: Takashi Iwai @ 2014-11-10 10:50 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Paul Mackerras, linux-ppp, Stefan Seyfried
In ppp_ioctl(), bpf_prog_create() is called inside ppp_lock, which
eventually calls vmalloc() and hits BUG_ON() in vmalloc.c. This patch
works around the problem by moving the allocation outside the lock.
The bug was revealed by the recent change in net/core/filter.c, as it
allocates via vmalloc() instead of kmalloc() now.
Reported-and-tested-by: Stefan Seyfried <stefan.seyfried@googlemail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/net/ppp/ppp_generic.c | 40 ++++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 68c3a3f4e0ab..794a47329368 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -755,23 +755,23 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
err = get_filter(argp, &code);
if (err >= 0) {
+ struct bpf_prog *pass_filter = NULL;
struct sock_fprog_kern fprog = {
.len = err,
.filter = code,
};
- ppp_lock(ppp);
- if (ppp->pass_filter) {
- bpf_prog_destroy(ppp->pass_filter);
- ppp->pass_filter = NULL;
+ err = 0;
+ if (fprog.filter)
+ err = bpf_prog_create(&pass_filter, &fprog);
+ if (!err) {
+ ppp_lock(ppp);
+ if (ppp->pass_filter)
+ bpf_prog_destroy(ppp->pass_filter);
+ ppp->pass_filter = pass_filter;
+ ppp_unlock(ppp);
}
- if (fprog.filter != NULL)
- err = bpf_prog_create(&ppp->pass_filter,
- &fprog);
- else
- err = 0;
kfree(code);
- ppp_unlock(ppp);
}
break;
}
@@ -781,23 +781,23 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
err = get_filter(argp, &code);
if (err >= 0) {
+ struct bpf_prog *active_filter = NULL;
struct sock_fprog_kern fprog = {
.len = err,
.filter = code,
};
- ppp_lock(ppp);
- if (ppp->active_filter) {
- bpf_prog_destroy(ppp->active_filter);
- ppp->active_filter = NULL;
+ err = 0;
+ if (fprog.filter)
+ err = bpf_prog_create(&active_filter, &fprog);
+ if (!err) {
+ ppp_lock(ppp);
+ if (ppp->active_filter)
+ bpf_prog_destroy(ppp->active_filter);
+ ppp->active_filter = active_filter;
+ ppp_unlock(ppp);
}
- if (fprog.filter != NULL)
- err = bpf_prog_create(&ppp->active_filter,
- &fprog);
- else
- err = 0;
kfree(code);
- ppp_unlock(ppp);
}
break;
}
--
2.1.3
^ permalink raw reply related
* [PATCH] stmmac: split to core library and probe drivers
From: Andy Shevchenko @ 2014-11-10 10:38 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
Vince Bridgers
Cc: Andy Shevchenko
Instead of registering the platform and PCI drivers in one module let's move
necessary bits to where it belongs. During this procedure we convert the module
registration part to use module_*_driver() macros which makes code simplier.
>From now on the driver consists three parts: core library, PCI, and platform
drivers.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 4 +-
drivers/net/ethernet/stmicro/stmmac/Makefile | 15 +++---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 61 ----------------------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 36 ++-----------
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 13 ++---
6 files changed, 25 insertions(+), 108 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 33b85ba..7d3af19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -14,7 +14,7 @@ config STMMAC_ETH
if STMMAC_ETH
config STMMAC_PLATFORM
- bool "STMMAC Platform bus support"
+ tristate "STMMAC Platform bus support"
depends on STMMAC_ETH
default y
---help---
@@ -27,7 +27,7 @@ config STMMAC_PLATFORM
If unsure, say N.
config STMMAC_PCI
- bool "STMMAC PCI bus support"
+ tristate "STMMAC PCI bus support"
depends on STMMAC_ETH && PCI
---help---
This is to select the Synopsys DWMAC available on PCI devices,
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 034da70..ac4d562 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -1,9 +1,12 @@
obj-$(CONFIG_STMMAC_ETH) += stmmac.o
-stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
-stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o dwmac-meson.o \
- dwmac-sunxi.o dwmac-sti.o \
- dwmac-socfpga.o
stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \
- chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
- dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
+ chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
+ dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o $(stmmac-y)
+
+obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
+stmmac-platform-objs:= stmmac_platform.o dwmac-meson.o dwmac-sunxi.o \
+ dwmac-sti.o dwmac-socfpga.o
+
+obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
+stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index bd75ee8..c0a3919 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -134,65 +134,4 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
void stmmac_disable_eee_mode(struct stmmac_priv *priv);
bool stmmac_eee_init(struct stmmac_priv *priv);
-#ifdef CONFIG_STMMAC_PLATFORM
-extern struct platform_driver stmmac_pltfr_driver;
-
-static inline int stmmac_register_platform(void)
-{
- int err;
-
- err = platform_driver_register(&stmmac_pltfr_driver);
- if (err)
- pr_err("stmmac: failed to register the platform driver\n");
-
- return err;
-}
-
-static inline void stmmac_unregister_platform(void)
-{
- platform_driver_unregister(&stmmac_pltfr_driver);
-}
-#else
-static inline int stmmac_register_platform(void)
-{
- pr_debug("stmmac: do not register the platf driver\n");
-
- return 0;
-}
-
-static inline void stmmac_unregister_platform(void)
-{
-}
-#endif /* CONFIG_STMMAC_PLATFORM */
-
-#ifdef CONFIG_STMMAC_PCI
-extern struct pci_driver stmmac_pci_driver;
-static inline int stmmac_register_pci(void)
-{
- int err;
-
- err = pci_register_driver(&stmmac_pci_driver);
- if (err)
- pr_err("stmmac: failed to register the PCI driver\n");
-
- return err;
-}
-
-static inline void stmmac_unregister_pci(void)
-{
- pci_unregister_driver(&stmmac_pci_driver);
-}
-#else
-static inline int stmmac_register_pci(void)
-{
- pr_debug("stmmac: do not register the PCI driver\n");
-
- return 0;
-}
-
-static inline void stmmac_unregister_pci(void)
-{
-}
-#endif /* CONFIG_STMMAC_PCI */
-
#endif /* __STMMAC_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 53db11b..0f1c146 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2885,6 +2885,7 @@ error_clk_get:
return ERR_PTR(ret);
}
+EXPORT_SYMBOL_GPL(stmmac_dvr_probe);
/**
* stmmac_dvr_remove
@@ -2914,8 +2915,8 @@ int stmmac_dvr_remove(struct net_device *ndev)
return 0;
}
+EXPORT_SYMBOL_GPL(stmmac_dvr_remove);
-#ifdef CONFIG_PM
int stmmac_suspend(struct net_device *ndev)
{
struct stmmac_priv *priv = netdev_priv(ndev);
@@ -2957,6 +2958,7 @@ int stmmac_suspend(struct net_device *ndev)
priv->oldduplex = -1;
return 0;
}
+EXPORT_SYMBOL_GPL(stmmac_suspend);
int stmmac_resume(struct net_device *ndev)
{
@@ -3003,37 +3005,7 @@ int stmmac_resume(struct net_device *ndev)
return 0;
}
-#endif /* CONFIG_PM */
-
-/* Driver can be configured w/ and w/ both PCI and Platf drivers
- * depending on the configuration selected.
- */
-static int __init stmmac_init(void)
-{
- int ret;
-
- ret = stmmac_register_platform();
- if (ret)
- goto err;
- ret = stmmac_register_pci();
- if (ret)
- goto err_pci;
- return 0;
-err_pci:
- stmmac_unregister_platform();
-err:
- pr_err("stmmac: driver registration failed\n");
- return ret;
-}
-
-static void __exit stmmac_exit(void)
-{
- stmmac_unregister_platform();
- stmmac_unregister_pci();
-}
-
-module_init(stmmac_init);
-module_exit(stmmac_exit);
+EXPORT_SYMBOL_GPL(stmmac_resume);
#ifndef MODULE
static int __init stmmac_cmdline_opt(char *str)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 5084699..77a6d68 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -158,7 +158,7 @@ static const struct pci_device_id stmmac_id_table[] = {
MODULE_DEVICE_TABLE(pci, stmmac_id_table);
-struct pci_driver stmmac_pci_driver = {
+static struct pci_driver stmmac_pci_driver = {
.name = STMMAC_RESOURCE_NAME,
.id_table = stmmac_id_table,
.probe = stmmac_pci_probe,
@@ -168,6 +168,8 @@ struct pci_driver stmmac_pci_driver = {
},
};
+module_pci_driver(stmmac_pci_driver);
+
MODULE_DESCRIPTION("STMMAC 10/100/1000 Ethernet PCI driver");
MODULE_AUTHOR("Rayagond Kokatanur <rayagond.kokatanur@vayavyalabs.com>");
MODULE_AUTHOR("Giuseppe Cavallaro <peppe.cavallaro@st.com>");
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 9f18401..e22a960 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -362,7 +362,7 @@ static int stmmac_pltfr_remove(struct platform_device *pdev)
return ret;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int stmmac_pltfr_suspend(struct device *dev)
{
int ret;
@@ -388,13 +388,12 @@ static int stmmac_pltfr_resume(struct device *dev)
return stmmac_resume(ndev);
}
-
-#endif /* CONFIG_PM */
+#endif /* CONFIG_PM_SLEEP */
static SIMPLE_DEV_PM_OPS(stmmac_pltfr_pm_ops,
- stmmac_pltfr_suspend, stmmac_pltfr_resume);
+ stmmac_pltfr_suspend, stmmac_pltfr_resume);
-struct platform_driver stmmac_pltfr_driver = {
+static struct platform_driver stmmac_pltfr_driver = {
.probe = stmmac_pltfr_probe,
.remove = stmmac_pltfr_remove,
.driver = {
@@ -402,9 +401,11 @@ struct platform_driver stmmac_pltfr_driver = {
.owner = THIS_MODULE,
.pm = &stmmac_pltfr_pm_ops,
.of_match_table = of_match_ptr(stmmac_dt_ids),
- },
+ },
};
+module_platform_driver(stmmac_pltfr_driver);
+
MODULE_DESCRIPTION("STMMAC 10/100/1000 Ethernet PLATFORM driver");
MODULE_AUTHOR("Giuseppe Cavallaro <peppe.cavallaro@st.com>");
MODULE_LICENSE("GPL");
--
2.1.3
^ permalink raw reply related
* Re: [PATCH net-next 05/13] ethtool,net/mlx4_en: Add 100M, 20G, 56G speeds ethtool reporting support
From: Saeed Mahameed @ 2014-11-10 10:30 UTC (permalink / raw)
To: Ben Hutchings, Amir Vadai
Cc: David S. Miller, netdev, Yevgeny Petrilin, Or Gerlitz,
Saeed Mahameed
In-Reply-To: <1415227117.3398.31.camel@decadent.org.uk>
On 11/6/2014 12:38 AM, Ben Hutchings wrote:
> On Mon, 2014-10-27 at 11:37 +0200, Amir Vadai wrote:
>> From: Saeed Mahameed <saeedm@mellanox.com>
>>
>> Added 100M, 20G and 56G ethtool speed reporting support.
>> Update mlx4_en_test_speed self test with the new speeds.
>>
>> Defined new link speeds in include/uapi/linux/ethtool.h:
>> +#define SPEED_20000 20000
>> +#define SPEED_40000 40000
>> +#define SPEED_56000 56000
>>
>> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> [...]
>> --- a/include/uapi/linux/ethtool.h
>> +++ b/include/uapi/linux/ethtool.h
>> @@ -1213,6 +1213,10 @@ enum ethtool_sfeatures_retval_bits {
>> #define SUPPORTED_40000baseCR4_Full (1 << 24)
>> #define SUPPORTED_40000baseSR4_Full (1 << 25)
>> #define SUPPORTED_40000baseLR4_Full (1 << 26)
>> +#define SUPPORTED_56000baseKR4_Full (1 << 27)
>> +#define SUPPORTED_56000baseCR4_Full (1 << 28)
>> +#define SUPPORTED_56000baseSR4_Full (1 << 29)
>> +#define SUPPORTED_56000baseLR4_Full (1 << 30)
>>
>> #define ADVERTISED_10baseT_Half (1 << 0)
>> #define ADVERTISED_10baseT_Full (1 << 1)
>> @@ -1241,6 +1245,10 @@ enum ethtool_sfeatures_retval_bits {
>> #define ADVERTISED_40000baseCR4_Full (1 << 24)
>> #define ADVERTISED_40000baseSR4_Full (1 << 25)
>> #define ADVERTISED_40000baseLR4_Full (1 << 26)
>> +#define ADVERTISED_56000baseKR4_Full (1 << 27)
>> +#define ADVERTISED_56000baseCR4_Full (1 << 28)
>> +#define ADVERTISED_56000baseSR4_Full (1 << 29)
>> +#define ADVERTISED_56000baseLR4_Full (1 << 30)
> Can these modes be auto-negotiated? If not then they don't need
> advertised/supported bits.
Hi Ben,
At least 56000baseKR4_Full and 56000baseCR4_Full can be negotiated for sure,
regarding SR and LR i will check with arch team.
>> /* The following are all involved in forcing a particular link
>> * mode for the device for setting things. When getting the
>> @@ -1248,12 +1256,16 @@ enum ethtool_sfeatures_retval_bits {
>> * it was forced up into this mode or autonegotiated.
>> */
>>
>> -/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE. */
>> +/* The forced speed, 10Mb, 100Mb, gigabit, [2.5|10|20|40|56]GbE. */
>> #define SPEED_10 10
>> #define SPEED_100 100
>> #define SPEED_1000 1000
>> #define SPEED_2500 2500
>> #define SPEED_10000 10000
>> +#define SPEED_20000 20000
>> +#define SPEED_40000 40000
>> +#define SPEED_56000 56000
> We shouldn't add new SPEED macros. The speed is just a number of Mbit/s
> and we don't need to enumerate the possible values.
It is a little bit confusing that some speeds still use the defines
above, and new speeds should be hardcoded.
Why those speeds still there? is it some kind of work that need to be
done (i.e remove all of those defines) or are they needed in other
situations.
I thought it is nice that well-known speeds are organized in such MACROs
and this will prevent drivers from using magic numbers in their code.
Thanks for your time,
-Saeed.
>
> Ben.
>
>> #define SPEED_UNKNOWN -1
>>
>> /* Duplex, half or full. */
^ permalink raw reply
* Re: BUG ? - natsemi: Allow users to disable workaround for DspCfg reset
From: Mark Brown @ 2014-11-10 10:20 UTC (permalink / raw)
To: devzero; +Cc: netdev, Jeff Garzik
In-Reply-To: <trinity-83a3e1d0-0840-4d1e-98c1-e9e968c4af05-1415562288729@3capp-webde-bs47>
[-- Attachment #1: Type: text/plain, Size: 210 bytes --]
On Sun, Nov 09, 2014 at 08:44:48PM +0100, devzero@web.de wrote:
> Hi,
>
> i wanted to get rid of some heavy natsemi driver dmesg spamming like
You've sent the same message twice in quick succession...
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Michael S. Tsirkin @ 2014-11-10 10:14 UTC (permalink / raw)
To: Al Viro; +Cc: David Miller, herbert, netdev, linux-kernel, bcrl
In-Reply-To: <20141109211908.GF7996@ZenIV.linux.org.uk>
On Sun, Nov 09, 2014 at 09:19:08PM +0000, Al Viro wrote:
> [Michael Cc'd]
>
> On Fri, Nov 07, 2014 at 11:42:53PM +0000, Al Viro wrote:
>
> > I'll finish RTFS drivers/vhost and if it turns out to be OK I'll post the
> > series moving those checks to the moment of copying iovec from userland,
> > so that kernel-side we could always rely on ->msg_iov elements having been
> > verified.
>
> Two questions:
> 1) does sparc64 access_ok() need to differ for 32bit and 64bit tasks?
> AFAICS, x86 and ppc just check that address is OK for 64bit process -
> if a 32bit process passes the kernel an address that would be valid
> for 64bit process, but not for 32bit one, we just get a pagefault in
> __copy_from_user() and friends. No kernel objects are going to have
> a virtual address in that range, so access_ok() doesn't bother preventing
> such access attempts there...
>
> 2) shouldn't vhost_dev_cleanup() stop the worker thread before doing anything
> else?
> AFAICS, we do parts of vhost_dev teardown while the thread is
> still running; granted, we keep dev->mm pinned down until after it stops
> (or we would be _really_ screwed), but is it safe to do all those fput()s, etc.
> while it's still running? Michael?
Before invoking vhost_dev_cleanup,
the caller for vhost-net (vhost_net_release) sets private data to NULL
(using vhost_net_stop_vq) which guarantees thread will do nothing at all.
vhost scsi does it in vhost_scsi_clear_endpoint.
--
MST
^ permalink raw reply
* Re: [patch net-next v2 06/10] bridge: introduce fdb offloading via switchdev
From: Scott Feldman @ 2014-11-10 9:30 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jamal Hadi Salim, Netdev, David S. Miller, nhorman,
Andy Gospodarek, Thomas Graf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, Kirsher, Jeffrey T, vyasevic, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, Alexei Starovoitov
In-Reply-To: <20141110081552.GD1850@nanopsycho.orion>
On Sun, Nov 9, 2014 at 10:15 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Mon, Nov 10, 2014 at 04:47:48AM CET, jhs@mojatatu.com wrote:
>>On 11/09/14 05:51, Jiri Pirko wrote:
>>>From: Scott Feldman <sfeldma@gmail.com>
>>>
>>>Add two new ndos: ndo_sw_port_fdb_add/del to offload static bridge
>>>fdb entries. Static bridge FDB entries are installed, for example,
>>>using iproute2 bridge cmd:
>>>
>>> bridge fdb add ADDR dev DEV master vlan VID
>>>
>>>This would install ADDR into the bridge's FDB for port DEV on vlan VID. The
>>>switch driver implements two ndo_swdev ops to add/delete FDB entries in the
>>>switch device:
>>>
>>> int ndo_sw_port_fdb_add(struct net_device *dev,
>>> const unsigned char *addr,
>>> u16 vid);
>>>
>>> int ndo_sw_port_fdb_del(struct net_device *dev,
>>> const unsigned char *addr,
>>> u16 vid);
>>>
>>>The driver returns 0 on success, negative error code on failure.
>>>
>>>Note: the switch driver would not implement ndo_fdb_add/del/dump on a port
>>>netdev as these are intended for devices maintaining their own FDB. In our
>>>case, we want the Linux bridge to own the FBD.
>>>
>>>Note: by default, the bridge does not filter on VLAN and only bridges untagged
>>>traffic. To enable VLAN support, turn on VLAN filtering:
>>>
>>> echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering
>>>
>>
>>Sorry - why is the current fdb_add/del insufficient? It needs a vlanid
>>and the master/self flags should indicate intent to add to h/w vs s/w.
>
> Jamal, I believe we discussed this already. The thing is that current
> fdb_add/del does not need vlanid and master/self flags, because it
> already has that (struct nlattr *tb[]). Here is the whole list of
> parameters to these functions:
> NDA_DST,
> NDA_LLADDR,
> NDA_CACHEINFO,
> NDA_PROBES,
> NDA_VLAN,
> NDA_PORT,
> NDA_VNI,
> NDA_IFINDEX,
> NDA_MASTER,
>
> There are few problems in re-using this. It is netlink based so for calling
> it from bridge code, we would have to construct netlink message. But
> that could be probably changed.
> As you can see from the list of parameters, this is no longer about fdb (addr,
> vlanid) but this has been extended to something else. See vxlan code for
> what this is used for. I believe that fdb_add/del should be renamed to
> something else, perhaps l2neigh_add/del or something like that.
> The other problem is that fdb_add/del is currently used by various
> drivers for different purpose (adding macs to unicast list).
>
> Scott, you may probably want to add something to this.
You hit the main point: having to synthesize netlink msg in the bridge
driver and pass it down to port driver using .ndo_fdb_add/del is
awkward. And then, if the port driver implements .ndo_fdb_add/del
(and dump), then user could by-pass bridge and install fdbs directly
on port, as if the port maintains its own fdb. We want the bridge fdb
to be the single fdb, and static fdbs installed by user on bridge to
be pushed down to sw port driver to be installed in hw.
>>
>>cheers,
>>jamal
>>
^ permalink raw reply
* Re: [patch net-next v2 10/10] rocker: implement L2 bridge offloading
From: Nicolas Dichtel @ 2014-11-10 9:10 UTC (permalink / raw)
To: Jiri Pirko, Jamal Hadi Salim
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl
In-Reply-To: <20141110081826.GE1850@nanopsycho.orion>
Le 10/11/2014 09:18, Jiri Pirko a écrit :
> Mon, Nov 10, 2014 at 04:53:07AM CET, jhs@mojatatu.com wrote:
>> On 11/09/14 05:51, Jiri Pirko wrote:
>>> From: Scott Feldman <sfeldma@gmail.com>
>>>
>>> Add L2 bridge offloading support to rocker driver. Here, the Linux bridge
>>> driver is used to collect swdev ports into a tagged (or untagged) VLAN
>>> bridge. The swdev will offload from the bridge driver the following L2
>>> bridging functions:
>>>
>>> - Learning of neighbor MAC addresses on VLAN X Learned mac/vlan is
>>> installed in bridge FDB. (And removed when device unlearns mac/vlan).
>>> Learning must be turned off on each bridge port to disable the feature in
>>> the bridge driver.
>>>
>>
>> I have quiet a few use cases where the above is a no-no. I dont want
>> learning of any sort (we have a knob for that in the bridge).
>
> I would love to see your code. Please do share.
>
>> And i dont want learning in hardware to be reflected in software.
>> Basically this is a policy decision. Introduce a knob to choose whether
>> hardware learnt addresses should be reflected in software.
>
> This can be easily done as a bridge option I believe. If you are ok with
> that, I will add a patch (either in re-post or as a follow-up)
An option will be nice.
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-10 9:09 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, linux-kernel, bcrl, mst
In-Reply-To: <20141110.023000.1275181784917275552.davem@davemloft.net>
On Mon, Nov 10, 2014 at 02:30:00AM -0500, David Miller wrote:
> From: Al Viro <viro@ZenIV.linux.org.uk>
> Date: Mon, 10 Nov 2014 06:58:17 +0000
>
> > On Mon, Nov 10, 2014 at 12:20:20AM -0500, David Miller wrote:
> >> From: Al Viro <viro@ZenIV.linux.org.uk>
> >> Date: Sun, 9 Nov 2014 21:19:08 +0000
> >>
> >> > 1) does sparc64 access_ok() need to differ for 32bit and 64bit tasks?
> >>
> >> sparc64 will just fault no matter what kind of task it is.
> >>
> >> It is impossible for a user task to generate a reference to
> >> a kernel virtual address, as kernel and user accesses each
> >> go via a separate address space identifier.
> >
> > Sure, but why do we have access_ok() there at all? I.e. why not just have
> > it constant 1?
>
> Since access_ok() is in fact constant 1 on sparc64, where we use it,
> does it really matter?
*blink*
My apologies - I've got confused by the maze of twisty includes, all alike.
Right you are; in biarch case it *doesn't* depend on 32bit vs. 64bit.
STACK_TOP-using one is sparc32 variant where we obviously don't have
biarch at all.
Anyway, the series switching to {compat_,}rw_copy_check_uvector() and
getting rid of duplicate checks is in vfs.git#iov_iter-net. Warning:
it's almost completely untested. It survives boot, ssh into it and
runltp -f syscalls (no regressions), but that's about it. BTW, what's
the usual regression suite used for net/* stuff?
3 commits in there, on top of net-next#master; head should be at 555126.
There's a bunch of fairly obvious followups becoming possible after that,
but let's keep those separate...
^ permalink raw reply
* Re: [PATCH] brcmfmac: unlink URB when request timed out
From: Oliver Neukum @ 2014-11-10 9:08 UTC (permalink / raw)
To: Mathy Vanhoef
Cc: brudley, arend, frankyl, meuleman, linville, pieterpg,
linux-wireless, brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <545FAE05.2030701@gmail.com>
On Sun, 2014-11-09 at 13:10 -0500, Mathy Vanhoef wrote:
> From: Mathy Vanhoef <vanhoefm@gmail.com>
>
> Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
> assures the URB is never submitted twice, preventing a driver crash.
Hi,
I am afrad this patch is no good. The diagnosis is good,
but the fix introduces serious problems.
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> index 5265aa7..1bc7858 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
> @@ -738,10 +738,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info *devinfo, u8 cmd,
> goto finalize;
> }
>
> - if (!brcmf_usb_ioctl_resp_wait(devinfo))
> + if (!brcmf_usb_ioctl_resp_wait(devinfo)) {
> + usb_unlink_urb(devinfo->ctl_urb);
This is the asynchronous unlink. You have no guarantee it is finished
after this point.
> ret = -ETIMEDOUT;
> - else
> + } else {
> memcpy(buffer, tmpbuf, buflen);
> + }
>
> finalize:
> kfree(tmpbuf);
Which means that you are freeing memory that may still be used by DMA
at this time.
In addition you have no guarantee that the unlink is indeed finished
by the time the URB is reused.
If you wish to take this approach you better forget about this URB
and allocate a new one and free the buffer from the callback.
Regards
Oliver
--
Oliver Neukum <oneukum@suse.de>
^ permalink raw reply
* Re: [PATCH v4 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Roger Quadros @ 2014-11-10 9:00 UTC (permalink / raw)
To: Marc Kleine-Budde, wg
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev
In-Reply-To: <545CDD30.2070508@pengutronix.de>
On 11/07/2014 04:54 PM, Marc Kleine-Budde wrote:
> On 11/07/2014 03:49 PM, Roger Quadros wrote:
>> DRA7 CAN IP suffers from a problem which causes it to be prevented
>> from fully turning OFF (i.e. stuck in transition) if the module was
>> disabled while there was traffic on the CAN_RX line.
>>
>> To work around this issue we select the SLEEP pin state by default
>> on probe and use the DEFAULT pin state on CAN up and back to the
>> SLEEP pin state on CAN down.
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> drivers/net/can/c_can/c_can.c | 20 ++++++++++++++++++++
>> drivers/net/can/c_can/c_can.h | 1 +
>> drivers/net/can/c_can/c_can_platform.c | 20 ++++++++++++++++++++
>> 3 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
>> index 8e78bb4..4dfc3ce 100644
>> --- a/drivers/net/can/c_can/c_can.c
>> +++ b/drivers/net/can/c_can/c_can.c
>> @@ -35,6 +35,7 @@
>> #include <linux/list.h>
>> #include <linux/io.h>
>> #include <linux/pm_runtime.h>
>> +#include <linux/pinctrl/consumer.h>
>>
>> #include <linux/can.h>
>> #include <linux/can/dev.h>
>> @@ -603,6 +604,15 @@ static int c_can_start(struct net_device *dev)
>>
>> priv->can.state = CAN_STATE_ERROR_ACTIVE;
>>
>> + /* activate pins */
>> + if (!IS_ERR(priv->pinctrl)) {
>> + struct pinctrl_state *s;
>> +
>> + s = pinctrl_lookup_state(priv->pinctrl, PINCTRL_STATE_DEFAULT);
>> + if (!IS_ERR(s))
>> + pinctrl_select_state(priv->pinctrl, s);
>> + }
>
> Please put this common code into a seperate function.
Oops, forgot this one in a hurry.
cheers,
-roger
^ permalink raw reply
* Re: [patch net-next v2 10/10] rocker: implement L2 bridge offloading
From: Scott Feldman @ 2014-11-10 8:46 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman, Andy Gospodarek,
Thomas Graf, dborkman, ogerlitz, jesse, pshelar, azhou, ben,
stephen, Kirsher, Jeffrey T, vyasevic, xiyou.wangcong,
Fastabend, John R, edumazet, Florian Fainelli, Roopa Prabhu,
John Linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.ho
In-Reply-To: <546036A3.3010404@mojatatu.com>
On Sun, Nov 9, 2014 at 5:53 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> On 11/09/14 05:51, Jiri Pirko wrote:
>>
>> From: Scott Feldman <sfeldma@gmail.com>
>>
>> Add L2 bridge offloading support to rocker driver. Here, the Linux bridge
>> driver is used to collect swdev ports into a tagged (or untagged) VLAN
>> bridge. The swdev will offload from the bridge driver the following L2
>> bridging functions:
>>
>> - Learning of neighbor MAC addresses on VLAN X Learned mac/vlan is
>> installed in bridge FDB. (And removed when device unlearns mac/vlan).
>> Learning must be turned off on each bridge port to disable the feature in
>> the bridge driver.
>>
>
> I have quiet a few use cases where the above is a no-no. I dont want
> learning of any sort (we have a knob for that in the bridge).
> And i dont want learning in hardware to be reflected in software.
> Basically this is a policy decision. Introduce a knob to choose whether
> hardware learnt addresses should be reflected in software.
IFLA_BRPORT_LEARNING is u8 attr and we're only using lower bit to turn
learning on/off. Maybe we can use another bit to indicate learning to
be done in sw or hw. I don't think adding another bit would break
existing iproute2.
LEARNING_ENABLED (1 << 0)
LEARNING_HW (1 << 1)
Would this work?
>
>
> Have to run, but will comment when i get the time.
>
> cheers,
> jamal
>
^ permalink raw reply
* Re: [patch net-next v2 10/10] rocker: implement L2 bridge offloading
From: Jiri Pirko @ 2014-11-10 8:18 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <546036A3.3010404@mojatatu.com>
Mon, Nov 10, 2014 at 04:53:07AM CET, jhs@mojatatu.com wrote:
>On 11/09/14 05:51, Jiri Pirko wrote:
>>From: Scott Feldman <sfeldma@gmail.com>
>>
>>Add L2 bridge offloading support to rocker driver. Here, the Linux bridge
>>driver is used to collect swdev ports into a tagged (or untagged) VLAN
>>bridge. The swdev will offload from the bridge driver the following L2
>>bridging functions:
>>
>> - Learning of neighbor MAC addresses on VLAN X Learned mac/vlan is
>>installed in bridge FDB. (And removed when device unlearns mac/vlan).
>>Learning must be turned off on each bridge port to disable the feature in
>>the bridge driver.
>>
>
>I have quiet a few use cases where the above is a no-no. I dont want
>learning of any sort (we have a knob for that in the bridge).
I would love to see your code. Please do share.
>And i dont want learning in hardware to be reflected in software.
>Basically this is a policy decision. Introduce a knob to choose whether
>hardware learnt addresses should be reflected in software.
This can be easily done as a bridge option I believe. If you are ok with
that, I will add a patch (either in re-post or as a follow-up)
>
>
>Have to run, but will comment when i get the time.
>
>cheers,
>jamal
>
^ permalink raw reply
* Re: [patch net-next v2 06/10] bridge: introduce fdb offloading via switchdev
From: Jiri Pirko @ 2014-11-10 8:15 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <54603564.3070606@mojatatu.com>
Mon, Nov 10, 2014 at 04:47:48AM CET, jhs@mojatatu.com wrote:
>On 11/09/14 05:51, Jiri Pirko wrote:
>>From: Scott Feldman <sfeldma@gmail.com>
>>
>>Add two new ndos: ndo_sw_port_fdb_add/del to offload static bridge
>>fdb entries. Static bridge FDB entries are installed, for example,
>>using iproute2 bridge cmd:
>>
>> bridge fdb add ADDR dev DEV master vlan VID
>>
>>This would install ADDR into the bridge's FDB for port DEV on vlan VID. The
>>switch driver implements two ndo_swdev ops to add/delete FDB entries in the
>>switch device:
>>
>> int ndo_sw_port_fdb_add(struct net_device *dev,
>> const unsigned char *addr,
>> u16 vid);
>>
>> int ndo_sw_port_fdb_del(struct net_device *dev,
>> const unsigned char *addr,
>> u16 vid);
>>
>>The driver returns 0 on success, negative error code on failure.
>>
>>Note: the switch driver would not implement ndo_fdb_add/del/dump on a port
>>netdev as these are intended for devices maintaining their own FDB. In our
>>case, we want the Linux bridge to own the FBD.
>>
>>Note: by default, the bridge does not filter on VLAN and only bridges untagged
>>traffic. To enable VLAN support, turn on VLAN filtering:
>>
>> echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering
>>
>
>Sorry - why is the current fdb_add/del insufficient? It needs a vlanid
>and the master/self flags should indicate intent to add to h/w vs s/w.
Jamal, I believe we discussed this already. The thing is that current
fdb_add/del does not need vlanid and master/self flags, because it
already has that (struct nlattr *tb[]). Here is the whole list of
parameters to these functions:
NDA_DST,
NDA_LLADDR,
NDA_CACHEINFO,
NDA_PROBES,
NDA_VLAN,
NDA_PORT,
NDA_VNI,
NDA_IFINDEX,
NDA_MASTER,
There are few problems in re-using this. It is netlink based so for calling
it from bridge code, we would have to construct netlink message. But
that could be probably changed.
As you can see from the list of parameters, this is no longer about fdb (addr,
vlanid) but this has been extended to something else. See vxlan code for
what this is used for. I believe that fdb_add/del should be renamed to
something else, perhaps l2neigh_add/del or something like that.
The other problem is that fdb_add/del is currently used by various
drivers for different purpose (adding macs to unicast list).
Scott, you may probably want to add something to this.
>
>cheers,
>jamal
>
^ permalink raw reply
* Re: e100: Laptop battery drain and WoL settings from EEPROM
From: Ondrej Zary @ 2014-11-10 8:14 UTC (permalink / raw)
To: Francois Romieu; +Cc: e1000-devel, netdev, Kernel development list
In-Reply-To: <20141109233437.GA5037@electric-eye.fr.zoreil.com>
On Monday 10 November 2014, Francois Romieu wrote:
> Ondrej Zary <linux@rainbow-software.org> :
> [...]
>
> > > Looks like this laptop is probably WoL-capable even on battery.
> > >
> > > Measured the current from AC adapter:
> > > around 20mA with WoL inactive (shut down from Windows or by power
> > > button in GRUB) around 40mA with WoL active (shut down from Linux)
> > >
> > > So to work-around this problem, users must disable WoL manually on each
> > > boot.
>
> Or configure udev so that ethtool disables WoL.
This is inconsistent with other (non-Intel) ethernet drivers where users need
to use ethtool only if they want to enable WoL.
Installing ethtool and writing udev rules just to make a laptop shutdown
properly is not very user-friendly.
> The current policy has been here for ages. Some users may rely on it.
>
> There must be some strong rationale for their setup to have to be changed.
Yes, that might be a problem.
--
Ondrej Zary
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Face some error after applying commit 7dfa4b414d4(net/mlx4_en: Code cleanups in tx path)
From: Amir Vadai @ 2014-11-10 8:00 UTC (permalink / raw)
To: Wei Yang, Eric Dumazet; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <20141110054010.GA3224@richard>
On 11/10/2014 7:40 AM, Wei Yang wrote:
> On Sun, Nov 09, 2014 at 06:46:14PM -0800, Eric Dumazet wrote:
>> On Mon, 2014-11-10 at 09:59 +0800, Wei Yang wrote:
>>> On Fri, Nov 07, 2014 at 07:38:15PM -0800, Eric Dumazet wrote:
>>>> On Fri, Nov 7, 2014 at 6:57 PM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>>>>> Eric and Amir
>>>>>
[...]
>>>
>>
>> Okay, your message was not clear : I thought you had a compilation error
>> on current tree.
>>
>> The true story of these patches is that Mellanox split an initial big
>> chunk [1] I gave into multiple patches.
>>
>> Maybe they missed that one patch did not actually compile.
>>
>> [1] https://patchwork.ozlabs.org/patch/394256/
>>
>> Now, it is done, there is nothing we can do.
>>
>> I'll let Mellanox comment, but it looks like your hardware does not like
>> something.
>>
>> Have you tried to disable Blue Frame ?
>>
>
> Yep, looks the PF works fine. But the current FW I can't just enable the PF.
>
> How to disable Blue Frame? I am not clear about this.
>
Hi,
Lets see that we're on the same page here:
1. There was a compilation problem that you fixed (Yes, it was my fault
- I just discovered it a minute after the code was applied).
2. When you're using SR-IOV, during initialization, you get a CQE error
with syndrome 0x2 on one of the probed VF's.
3. Regarding the BlueFlame - I don't see how it is related to the issue
that you see. But it is a very easy experiment. Issue: "ethtool
--set-priv-flags eth1 blueflame off"
Please send me the module parameters you used when loading mlx4_core, a
full dmesg with both mlx4_core and mlx4_en loading.
Amir.
^ permalink raw reply
* Re: [patch net-next v2 03/10] rtnl: expose physical switch id for particular device
From: Jiri Pirko @ 2014-11-10 7:45 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <5460347E.6040000@mojatatu.com>
Mon, Nov 10, 2014 at 04:43:58AM CET, jhs@mojatatu.com wrote:
>On 11/09/14 05:51, Jiri Pirko wrote:
>>The netdevice represents a port in a switch, it will expose
>>IFLA_PHYS_SWITCH_ID value via rtnl. Two netdevices with the same value
>>belong to one physical switch.
>>
>>Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>---
>> include/uapi/linux/if_link.h | 1 +
>> net/core/rtnetlink.c | 26 +++++++++++++++++++++++++-
>> 2 files changed, 26 insertions(+), 1 deletion(-)
>>
>>diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>>index 7072d83..4163753 100644
>>--- a/include/uapi/linux/if_link.h
>>+++ b/include/uapi/linux/if_link.h
>>@@ -145,6 +145,7 @@ enum {
>> IFLA_CARRIER,
>> IFLA_PHYS_PORT_ID,
>> IFLA_CARRIER_CHANGES,
>>+ IFLA_PHYS_SWITCH_ID,
>> __IFLA_MAX
>> };
>>
>
>
>>@@ -1198,6 +1221,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
>> [IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
>> [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
>> [IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
>>+ [IFLA_PHYS_SWITCH_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
>> };
>>
>
>Ok, looking at this compared to #1 i can see you are introducing
>IFLA_PHYS_SWITCH_ID but then why did you need to change IFLA_PHYS_PORT_ID
>earlier?
I did not change it at all. I only made the name more generic. Please
look closer to the patch 1.
>
>cheers,
>jamal
>
>> static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
>>
>
^ permalink raw reply
* Re: [patch net-next v2 01/10] net: rename netdev_phys_port_id to more generic name
From: Jiri Pirko @ 2014-11-10 7:43 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <54603270.509@mojatatu.com>
Mon, Nov 10, 2014 at 04:35:12AM CET, jhs@mojatatu.com wrote:
>
>On 11/09/14 05:51, Jiri Pirko wrote:
>>So this can be reused for identification of other "items" as well.
>>
>
>
>
>
>>
>>diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
>>index 9dd0669..55dc4da 100644
>>--- a/net/core/net-sysfs.c
>>+++ b/net/core/net-sysfs.c
>>@@ -387,7 +387,7 @@ static ssize_t phys_port_id_show(struct device *dev,
>> return restart_syscall();
>>
>> if (dev_isalive(netdev)) {
>>- struct netdev_phys_port_id ppid;
>>+ struct netdev_phys_item_id ppid;
>>
>> ret = dev_get_phys_port_id(netdev, &ppid);
>> if (!ret)
>>diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>>index a688268..1087c6d 100644
>>--- a/net/core/rtnetlink.c
>>+++ b/net/core/rtnetlink.c
>>@@ -868,7 +868,7 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
>> + rtnl_port_size(dev, ext_filter_mask) /* IFLA_VF_PORTS + IFLA_PORT_SELF */
>> + rtnl_link_get_size(dev) /* IFLA_LINKINFO */
>> + rtnl_link_get_af_size(dev) /* IFLA_AF_SPEC */
>>- + nla_total_size(MAX_PHYS_PORT_ID_LEN); /* IFLA_PHYS_PORT_ID */
>>+ + nla_total_size(MAX_PHYS_ITEM_ID_LEN); /* IFLA_PHYS_PORT_ID */
>> }
>>
>
>[...]
>> static int rtnl_vf_ports_fill(struct sk_buff *skb, struct net_device *dev)
>>@@ -952,7 +952,7 @@ static int rtnl_port_fill(struct sk_buff *skb, struct net_device *dev,
>> static int rtnl_phys_port_id_fill(struct sk_buff *skb, struct net_device *dev)
>> {
>> int err;
>>- struct netdev_phys_port_id ppid;
>>+ struct netdev_phys_item_id ppid;
>>
>> err = dev_get_phys_port_id(dev, &ppid);
>> if (err) {
>>@@ -1196,7 +1196,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
>> [IFLA_PROMISCUITY] = { .type = NLA_U32 },
>> [IFLA_NUM_TX_QUEUES] = { .type = NLA_U32 },
>> [IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
>>- [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_PORT_ID_LEN },
>>+ [IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
>> [IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
>> };
>
>
>wouldnt this just break an existing ABI? You may need to introduce a new
>attribute.
I don't see a reason why this would break kabi:
-#define MAX_PHYS_PORT_ID_LEN 32
+#define MAX_PHYS_ITEM_ID_LEN 32
>
>cheers,
>jamal
>
>
^ permalink raw reply
* Re: [PATCH RFC net-next 0/5] *** Introduce 4 AD link speed ***
From: Jianhua Xie @ 2014-11-10 7:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141107.151918.371340447814973895.davem@davemloft.net>
Thanks a lot for the valuable comments.
New patches set is coming.
Best Regards,
Jianhua
在 2014年11月08日 04:19, David Miller 写道:
> From: Xie Jianhua <Jianhua.Xie@freescale.com>
> Date: Thu, 6 Nov 2014 19:52:47 +0800
>
>> From: Jianhua Xie <Jianhua.Xie@freescale.com>
>>
>> User Key bits in Port key of AD mode are yet not used. This series
>> expands speed type bits and shrinks unused user Key bits in AD mode
>> Port Key, introduces 4 AD link speed: 2.5G/20G/40G/56G, and fixes
>> aggregated link bandwidth calculation based on new link speed.
> I think you can compress patches #2 to #5 into one single patch.
^ permalink raw reply
* [PATCH v1 net-next 1/2] bonding: Expand speed type bits of the AD Port Key
From: Xie Jianhua @ 2014-11-10 7:16 UTC (permalink / raw)
To: netdev
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David S. Miller,
Jianhua Xie, Jianhua Xie
In-Reply-To: <1415603801-21285-1-git-send-email-Jianhua.Xie@freescale.com>
From: Jianhua Xie <Jianhua.Xie@freescale.com>
Port Key was determined as 16 bits according to the link speed,
duplex and user key (which is yet not supported), in which key
speed was 5 bits for 1Mbps/10Mbps/100Mbps/1Gbps/10Gbps as below:
--------------------------------------------------------------
Port key :| User key | Speed | Duplex|
--------------------------------------------------------------
16 6 1 0
This patch is expanding speed type from 5 bits to 9 bits for other
speed 2.5Gbps/20Gbps/40Gbps/56Gbps and shrinking user key from 10
bits to 6 bits. New Port Key looks like below:
--------------------------------------------------------------
Port key :| User key | Speed | Duplex|
--------------------------------------------------------------
16 10 1 0
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Jianhua Xie <jianhua.xie@freescale.com>
---
drivers/net/bonding/bond_3ad.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 2110215f..8e5ab5c 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -77,11 +77,11 @@
* --------------------------------------------------------------
* Port key : | User key | Speed | Duplex |
* --------------------------------------------------------------
- * 16 6 1 0
+ * 16 10 1 0
*/
#define AD_DUPLEX_KEY_BITS 0x1
-#define AD_SPEED_KEY_BITS 0x3E
-#define AD_USER_KEY_BITS 0xFFC0
+#define AD_SPEED_KEY_BITS 0x3FE
+#define AD_USER_KEY_BITS 0xFC00
#define AD_LINK_SPEED_BITMASK_1MBPS 0x1
#define AD_LINK_SPEED_BITMASK_10MBPS 0x2
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v1 net-next 0/2] bonding: Introduce 4 AD link speed
From: Xie Jianhua @ 2014-11-10 7:16 UTC (permalink / raw)
To: netdev
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David S. Miller,
Jianhua Xie
From: Jianhua Xie <Jianhua.Xie@freescale.com>
User Key bits in Port key of AD mode are yet not used. This series
expands speed type bits and shrinks unused user Key bits in AD mode
Port Key, introduces 4 AD link speed: 2.5G/20G/40G/56G, and fixes
aggregated link bandwidth calculation based on new link speed.
Jianhua Xie (2):
bonding: Expand speed type bits of the AD Port Key
bonding: Introduce 4 AD link speed to fix agg_bandwidth
drivers/net/bonding/bond_3ad.c | 44 ++++++++++++++++++++++++++++++++++++++----
1 file changed, 40 insertions(+), 4 deletions(-)
--
Changes in v1:
* Compress RFC patches #2 to #5 into one single patch.
* Fix inexact commit information.
2.1.0.27.g96db324
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: David Miller @ 2014-11-10 7:30 UTC (permalink / raw)
To: viro; +Cc: herbert, netdev, linux-kernel, bcrl, mst
In-Reply-To: <20141110065817.GG7996@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Mon, 10 Nov 2014 06:58:17 +0000
> On Mon, Nov 10, 2014 at 12:20:20AM -0500, David Miller wrote:
>> From: Al Viro <viro@ZenIV.linux.org.uk>
>> Date: Sun, 9 Nov 2014 21:19:08 +0000
>>
>> > 1) does sparc64 access_ok() need to differ for 32bit and 64bit tasks?
>>
>> sparc64 will just fault no matter what kind of task it is.
>>
>> It is impossible for a user task to generate a reference to
>> a kernel virtual address, as kernel and user accesses each
>> go via a separate address space identifier.
>
> Sure, but why do we have access_ok() there at all? I.e. why not just have
> it constant 1?
Since access_ok() is in fact constant 1 on sparc64, where we use it,
does it really matter?
^ permalink raw reply
* Re: [patch net-next v2 00/10] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Jiri Pirko @ 2014-11-10 7:23 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <5460319B.2010605@mojatatu.com>
Mon, Nov 10, 2014 at 04:31:39AM CET, jhs@mojatatu.com wrote:
>Jiri,
>
>I am hoping you have considered what Ben Lahaise's, John Fastabend's,
>and Roopa's patches after all those discussions and
>meetings we have had (in which you promised you will merge patches
>in). I am not seeing much of that here or mention of anything of that
>sort.
Hi Jamal.
Yes I looked over their patches. Roopas patche's are about new class of
device which, as I commented in the cover letter, I left out for now and
can be safely added later on.
I went over the Ben's work very carefully as well. The patches are very
rough, mostly rtl-chip specific. But again, my patchset is a base on
which this patches can be build on. I see no issues in that.
>At least please get their sign on - this is such an important piece of
>new work that you should make sure you get consensus.
Since I did not use their code now, I only put sign off of Scott.
>Otherwise we are back to square one and everyone is going their way with
>their patches;
I do think that we are in sync. I do not see any counter ways. As I
said, their work can be added on to the base made of this patchset.
>
>Ben/Roopa/John - please issue either a signed-off as well
>if you agree with this approach otherwise i am hoping none of these
>patches are merged in.
>
>I will look at the patches and comment.
>
>cheers,
>jamal
>
>On 11/09/14 05:51, Jiri Pirko wrote:
>>Hi all.
>>
>>This patchset is just the first phase of switch and switch-ish device
>>support api in kernel. Note that the api will extend (our complete work
>>can be pulled from https://github.com/jpirko/net-next-rocker).
>>
>>So what this patchset includes:
>>- introduce switchdev api for implementing switch drivers (so far
>> only linux bridge fdb offload is covered)
>>- introduce rocker switch driver which implements switchdev api
>>
>>As to the discussion if there is need to have specific class of device
>>representing the switch itself, so far we found no need to introduce that.
>>But we are generally ok with the idea and when the time comes and it will
>>be needed, it can be easily introduced without any disturbance.
>>
>>This patchset introduces switch id export through rtnetlink and sysfs,
>>which is similar to what we have for port id in SR-IOV. I will send iproute2
>>patchset for showing the switch id for port netdevs once this is applied.
>>
>>For detailed description, please see individual patches.
>>
>>v1->v2:
>>- addressed all DaveM's comments
>>
>>Jiri Pirko (5):
>> net: rename netdev_phys_port_id to more generic name
>> net: introduce generic switch devices support
>> rtnl: expose physical switch id for particular device
>> net-sysfs: expose physical switch id for particular device
>> rocker: introduce rocker switch driver
>>
>>Scott Feldman (5):
>> bridge: introduce fdb offloading via switchdev
>> bridge: call netdev_sw_port_stp_update when bridge port STP status
>> changes
>> bridge: add API to notify bridge driver of learned FBD on offloaded
>> device
>> rocker: implement rocker ofdpa flow table manipulation
>> rocker: implement L2 bridge offloading
>>
>> Documentation/networking/switchdev.txt | 59 +
>> MAINTAINERS | 14 +
>> drivers/net/ethernet/Kconfig | 1 +
>> drivers/net/ethernet/Makefile | 1 +
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
>> drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
>> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 2 +-
>> drivers/net/ethernet/rocker/Kconfig | 27 +
>> drivers/net/ethernet/rocker/Makefile | 5 +
>> drivers/net/ethernet/rocker/rocker.c | 4182 ++++++++++++++++++++++
>> drivers/net/ethernet/rocker/rocker.h | 427 +++
>> include/linux/if_bridge.h | 18 +
>> include/linux/netdevice.h | 48 +-
>> include/net/switchdev.h | 53 +
>> include/uapi/linux/if_link.h | 1 +
>> net/Kconfig | 1 +
>> net/Makefile | 3 +
>> net/bridge/br_fdb.c | 94 +-
>> net/bridge/br_netlink.c | 2 +
>> net/bridge/br_stp.c | 4 +
>> net/bridge/br_stp_if.c | 3 +
>> net/bridge/br_stp_timer.c | 2 +
>> net/core/dev.c | 2 +-
>> net/core/net-sysfs.c | 26 +-
>> net/core/rtnetlink.c | 30 +-
>> net/switchdev/Kconfig | 13 +
>> net/switchdev/Makefile | 5 +
>> net/switchdev/switchdev.c | 93 +
>> 29 files changed, 5104 insertions(+), 18 deletions(-)
>> create mode 100644 Documentation/networking/switchdev.txt
>> create mode 100644 drivers/net/ethernet/rocker/Kconfig
>> create mode 100644 drivers/net/ethernet/rocker/Makefile
>> create mode 100644 drivers/net/ethernet/rocker/rocker.c
>> create mode 100644 drivers/net/ethernet/rocker/rocker.h
>> create mode 100644 include/net/switchdev.h
>> create mode 100644 net/switchdev/Kconfig
>> create mode 100644 net/switchdev/Makefile
>> create mode 100644 net/switchdev/switchdev.c
>>
>
^ permalink raw reply
* [PATCH v1 net-next 2/2] bonding: Introduce 4 AD link speed to fix agg_bandwidth
From: Xie Jianhua @ 2014-11-10 7:16 UTC (permalink / raw)
To: netdev
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David S. Miller,
Jianhua Xie, Jianhua Xie
In-Reply-To: <1415603801-21285-1-git-send-email-Jianhua.Xie@freescale.com>
From: Jianhua Xie <Jianhua.Xie@freescale.com>
This patch adds 2.5Gbps/20Gbps/40Gbps/56Gbps bitmask micros, and
fixes aggregated bandwidth calculation based on 2.5Gbps/20Gbps/
40Gbps/56Gbps slave links.
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Jianhua Xie <jianhua.xie@freescale.com>
---
drivers/net/bonding/bond_3ad.c | 38 +++++++++++++++++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 8e5ab5c..ee4fe05 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -87,7 +87,11 @@
#define AD_LINK_SPEED_BITMASK_10MBPS 0x2
#define AD_LINK_SPEED_BITMASK_100MBPS 0x4
#define AD_LINK_SPEED_BITMASK_1000MBPS 0x8
-#define AD_LINK_SPEED_BITMASK_10000MBPS 0x10
+#define AD_LINK_SPEED_BITMASK_2500MBPS 0x10
+#define AD_LINK_SPEED_BITMASK_10000MBPS 0x20
+#define AD_LINK_SPEED_BITMASK_20000MBPS 0x40
+#define AD_LINK_SPEED_BITMASK_40000MBPS 0x80
+#define AD_LINK_SPEED_BITMASK_56000MBPS 0x100
/* compare MAC addresses */
#define MAC_ADDRESS_EQUAL(A, B) \
@@ -245,7 +249,11 @@ static inline int __check_agg_selection_timer(struct port *port)
* %AD_LINK_SPEED_BITMASK_10MBPS,
* %AD_LINK_SPEED_BITMASK_100MBPS,
* %AD_LINK_SPEED_BITMASK_1000MBPS,
+ * %AD_LINK_SPEED_BITMASK_2500MBPS,
* %AD_LINK_SPEED_BITMASK_10000MBPS
+ * %AD_LINK_SPEED_BITMASK_20000MBPS
+ * %AD_LINK_SPEED_BITMASK_40000MBPS
+ * %AD_LINK_SPEED_BITMASK_56000MBPS
*/
static u16 __get_link_speed(struct port *port)
{
@@ -273,10 +281,26 @@ static u16 __get_link_speed(struct port *port)
speed = AD_LINK_SPEED_BITMASK_1000MBPS;
break;
+ case SPEED_2500:
+ speed = AD_LINK_SPEED_BITMASK_2500MBPS;
+ break;
+
case SPEED_10000:
speed = AD_LINK_SPEED_BITMASK_10000MBPS;
break;
+ case SPEED_20000:
+ speed = AD_LINK_SPEED_BITMASK_20000MBPS;
+ break;
+
+ case SPEED_40000:
+ speed = AD_LINK_SPEED_BITMASK_40000MBPS;
+ break;
+
+ case SPEED_56000:
+ speed = AD_LINK_SPEED_BITMASK_56000MBPS;
+ break;
+
default:
/* unknown speed value from ethtool. shouldn't happen */
speed = 0;
@@ -637,9 +661,21 @@ static u32 __get_agg_bandwidth(struct aggregator *aggregator)
case AD_LINK_SPEED_BITMASK_1000MBPS:
bandwidth = aggregator->num_of_ports * 1000;
break;
+ case AD_LINK_SPEED_BITMASK_2500MBPS:
+ bandwidth = aggregator->num_of_ports * 2500;
+ break;
case AD_LINK_SPEED_BITMASK_10000MBPS:
bandwidth = aggregator->num_of_ports * 10000;
break;
+ case AD_LINK_SPEED_BITMASK_20000MBPS:
+ bandwidth = aggregator->num_of_ports * 20000;
+ break;
+ case AD_LINK_SPEED_BITMASK_40000MBPS:
+ bandwidth = aggregator->num_of_ports * 40000;
+ break;
+ case AD_LINK_SPEED_BITMASK_56000MBPS:
+ bandwidth = aggregator->num_of_ports * 56000;
+ break;
default:
bandwidth = 0; /* to silence the compiler */
}
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-10 6:58 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, linux-kernel, bcrl, mst
In-Reply-To: <20141110.002020.1062493586889118565.davem@davemloft.net>
On Mon, Nov 10, 2014 at 12:20:20AM -0500, David Miller wrote:
> From: Al Viro <viro@ZenIV.linux.org.uk>
> Date: Sun, 9 Nov 2014 21:19:08 +0000
>
> > 1) does sparc64 access_ok() need to differ for 32bit and 64bit tasks?
>
> sparc64 will just fault no matter what kind of task it is.
>
> It is impossible for a user task to generate a reference to
> a kernel virtual address, as kernel and user accesses each
> go via a separate address space identifier.
Sure, but why do we have access_ok() there at all? I.e. why not just have
it constant 1?
^ 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