* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Arnd Bergmann @ 2017-01-11 20:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, David S. Miller, Networking, linux-kernel
In-Reply-To: <1484147177.29931.14.camel@sipsolutions.net>
On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote:
>
> Applied. Also fixed the typo in the subject :)
Thanks! Unfortunately I now got another warning for the same function,
and though I would have expected the patch to fix it, that did not work:
In file included from /git/arm-soc/drivers/net/wireless/intersil/prism54/islpci_dev.h:27:0,
from /git/arm-soc/drivers/net/wireless/intersil/prism54/isl_ioctl.h:24,
from /git/arm-soc/drivers/net/wireless/intersil/prism54/isl_ioctl.c:32:
/git/arm-soc/drivers/net/wireless/intersil/prism54/isl_ioctl.c: In function 'prism54_get_scan':
/git/arm-soc/include/net/iw_handler.h:560:4: error: argument 2 null where non-null expected [-Werror=nonnull]
memcpy(stream + point_len, extra, iwe->u.data.length);
The change below kills that warning too, but it gets even uglier there:
diff --git a/include/net/iw_handler.h b/include/net/iw_handler.h
index 1a41043688bc..c2aa73e5e6bb 100644
--- a/include/net/iw_handler.h
+++ b/include/net/iw_handler.h
@@ -556,7 +556,7 @@ iwe_stream_add_point(struct iw_request_info *info, char *stream, char *ends,
memcpy(stream + lcp_len,
((char *) &iwe->u) + IW_EV_POINT_OFF,
IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
- if (iwe->u.data.length)
+ if (iwe->u.data.length && extra)
memcpy(stream + point_len, extra, iwe->u.data.length);
stream += event_len;
}
Let me know if you want a proper follow-up patch, or if you can amend your
commit, or you have a better idea for resolving that warning.
Arnd
^ permalink raw reply related
* Re: TCP using IPv4-mapped IPv6 address as source
From: Eric Dumazet @ 2017-01-11 20:43 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: Jonathan T. Leighton, netdev, edumazet, Yuchung Cheng,
Neal Cardwell
In-Reply-To: <20170111195909.GL24086@oracle.com>
On Wed, 2017-01-11 at 14:59 -0500, Sowmini Varadhan wrote:
> I think the RFC states somewhere that you should never ever
> send out a v4 mapped address on the wire.
Can you point the exact RFC ?
https://tools.ietf.org/html/rfc2765 seems to allow just that.
Jonathan issue is about terminating such flows in TCP stack, which is
likely not needed/useful.
^ permalink raw reply
* Re: TCP using IPv4-mapped IPv6 address as source
From: Sowmini Varadhan @ 2017-01-11 20:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jonathan T. Leighton, netdev, edumazet, Yuchung Cheng,
Neal Cardwell
In-Reply-To: <1484167422.15816.1.camel@edumazet-glaptop3.roam.corp.google.com>
On (01/11/17 12:43), Eric Dumazet wrote:
>
> On Wed, 2017-01-11 at 14:59 -0500, Sowmini Varadhan wrote:
>
> > I think the RFC states somewhere that you should never ever
> > send out a v4 mapped address on the wire.
>
> Can you point the exact RFC ?
>
> https://tools.ietf.org/html/rfc2765 seems to allow just that.
I have not read the details of 2765, but from a cursory look,
it talks about "IPv4-translatable addresses", not v4-mapped
addrs, and says,
"The address translation mechanisms for the stateless and the stateful
translations are defined in [RFC6052]"
It's also not clear to me that 2765 warrants the use of these
as ip6 src, or ip6 dst, or the target(s) of NS/NA.
https://www.rfc-editor.org/rfc/rfc4038.txt refers to security
considerations about sending v4-mapped addrs on the wire
Looks like these security considerations are discussed in
https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
In general, I think BSD and Solaris (and probably most
router implementations, esp the BSD-based ones) will not allow
v4 mapped addresses as src or dst of ip6 packets.
> Jonathan issue is about terminating such flows in TCP stack, which is
> likely not needed/useful.
sure. but if you configure the v4 mapped address as
a src addr "everything should be fine!"
--Sowmini
^ permalink raw reply
* [PATCH net-next 0/3] net: mdio-gpio: Use modern GPIO helpers
From: Florian Fainelli @ 2017-01-11 20:59 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, cphealy, linux, Florian Fainelli
Hi David,
This patch series modernizes the mdio-gpio and makes it switch to the
latest and greatest API for manipulating GPIO lines, thus allowing
some simplifications in the driver.
Thanks!
Guenter Roeck (3):
net: mdio-gpio: Use devm_gpio_request_one instead of devm_gpio_request
net: mdio-gpio: Convert to use gpiod functions where possible
net: mdio-gpio: Use gpio subsystem to handle low-active pins
drivers/net/phy/mdio-gpio.c | 60 ++++++++++++++++++++++-----------------------
1 file changed, 30 insertions(+), 30 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH net-next 1/3] net: mdio-gpio: Use devm_gpio_request_one instead of devm_gpio_request
From: Florian Fainelli @ 2017-01-11 20:59 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, cphealy, linux, Florian Fainelli
In-Reply-To: <20170111205951.32363-1-f.fainelli@gmail.com>
From: Guenter Roeck <linux@roeck-us.net>
Using devm_gpio_request_one lets us request gpio pins with initial state
in one go.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/mdio-gpio.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 27ab63064f95..f6e773256c82 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -137,6 +137,9 @@ static struct mii_bus *mdio_gpio_bus_init(struct device *dev,
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
int i;
+ unsigned long mdc_flags = GPIOF_OUT_INIT_LOW;
+ unsigned long mdio_flags = GPIOF_DIR_IN;
+ unsigned long mdo_flags = GPIOF_OUT_INIT_HIGH;
bitbang = devm_kzalloc(dev, sizeof(*bitbang), GFP_KERNEL);
if (!bitbang)
@@ -174,21 +177,17 @@ static struct mii_bus *mdio_gpio_bus_init(struct device *dev,
else
strncpy(new_bus->id, "gpio", MII_BUS_ID_SIZE);
- if (devm_gpio_request(dev, bitbang->mdc, "mdc"))
+ if (devm_gpio_request_one(dev, bitbang->mdc, mdc_flags, "mdc"))
goto out_free_bus;
- if (devm_gpio_request(dev, bitbang->mdio, "mdio"))
+ if (devm_gpio_request_one(dev, bitbang->mdio, mdio_flags, "mdio"))
goto out_free_bus;
if (bitbang->mdo) {
- if (devm_gpio_request(dev, bitbang->mdo, "mdo"))
+ if (devm_gpio_request_one(dev, bitbang->mdo, mdo_flags, "mdo"))
goto out_free_bus;
- gpio_direction_output(bitbang->mdo, 1);
- gpio_direction_input(bitbang->mdio);
}
- gpio_direction_output(bitbang->mdc, 0);
-
dev_set_drvdata(dev, new_bus);
return new_bus;
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 2/3] net: mdio-gpio: Convert to use gpiod functions where possible
From: Florian Fainelli @ 2017-01-11 20:59 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, cphealy, linux, Florian Fainelli
In-Reply-To: <20170111205951.32363-1-f.fainelli@gmail.com>
From: Guenter Roeck <linux@roeck-us.net>
Using gpiod functions lets us use functionality which is not available
with gpio functions.
There is no gpiod function to match devm_gpio_request_one, so leave it
in place and use gpio_to_desc() to convert absolute pin numbers to gpio
descriptors.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/mdio-gpio.c | 43 +++++++++++++++++++++----------------------
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index f6e773256c82..e62fcea2d945 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -32,7 +32,7 @@
struct mdio_gpio_info {
struct mdiobb_ctrl ctrl;
- int mdc, mdio, mdo;
+ struct gpio_desc *mdc, *mdio, *mdo;
int mdc_active_low, mdio_active_low, mdo_active_low;
};
@@ -80,16 +80,15 @@ static void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
* assume the pin serves as pull-up. If direction is
* output, the default value is high.
*/
- gpio_set_value_cansleep(bitbang->mdo,
- 1 ^ bitbang->mdo_active_low);
+ gpiod_set_value(bitbang->mdo, 1 ^ bitbang->mdo_active_low);
return;
}
if (dir)
- gpio_direction_output(bitbang->mdio,
- 1 ^ bitbang->mdio_active_low);
+ gpiod_direction_output(bitbang->mdio,
+ 1 ^ bitbang->mdio_active_low);
else
- gpio_direction_input(bitbang->mdio);
+ gpiod_direction_input(bitbang->mdio);
}
static int mdio_get(struct mdiobb_ctrl *ctrl)
@@ -97,8 +96,7 @@ static int mdio_get(struct mdiobb_ctrl *ctrl)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- return gpio_get_value_cansleep(bitbang->mdio) ^
- bitbang->mdio_active_low;
+ return gpiod_get_value(bitbang->mdio) ^ bitbang->mdio_active_low;
}
static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
@@ -107,11 +105,9 @@ static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
container_of(ctrl, struct mdio_gpio_info, ctrl);
if (bitbang->mdo)
- gpio_set_value_cansleep(bitbang->mdo,
- what ^ bitbang->mdo_active_low);
+ gpiod_set_value(bitbang->mdo, what ^ bitbang->mdo_active_low);
else
- gpio_set_value_cansleep(bitbang->mdio,
- what ^ bitbang->mdio_active_low);
+ gpiod_set_value(bitbang->mdio, what ^ bitbang->mdio_active_low);
}
static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
@@ -119,7 +115,7 @@ static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- gpio_set_value_cansleep(bitbang->mdc, what ^ bitbang->mdc_active_low);
+ gpiod_set_value(bitbang->mdc, what ^ bitbang->mdc_active_low);
}
static struct mdiobb_ops mdio_gpio_ops = {
@@ -137,6 +133,7 @@ static struct mii_bus *mdio_gpio_bus_init(struct device *dev,
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
int i;
+ int mdc, mdio, mdo;
unsigned long mdc_flags = GPIOF_OUT_INIT_LOW;
unsigned long mdio_flags = GPIOF_DIR_IN;
unsigned long mdo_flags = GPIOF_OUT_INIT_HIGH;
@@ -147,11 +144,15 @@ static struct mii_bus *mdio_gpio_bus_init(struct device *dev,
bitbang->ctrl.ops = &mdio_gpio_ops;
bitbang->ctrl.reset = pdata->reset;
- bitbang->mdc = pdata->mdc;
+ mdc = pdata->mdc;
+ bitbang->mdc = gpio_to_desc(mdc);
bitbang->mdc_active_low = pdata->mdc_active_low;
- bitbang->mdio = pdata->mdio;
+ mdio = pdata->mdio;
+ bitbang->mdio = gpio_to_desc(mdio);
bitbang->mdio_active_low = pdata->mdio_active_low;
- bitbang->mdo = pdata->mdo;
+ mdo = pdata->mdo;
+ if (mdo)
+ bitbang->mdo = gpio_to_desc(mdo);
bitbang->mdo_active_low = pdata->mdo_active_low;
new_bus = alloc_mdio_bitbang(&bitbang->ctrl);
@@ -177,16 +178,14 @@ static struct mii_bus *mdio_gpio_bus_init(struct device *dev,
else
strncpy(new_bus->id, "gpio", MII_BUS_ID_SIZE);
- if (devm_gpio_request_one(dev, bitbang->mdc, mdc_flags, "mdc"))
+ if (devm_gpio_request_one(dev, mdc, mdc_flags, "mdc"))
goto out_free_bus;
- if (devm_gpio_request_one(dev, bitbang->mdio, mdio_flags, "mdio"))
+ if (devm_gpio_request_one(dev, mdio, mdio_flags, "mdio"))
goto out_free_bus;
- if (bitbang->mdo) {
- if (devm_gpio_request_one(dev, bitbang->mdo, mdo_flags, "mdo"))
- goto out_free_bus;
- }
+ if (mdo && devm_gpio_request_one(dev, mdo, mdo_flags, "mdo"))
+ goto out_free_bus;
dev_set_drvdata(dev, new_bus);
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 3/3] net: mdio-gpio: Use gpio subsystem to handle low-active pins
From: Florian Fainelli @ 2017-01-11 20:59 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, cphealy, linux, Florian Fainelli
In-Reply-To: <20170111205951.32363-1-f.fainelli@gmail.com>
From: Guenter Roeck <linux@roeck-us.net>
gpiod functions support handling low-active pins, so we can move
thos code out of this driver into the gpio subsystem and simplify
the code a bit.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/mdio-gpio.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index e62fcea2d945..7faa79b254ef 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -33,7 +33,6 @@
struct mdio_gpio_info {
struct mdiobb_ctrl ctrl;
struct gpio_desc *mdc, *mdio, *mdo;
- int mdc_active_low, mdio_active_low, mdo_active_low;
};
static void *mdio_gpio_of_get_data(struct platform_device *pdev)
@@ -80,13 +79,12 @@ static void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
* assume the pin serves as pull-up. If direction is
* output, the default value is high.
*/
- gpiod_set_value(bitbang->mdo, 1 ^ bitbang->mdo_active_low);
+ gpiod_set_value(bitbang->mdo, 1);
return;
}
if (dir)
- gpiod_direction_output(bitbang->mdio,
- 1 ^ bitbang->mdio_active_low);
+ gpiod_direction_output(bitbang->mdio, 1);
else
gpiod_direction_input(bitbang->mdio);
}
@@ -96,7 +94,7 @@ static int mdio_get(struct mdiobb_ctrl *ctrl)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- return gpiod_get_value(bitbang->mdio) ^ bitbang->mdio_active_low;
+ return gpiod_get_value(bitbang->mdio);
}
static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
@@ -105,9 +103,9 @@ static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
container_of(ctrl, struct mdio_gpio_info, ctrl);
if (bitbang->mdo)
- gpiod_set_value(bitbang->mdo, what ^ bitbang->mdo_active_low);
+ gpiod_set_value(bitbang->mdo, what);
else
- gpiod_set_value(bitbang->mdio, what ^ bitbang->mdio_active_low);
+ gpiod_set_value(bitbang->mdio, what);
}
static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
@@ -115,7 +113,7 @@ static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- gpiod_set_value(bitbang->mdc, what ^ bitbang->mdc_active_low);
+ gpiod_set_value(bitbang->mdc, what);
}
static struct mdiobb_ops mdio_gpio_ops = {
@@ -146,14 +144,18 @@ static struct mii_bus *mdio_gpio_bus_init(struct device *dev,
bitbang->ctrl.reset = pdata->reset;
mdc = pdata->mdc;
bitbang->mdc = gpio_to_desc(mdc);
- bitbang->mdc_active_low = pdata->mdc_active_low;
+ if (pdata->mdc_active_low)
+ mdc_flags = GPIOF_OUT_INIT_HIGH | GPIOF_ACTIVE_LOW;
mdio = pdata->mdio;
bitbang->mdio = gpio_to_desc(mdio);
- bitbang->mdio_active_low = pdata->mdio_active_low;
+ if (pdata->mdio_active_low)
+ mdio_flags |= GPIOF_ACTIVE_LOW;
mdo = pdata->mdo;
- if (mdo)
+ if (mdo) {
bitbang->mdo = gpio_to_desc(mdo);
- bitbang->mdo_active_low = pdata->mdo_active_low;
+ if (pdata->mdo_active_low)
+ mdo_flags = GPIOF_OUT_INIT_LOW | GPIOF_ACTIVE_LOW;
+ }
new_bus = alloc_mdio_bitbang(&bitbang->ctrl);
if (!new_bus)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net] r8152: fix the sw rx checksum is unavailable
From: David Miller @ 2017-01-11 21:09 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-232-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 11 Jan 2017 16:25:34 +0800
> Fix the hw rx checksum is always enabled, and the user couldn't switch
> it to sw rx checksum.
>
> Note that the RTL_VER_01 only support sw rx checksum only. Besides,
> the hw rx checksum for RTL_VER_02 is disabled after
> commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2] vxlan: Set ports in flow key when doing route lookups
From: David Miller @ 2017-01-11 21:10 UTC (permalink / raw)
To: martynas; +Cc: netdev
In-Reply-To: <20170111151853.4794-1-martynas@weave.works>
From: Martynas Pumputis <martynas@weave.works>
Date: Wed, 11 Jan 2017 15:18:53 +0000
> Otherwise, a xfrm policy with sport/dport being set cannot be matched.
>
> Signed-off-by: Martynas Pumputis <martynas@weave.works>
> ---
> Changes in v2:
> - Set the source port in the flow key.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: thunderx: Fix error return code in nicvf_open()
From: David Miller @ 2017-01-11 21:12 UTC (permalink / raw)
To: weiyj.lk; +Cc: weiyongjun1, sgoutham, rric, linux-arm-kernel, netdev
In-Reply-To: <20170111163251.19367-1-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 11 Jan 2017 16:32:51 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 712c31853440 ("net: thunderx: Program LMAC credits based on MTU")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sfc: efx_get_phys_port_id() can be static
From: David Miller @ 2017-01-11 21:12 UTC (permalink / raw)
To: weiyj.lk; +Cc: linux-net-drivers, ecree, bkenward, weiyongjun1, netdev
In-Reply-To: <20170111161612.14384-1-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 11 Jan 2017 16:16:12 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/net/ethernet/sfc/efx.c:2337:5: warning:
> symbol 'efx_get_phys_port_id' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] net: thunderx: Make hfunc variable const type in nicvf_set_rxfh()
From: David Miller @ 2017-01-11 21:13 UTC (permalink / raw)
To: rrichter; +Cc: sgoutham, rric, netdev
In-Reply-To: <20170111170432.31210-1-rrichter@cavium.com>
From: Robert Richter <rrichter@cavium.com>
Date: Wed, 11 Jan 2017 18:04:32 +0100
> From struct ethtool_ops:
>
> int (*set_rxfh)(struct net_device *, const u32 *indir,
> const u8 *key, const u8 hfunc);
>
> Change function arg of hfunc to const type.
>
> V2: Fixed indentation.
>
> Signed-off-by: Robert Richter <rrichter@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: Florian Fainelli @ 2017-01-11 21:14 UTC (permalink / raw)
To: Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <c74e6665ca14a4ca03b38cd3442ef0644d9e250d.1484059674.git.jpinto@synopsys.com>
On 01/10/2017 06:52 AM, Joao Pinto wrote:
> This patch renames stmicro/stmmac to synopsys/ since it is a standard
> ethernet software package regarding synopsys ethernet controllers, supporting
> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
> retro-compatibility, only the description was changed.
Do re really have to do this? ST Micro were the first to upstream
support for a Synopsys IP, and it was later on identified as being
"stmicro" instead of "synopsys" (during the big driver move under
drivers/net/ethernet) whichever came first in the driver essentially "wins".
As mentioned before, although git is able to track renames, git log does
not automatically have --follow, so it can be hard for people to track
down the (new) history of the driver.
Personally, I don't see much value in doing this rename, especially when
all the driver internal structures are still going to be named with
stmmac (and please don't even think about doing a s/stmmac/snps/ inside
the driver ;)).
My 2 cents.
--
Florian
^ permalink raw reply
* [PATCH] [net] net/mlx5e: fix another -Wmaybe-uninitialized warning
From: Arnd Bergmann @ 2017-01-11 21:14 UTC (permalink / raw)
To: Saeed Mahameed, Hadar Hen Zion
Cc: Or Gerlitz, David S . Miller, netdev, linux-kernel, Arnd Bergmann
As found by Olof's build bot, today's mainline kernel gained a harmless
warning about a potential uninitalied variable reference:
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function 'parse_tc_fdb_actions':
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:769:13: warning: 'out_dev' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:811:21: note: 'out_dev' was declared here
This was introduced through the addition of an 'IS_ERR/PTR_ERR' pair that
gcc is unfortunately unable to completely figure out. Replacing it with
PTR_ERR_OR_ZERO makes the code more understandable to gcc so it no longer
warns.
Hadar Hen Zion already attempted to fix the warning earlier by adding
fake initializations, but that ended up just making the code worse without
fully addressing all warnings, so I'm reverting it now that it is no longer
needed.
In order to avoid pulling a variable declaration into the #ifdef, I'm
removing it in favor of a more readable 'if()' statement here that
has the same effect.
Link: http://arm-soc.lixom.net/buildlogs/mainline/v4.10-rc3-98-gcff3b2c/
Fixes: a42485eb0ee4 ("net/mlx5e: TC ipv4 tunnel encap offload error flow fixes")
Fixes: a757d108dc1a ("net/mlx5e: Fix kbuild warnings for uninitialized parameters")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 118cea5..07d83835 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -666,14 +666,15 @@ static int mlx5e_route_lookup_ipv4(struct mlx5e_priv *priv,
struct rtable *rt;
struct neighbour *n = NULL;
int ttl;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_INET))
+ return -EOPNOTSUPP;
-#if IS_ENABLED(CONFIG_INET)
rt = ip_route_output_key(dev_net(mirred_dev), fl4);
- if (IS_ERR(rt))
- return PTR_ERR(rt);
-#else
- return -EOPNOTSUPP;
-#endif
+ ret = PTR_ERR_OR_ZERO(rt);
+ if (ret)
+ return ret;
if (!switchdev_port_same_parent_id(priv->netdev, rt->dst.dev)) {
pr_warn("%s: can't offload, devices not on same HW e-switch\n", __func__);
@@ -741,8 +742,8 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
struct flowi4 fl4 = {};
char *encap_header;
int encap_size;
- __be32 saddr = 0;
- int ttl = 0;
+ __be32 saddr;
+ int ttl;
int err;
encap_header = kzalloc(max_encap_size, GFP_KERNEL);
--
2.9.0
^ permalink raw reply related
* Re: TCP using IPv4-mapped IPv6 address as source
From: Jonathan T. Leighton @ 2017-01-11 21:26 UTC (permalink / raw)
To: Eric Dumazet, Sowmini Varadhan
Cc: netdev, edumazet, Yuchung Cheng, Neal Cardwell
In-Reply-To: <1484167422.15816.1.camel@edumazet-glaptop3.roam.corp.google.com>
On 1/11/17 3:43 PM, Eric Dumazet wrote:
> On Wed, 2017-01-11 at 14:59 -0500, Sowmini Varadhan wrote:
>
>> I think the RFC states somewhere that you should never ever
>> send out a v4 mapped address on the wire.
> Can you point the exact RFC ?
>
> https://tools.ietf.org/html/rfc2765 seems to allow just that.
Link was in my original post. See table 20:
https://tools.ietf.org/html/rfc6890#page-14
> Jonathan issue is about terminating such flows in TCP stack, which is
> likely not needed/useful.
I'm sure I understand what you're saying here. There should be no flow
to terminate.
>
>
>
>
^ permalink raw reply
* Re: [PATCH net v2] netvsc: add rcu_read locking to netvsc callback
From: David Miller @ 2017-01-11 21:31 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20170111171632.31241-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 11 Jan 2017 09:16:32 -0800
> The receive callback (in tasklet context) is using RCU to get reference
> to associated VF network device but this is not safe. RCU read lock
> needs to be held. Found by running with full lockdep debugging
> enabled.
>
> Fixes: f207c10d9823 ("hv_netvsc: use RCU to protect vf_netdev")
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> v2 - fix commit message
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: David Miller @ 2017-01-11 21:32 UTC (permalink / raw)
To: f.fainelli
Cc: Joao.Pinto, lars.persson, niklass, peppe.cavallaro,
alexandre.torgue, netdev
In-Reply-To: <5b5a3231-eed4-ef29-b32a-a19077681dad@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 11 Jan 2017 13:14:32 -0800
> As mentioned before, although git is able to track renames, git log does
> not automatically have --follow, so it can be hard for people to track
> down the (new) history of the driver.
>
> Personally, I don't see much value in doing this rename, especially when
> all the driver internal structures are still going to be named with
> stmmac (and please don't even think about doing a s/stmmac/snps/ inside
> the driver ;)).
I agree, this could really make long term maintainence and bug fix
backporting a nightmare for a lot of people.
Please strongly reconsider, I still don't see any true value in this
rename.
^ permalink raw reply
* Re: TCP using IPv4-mapped IPv6 address as source
From: Eric Dumazet @ 2017-01-11 21:47 UTC (permalink / raw)
To: Jonathan T. Leighton
Cc: Sowmini Varadhan, netdev, edumazet, Yuchung Cheng, Neal Cardwell
In-Reply-To: <0d48793d-81f1-3666-5c47-9c2431198dc1@udel.edu>
On Wed, 2017-01-11 at 16:26 -0500, Jonathan T. Leighton wrote:
> I'm sure I understand what you're saying here. There should be no flow
> to terminate.
rfc2765 describes a way to use IPv4-mapped IPv6 packets on the wire.
What I meant by 'terminating' was that it does not tell if an end system
(a host) is allowed to natively generate these packets.
Anyway,
https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00
(which does not appear to be an RFC), tells us this would be
dangerous ;)
^ permalink raw reply
* Re: [PATCH v2 01/13] net: ethernet: aquantia: Make and configuration files.
From: Rami Rosen @ 2017-01-11 22:05 UTC (permalink / raw)
To: Alexander Loktionov
Cc: Netdev, David VomLehn, Simon Edelhaus, Dmitrii Tarakanov,
Pavel Belous
In-Reply-To: <0b0d8974bdbfa66ab3bc4460f32f7916dd54b85a.1483999588.git.vomlehn@texas.net>
Hi,
> +++ b/drivers/net/ethernet/aquantia/Makefile
> @@ -0,0 +1,44 @@
...
...
> > +obj-$(CONFIG_AQTION) += atlantic.o
> +
> +atlantic-objs := aq_main.o \
> + aq_nic.o \
> + aq_pci_func.o \
Why twice aq_nic.o ? it appears two lines earlier:
> + aq_nic.o \
> + aq_vec.o \
> + aq_ring.o \
...
...
Regards,
Rami Rosen
^ permalink raw reply
* RE: Marvell Phy (1510) issue since v4.7 kernel
From: Kwok, WingMan @ 2017-01-11 22:18 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <20170110015336.GA7160@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Monday, January 09, 2017 8:54 PM
> To: Kwok, WingMan
> Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
>
> > From Marvell's brief description
> http://www.marvell.com/transceivers/alaska-gbe/,
> > it seems that 88E1510/1518 don't support fiber. Only 88E1512 does.
> In
> > that case, the fiber support patch is not applicable to
> 88E1510/1518.
>
> O.K. That makes it easier.
>
> Please add the relevant IDs to include/linux/marvell.h, and add
> entries to driver/net/phy/marvell.c for 1512 with SUPPORTED_FIBRE and
> 1510 and 1518 without.
>
> Andrew
By any chance you have the ID of 1512?
Thanks,
WingMan
^ permalink raw reply
* Re: Marvell Phy (1510) issue since v4.7 kernel
From: Andrew Lunn @ 2017-01-11 22:27 UTC (permalink / raw)
To: Kwok, WingMan; +Cc: Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <230CBA6E4B6B6B418E8730AC28E6FC7E15354AC2@DFLE11.ent.ti.com>
On Wed, Jan 11, 2017 at 10:18:02PM +0000, Kwok, WingMan wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Monday, January 09, 2017 8:54 PM
> > To: Kwok, WingMan
> > Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> > Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
> >
> > > From Marvell's brief description
> > http://www.marvell.com/transceivers/alaska-gbe/,
> > > it seems that 88E1510/1518 don't support fiber. Only 88E1512 does.
> > In
> > > that case, the fiber support patch is not applicable to
> > 88E1510/1518.
> >
> > O.K. That makes it easier.
> >
> > Please add the relevant IDs to include/linux/marvell.h, and add
> > entries to driver/net/phy/marvell.c for 1512 with SUPPORTED_FIBRE and
> > 1510 and 1518 without.
> >
> > Andrew
>
> By any chance you have the ID of 1512?
Nope, sorry.
Try Russell King.
Andrew
^ permalink raw reply
* [PATCH] net: lwtunnel: Handle lwtunnel_fill_encap failure
From: David Ahern @ 2017-01-11 22:29 UTC (permalink / raw)
To: netdev; +Cc: roopa, David Ahern
Handle failure in lwtunnel_fill_encap adding attributes to skb.
Fixes: 571e722676fe ("ipv4: support for fib route lwtunnel encap attributes")
Fixes: 19e42e451506 ("ipv6: support for fib route lwtunnel encap attributes")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/ipv4/fib_semantics.c | 11 +++++++----
net/ipv6/route.c | 3 ++-
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index eba1546b5031..9a375b908d01 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1279,8 +1279,9 @@ int fib_dump_info(struct sk_buff *skb, u32 portid, u32 seq, int event,
nla_put_u32(skb, RTA_FLOW, fi->fib_nh[0].nh_tclassid))
goto nla_put_failure;
#endif
- if (fi->fib_nh->nh_lwtstate)
- lwtunnel_fill_encap(skb, fi->fib_nh->nh_lwtstate);
+ if (fi->fib_nh->nh_lwtstate &&
+ lwtunnel_fill_encap(skb, fi->fib_nh->nh_lwtstate) < 0)
+ goto nla_put_failure;
}
#ifdef CONFIG_IP_ROUTE_MULTIPATH
if (fi->fib_nhs > 1) {
@@ -1316,8 +1317,10 @@ int fib_dump_info(struct sk_buff *skb, u32 portid, u32 seq, int event,
nla_put_u32(skb, RTA_FLOW, nh->nh_tclassid))
goto nla_put_failure;
#endif
- if (nh->nh_lwtstate)
- lwtunnel_fill_encap(skb, nh->nh_lwtstate);
+ if (nh->nh_lwtstate &&
+ lwtunnel_fill_encap(skb, nh->nh_lwtstate) < 0)
+ goto nla_put_failure;
+
/* length of rtnetlink header + attributes */
rtnh->rtnh_len = nlmsg_get_pos(skb) - (void *) rtnh;
} endfor_nexthops(fi);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index ce5aaf448c54..4f6b067c8753 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3317,7 +3317,8 @@ static int rt6_fill_node(struct net *net,
if (nla_put_u8(skb, RTA_PREF, IPV6_EXTRACT_PREF(rt->rt6i_flags)))
goto nla_put_failure;
- lwtunnel_fill_encap(skb, rt->dst.lwtstate);
+ if (lwtunnel_fill_encap(skb, rt->dst.lwtstate) < 0)
+ goto nla_put_failure;
nlmsg_end(skb, nlh);
return 0;
--
2.1.4
^ permalink raw reply related
* RE: Marvell Phy (1510) issue since v4.7 kernel
From: Kwok, WingMan @ 2017-01-11 22:32 UTC (permalink / raw)
To: Andrew Lunn, rmk+kernel@arm.linux.org.uk
Cc: Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <20170111222758.GG13033@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Wednesday, January 11, 2017 5:28 PM
> To: Kwok, WingMan
> Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
>
> On Wed, Jan 11, 2017 at 10:18:02PM +0000, Kwok, WingMan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > Sent: Monday, January 09, 2017 8:54 PM
> > > To: Kwok, WingMan
> > > Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> > > Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
> > >
> > > > From Marvell's brief description
> > > http://www.marvell.com/transceivers/alaska-gbe/,
> > > > it seems that 88E1510/1518 don't support fiber. Only 88E1512
> does.
> > > In
> > > > that case, the fiber support patch is not applicable to
> > > 88E1510/1518.
> > >
> > > O.K. That makes it easier.
> > >
> > > Please add the relevant IDs to include/linux/marvell.h, and add
> > > entries to driver/net/phy/marvell.c for 1512 with SUPPORTED_FIBRE
> and
> > > 1510 and 1518 without.
> > >
> > > Andrew
> >
> > By any chance you have the ID of 1512?
>
> Nope, sorry.
>
> Try Russell King.
>
> Andrew
Russell,
Do you have the ID of Marvell PHY 88E1512?
Thanks,
WingMan
^ permalink raw reply
* [PATCH] [v2] net: qcom/emac: grab a reference to the phydev on ACPI systems
From: Timur Tabi @ 2017-01-11 22:45 UTC (permalink / raw)
To: David Miller, netdev, johan
Commit 6ffe1c4cd0a7 ("net: qcom/emac: fix of_node and phydev leaks")
fixed the problem with reference leaks on phydev, but the fix is
device-tree specific. When the driver unloads, the reference is
dropped only on DT systems.
Instead, it's cleaner if up grab an reference on ACPI systems.
When the driver unloads, we can drop the reference without having
to check whether we're on a DT system.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
Notes:
v2: add check for null pointer
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 7 +++++++
drivers/net/ethernet/qualcomm/emac/emac.c | 6 ++----
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index 99a14df..2851b4c 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -201,6 +201,13 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
else
adpt->phydev = mdiobus_get_phy(mii_bus, phy_addr);
+ /* of_phy_find_device() claims a reference to the phydev,
+ * so we do that here manually as well. When the driver
+ * later unloads, it can unilaterally drop the reference
+ * without worrying about ACPI vs DT.
+ */
+ if (adpt->phydev)
+ get_device(&adpt->phydev->mdio.dev);
} else {
struct device_node *phy_np;
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index 6ffe192..0aac0de 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -729,8 +729,7 @@ static int emac_probe(struct platform_device *pdev)
err_undo_napi:
netif_napi_del(&adpt->rx_q.napi);
err_undo_mdiobus:
- if (!has_acpi_companion(&pdev->dev))
- put_device(&adpt->phydev->mdio.dev);
+ put_device(&adpt->phydev->mdio.dev);
mdiobus_unregister(adpt->mii_bus);
err_undo_clocks:
emac_clks_teardown(adpt);
@@ -750,8 +749,7 @@ static int emac_remove(struct platform_device *pdev)
emac_clks_teardown(adpt);
- if (!has_acpi_companion(&pdev->dev))
- put_device(&adpt->phydev->mdio.dev);
+ put_device(&adpt->phydev->mdio.dev);
mdiobus_unregister(adpt->mii_bus);
free_netdev(netdev);
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH] tilepro: Fix non-void return from void function
From: Joe Perches @ 2017-01-11 22:52 UTC (permalink / raw)
To: Chris Metcalf; +Cc: stephen hemminger, netdev, linux-kernel
commit bc1f44709cf2 ("net: make ndo_get_stats64 a void function")
mistakenly used a return value for this void conversion.
Fix it.
Signed-off-by: Joe Perches <joe@perches.com>
cc: stephen hemminger <stephen@networkplumber.org>
---
drivers/net/ethernet/tile/tilepro.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilepro.c b/drivers/net/ethernet/tile/tilepro.c
index 30cfea62a356..44f153713791 100644
--- a/drivers/net/ethernet/tile/tilepro.c
+++ b/drivers/net/ethernet/tile/tilepro.c
@@ -2090,12 +2090,8 @@ static void tile_net_get_stats64(struct net_device *dev,
stats->tx_bytes = tx_bytes;
stats->rx_errors = rx_errors;
stats->rx_dropped = rx_dropped;
-
- return stats;
}
-
-
/*
* Change the Ethernet Address of the NIC.
*
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
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