* Re: [PATCH net-next 13/13] s390/qeth: remove OSN-devices
From: David Miller @ 2017-01-11 14:05 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, stable
In-Reply-To: <20170111115600.4524-14-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Wed, 11 Jan 2017 12:56:00 +0100
> CHPID type "OSN" is a device type which had been used by IBM product
> "Communication Controller for Linux". This product has reached end of
> service in March 2016. Thus OSN support can be removed from the qeth
> driver.
>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
> Reviewed-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
> Reviewed-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
IBM can certainly decide what physical products it wants to support
or not, but this doesn't directly apply to what the Linux kernel
driver supports.
We do not unilaterally remove support for a chip from a driver just
because the vendor decides to stop supporting that chip. In fact this
is one of the main benefits and value-adds of Linux.
I'm not applying a patch series that removes support for a chipset
for this reason, sorry.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: David Miller @ 2017-01-11 14:11 UTC (permalink / raw)
To: lorenzo; +Cc: temnota.am, netdev
In-Reply-To: <CAKD1Yr3nfOp1LNfvVuTGZyThwu8Z+gaSN-DVaa11ZJYR+tMemg@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 11 Jan 2017 02:47:55 +0900
> On Tue, Jan 10, 2017 at 10:21 PM, Andrey Jr. Melnikov
> <temnota.am@gmail.com> wrote:
>>
>> > >>> I have no firsthand experience of this myself, but if the problems
>> > >>> that Andrey reports above in this thread are real, then those would
>> > >>> indicate that the code is not well-supported. Being unable to accept
>> > >>> DAD is a pretty serious issue. Andrey, what version of the kernel did
>> > >>> you see this on?
>>
>> Good catch. I'm running 4.8 without this patch. Current 4.10-rc works. Sorry
>> for noise.
>
> Ack. As I said before, I haven't seen this myself. Shouldn't have made
> assertions without firsthand evidence.
>
> That said, I think this patch is useful even though autoconf on VRFs
> works the same way. One reason is the example I provided above: it
> works even for interfaces that don't exist yet, whereas a VRF has to
> be created ahead of time, which means that the interface cannot
> immediately come up and receive an RA or its configuration will be
> incorrect.
>
> I also think that from a configuration perspective it's not
> necessarily useful to have one VRF for every interface, but that sort
> of depends on your point of view. Perhaps it's fine on a client system
> to have both vrf-wlan0 and wlan0, and vrf-eth0 and eth0. That might be
> confusing to users but maybe users don't really care?
>
> More in general I think that using a VRFs is buying into a bigger set
> of assumptions/restrictions than this patch does. For example, if I'm
> reading ipv6_dev_get_saddr correctly, once you put an interface in a
> VRF you can't really use the weak host model any more, because the
> stack won't pick a source address from outside the VRF if the route
> lookup returned a route in the VRF. Turning on the functionality in
> patch is a more minimal change that only affects autoconf.
I understand what you're saying, but if you look at how apps can be
put into hierarchical control groups, and automatically bind to VRF's
based upon where they are in that cgroup hierarchy, it matches your
use case precisely.
Maybe the setup is not ideal, but architectually it does everything
you want. And we strongly try to avoid adding multiple ways to do the
same thing.
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Alexandre Torgue @ 2017-01-11 14:25 UTC (permalink / raw)
To: Joao Pinto, davem; +Cc: lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <298670a0-7074-a590-9498-7a9db68d499e@synopsys.com>
Jao,
On 01/11/2017 12:54 PM, Joao Pinto wrote:
>
> Hi Alex,
>
> Às 11:39 AM de 1/11/2017, Alexandre Torgue escreveu:
>> Hi Jao,
>>
>> On 01/10/2017 03:52 PM, Joao Pinto wrote:
>>> This patch set removes the synopsys/dwc_eth_qos since it was merged recently
>>> to stmmac (dwmac-dwc-qos-eth glue driver).
>>>
>>> It also renames stmicro/stmmac to synopsys/ since it is a standard ethernet
>>> software package regarding synopsys ethernet controllers, supporting the
>>> majority of Synopsys Ethernet IPs.
>>
>> I understand the reason to rename stmmac driver. The only risk I see is that
>> usual user will be a little bit lost to find code. It seems there no risk of
>> backward compatibility with current/old DT (I assume you already checked this
>> point).
>
> I understand your concern, but for the Synopsys IPs users will be clearer what
> drivers to use and what current stmmac has to offer.
I agree.
>
> In terms of tests, I tested it and worked out of the box because the same
> Kconfig IDs were used assuring the retro-compatibility that David suggested a
> few weeks ago. For DT users no problems are expected as well.
Ok, sounds good.
I see that you rename also
Documentation/devicetree/bindings/net/stmmac.txt. You have also to
change some words inside as it talks about Stmicroelectronics.
Regards
Alex
>
> Thanks,
> Joao
>
>> Let's see what David think about that but if there no risk of backward
>> compatibility with DT, I agree with the series.
>>
>> Regards
>> Alex
>>
>>
>>
>>>
>>> In the future we should make an effort to migrate to this new synopsys/
>>> driver package all the Ethernet Synopsys IP drivers scattered in net/ethernet.
>>>
>>> Joao Pinto (2):
>>> synopsys: remove dwc_eth_qos driver
>>> stmmac: rename it to synopsys
>>>
>>> .../bindings/net/{stmmac.txt => synopsys.txt} | 0
>>> MAINTAINERS | 11 +-
>>> arch/arm/configs/multi_v7_defconfig | 3 +-
>>> drivers/net/ethernet/Kconfig | 3 +-
>>> drivers/net/ethernet/Makefile | 3 +-
>>> drivers/net/ethernet/stmicro/Kconfig | 21 -
>>> drivers/net/ethernet/stmicro/Makefile | 5 -
>>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 162 --
>>> drivers/net/ethernet/stmicro/stmmac/Makefile | 25 -
>>> drivers/net/ethernet/synopsys/Kconfig | 165 +-
>>> drivers/net/ethernet/synopsys/Makefile | 28 +-
>>> .../{stmicro/stmmac => synopsys}/altr_tse_pcs.c | 0
>>> .../{stmicro/stmmac => synopsys}/altr_tse_pcs.h | 0
>>> .../{stmicro/stmmac => synopsys}/chain_mode.c | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/common.h | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/descs.h | 0
>>> .../{stmicro/stmmac => synopsys}/descs_com.h | 0
>>> drivers/net/ethernet/synopsys/dwc_eth_qos.c | 2996 --------------------
>>> .../stmmac => synopsys}/dwmac-dwc-qos-eth.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-generic.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-ipq806x.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-lpc18xx.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-meson.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-meson8b.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-oxnas.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-rk.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-socfpga.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-sti.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-stm32.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-sunxi.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac100.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac1000.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac1000_core.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac1000_dma.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac100_core.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac100_dma.c | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/dwmac4.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_core.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_descs.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_descs.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_dma.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_dma.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_lib.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac_dma.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac_lib.c | 0
>>> .../{stmicro/stmmac => synopsys}/enh_desc.c | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/mmc.h | 0
>>> .../{stmicro/stmmac => synopsys}/mmc_core.c | 0
>>> .../{stmicro/stmmac => synopsys}/norm_desc.c | 0
>>> .../{stmicro/stmmac => synopsys}/ring_mode.c | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/stmmac.h | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_ethtool.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_hwtstamp.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_main.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_mdio.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_pci.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_pcs.h | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_platform.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_platform.h | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_ptp.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_ptp.h | 0
>>> 61 files changed, 180 insertions(+), 3242 deletions(-)
>>> rename Documentation/devicetree/bindings/net/{stmmac.txt => synopsys.txt} (100%)
>>> delete mode 100644 drivers/net/ethernet/stmicro/Kconfig
>>> delete mode 100644 drivers/net/ethernet/stmicro/Makefile
>>> delete mode 100644 drivers/net/ethernet/stmicro/stmmac/Kconfig
>>> delete mode 100644 drivers/net/ethernet/stmicro/stmmac/Makefile
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/altr_tse_pcs.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/altr_tse_pcs.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/chain_mode.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/common.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/descs.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/descs_com.h (100%)
>>> delete mode 100644 drivers/net/ethernet/synopsys/dwc_eth_qos.c
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-dwc-qos-eth.c
>>> (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-generic.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-ipq806x.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-lpc18xx.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-meson.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-meson8b.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-oxnas.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-rk.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-socfpga.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-sti.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-stm32.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-sunxi.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac100.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac1000.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac1000_core.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac1000_dma.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac100_core.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac100_dma.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_core.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_descs.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_descs.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_dma.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_dma.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_lib.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac_dma.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac_lib.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/enh_desc.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/mmc.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/mmc_core.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/norm_desc.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/ring_mode.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_ethtool.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_hwtstamp.c
>>> (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_main.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_mdio.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_pci.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_pcs.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_platform.c
>>> (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_platform.h
>>> (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_ptp.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_ptp.h (100%)
>>>
>
^ permalink raw reply
* Re: [PATCH net-next v3] net: dsa: make "label" property optional for dsa2
From: David Miller @ 2017-01-11 14:27 UTC (permalink / raw)
To: vivien.didelot
Cc: netdev, linux-kernel, kernel, f.fainelli, andrew, jiri, uwe,
andrew.smirnov
In-Reply-To: <20170109231351.5023-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 9 Jan 2017 18:13:51 -0500
> In the new DTS bindings for DSA (dsa2), the "ethernet" and "link"
> phandles are respectively mandatory and exclusive to CPU port and DSA
> link device tree nodes.
>
> Simplify dsa2.c a bit by checking the presence of such phandle instead
> of checking the redundant "label" property.
>
> Then the Linux philosophy for Ethernet switch ports is to expose them to
> userspace as standard NICs by default. Thus use the standard enumerated
> "eth%d" device name if no "label" property is provided for a user port.
> This allows to save DTS files from subjective net device names.
>
> If one wants to rename an interface, udev rules can be used as usual.
>
> Of course the current behavior is unchanged, and the optional "label"
> property for user ports has precedence over the enumerated name.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Acked-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 14:29 UTC (permalink / raw)
To: Alexandre Torgue, Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <d814eabb-ec19-9df4-1f44-4405ece6995f@st.com>
Alex,
Às 2:25 PM de 1/11/2017, Alexandre Torgue escreveu:
> Jao,
>
> On 01/11/2017 12:54 PM, Joao Pinto wrote:
>>
>> Hi Alex,
>>
>> Às 11:39 AM de 1/11/2017, Alexandre Torgue escreveu:
>>> Hi Jao,
>>>
>>> On 01/10/2017 03:52 PM, Joao Pinto wrote:
>>>> This patch set removes the synopsys/dwc_eth_qos since it was merged recently
>>>> to stmmac (dwmac-dwc-qos-eth glue driver).
>>>>
>>>> It also renames stmicro/stmmac to synopsys/ since it is a standard ethernet
>>>> software package regarding synopsys ethernet controllers, supporting the
>>>> majority of Synopsys Ethernet IPs.
>>>
>>> I understand the reason to rename stmmac driver. The only risk I see is that
>>> usual user will be a little bit lost to find code. It seems there no risk of
>>> backward compatibility with current/old DT (I assume you already checked this
>>> point).
>>
>> I understand your concern, but for the Synopsys IPs users will be clearer what
>> drivers to use and what current stmmac has to offer.
>
> I agree.
>
>>
>> In terms of tests, I tested it and worked out of the box because the same
>> Kconfig IDs were used assuring the retro-compatibility that David suggested a
>> few weeks ago. For DT users no problems are expected as well.
>
> Ok, sounds good.
>
> I see that you rename also Documentation/devicetree/bindings/net/stmmac.txt. You
> have also to change some words inside as it talks about Stmicroelectronics.
You are right. Going to change that and send a v3. Counting on your ack :)
Thanks!
>
> Regards
> Alex
>
>>
>> Thanks,
>> Joao
>>
>>> Let's see what David think about that but if there no risk of backward
>>> compatibility with DT, I agree with the series.
>>>
>>> Regards
>>> Alex
>>>
>>>
>>>
>>>>
>>>> In the future we should make an effort to migrate to this new synopsys/
>>>> driver package all the Ethernet Synopsys IP drivers scattered in net/ethernet.
>>>>
>>>> Joao Pinto (2):
>>>> synopsys: remove dwc_eth_qos driver
>>>> stmmac: rename it to synopsys
>>>>
>>>> .../bindings/net/{stmmac.txt => synopsys.txt} | 0
>>>> MAINTAINERS | 11 +-
>>>> arch/arm/configs/multi_v7_defconfig | 3 +-
>>>> drivers/net/ethernet/Kconfig | 3 +-
^ permalink raw reply
* RE: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Andrei.Pistirica @ 2017-01-11 14:34 UTC (permalink / raw)
To: richardcochran, rafalo, harinikatakamlinux, nicolas.ferre,
harini.katakam
Cc: tbultel, boris.brezillon, netdev, alexandre.belloni, linux-kernel,
michals, anirudh, punnaia, davem, linux-arm-kernel
In-Reply-To: <20170103111447.GA26488@localhost.localdomain>
> On Tue, Jan 03, 2017 at 10:47:56AM +0000, Rafal Ozieblo wrote:
> > We could use only descriptor approach but there are many Atmel's cores
> on the market which support only event registers.
>
> As I said in my other reply in this thread, the Atmel cores cannot possibly be
> made to work correctly.
>
> Sad, but true.
In conscience, I will make a patch containing only the common code (just to benefit from this effort) and then Rafal can add the driver for the GXL version on top of it.
Everybody agrees with this?
Best regards,
Andrei
>
> Thanks,
> Richard
^ permalink raw reply
* [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Arnd Bergmann @ 2017-01-11 14:35 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Arnd Bergmann, David S. Miller, Johannes Berg,
netdev, linux-kernel
gcc-7 complains that wl3501_cs passes NULL into a function that
then uses the argument as the input for memcpy:
drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan':
include/net/iw_handler.h:559:3: error: argument 2 null where non-null expected [-Werror=nonnull]
memcpy(stream + point_len, extra, iwe->u.data.length);
This works fine here because iwe->u.data.length is guaranteed to be
NULL, and the memcpy doesn't actually have an effect.
Making the length check explicit avoids the warning and should have
no other effect here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/net/iw_handler.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/iw_handler.h b/include/net/iw_handler.h
index e0f4109e64c6..1a41043688bc 100644
--- a/include/net/iw_handler.h
+++ b/include/net/iw_handler.h
@@ -556,7 +556,8 @@ 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);
- memcpy(stream + point_len, extra, iwe->u.data.length);
+ if (iwe->u.data.length)
+ memcpy(stream + point_len, extra, iwe->u.data.length);
stream += event_len;
}
return stream;
--
2.9.0
^ permalink raw reply related
* [PATCH] bnxt_en: hide unused bnxt_get_max_func_{vnics,rss_ctxs} functions
From: Arnd Bergmann @ 2017-01-11 14:36 UTC (permalink / raw)
To: Michael Chan
Cc: Arnd Bergmann, David S. Miller, Prashant Sreedharan,
Satish Baddipadige, Alexander Duyck, netdev, linux-kernel
There are lots of #ifdefs in this file, and a recent patch got one
of them wrong, leading to a harmless warning in some randconfig
builds:
ethernet/broadcom/bnxt/bnxt.c:4956:21: error: 'bnxt_get_max_func_vnics' defined but not used [-Werror=unused-function]
ethernet/broadcom/bnxt/bnxt.c:4947:21: error: 'bnxt_get_max_func_rss_ctxs' defined but not used [-Werror=unused-function]
Ideally we'd just remove all of them and use 'if (IS_ENABLED())'
checks instead, which don't have this problem, but for now, I'm
adding one more #ifdef to shut up the new warning.
Fixes: 8079e8f107bf ("bnxt_en: Refactor code that determines RFS capability.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 7bd2a85694dd..c0918507fdb4 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4944,6 +4944,7 @@ static int bnxt_setup_int_mode(struct bnxt *bp)
return rc;
}
+#ifdef CONFIG_RFS_ACCEL
static unsigned int bnxt_get_max_func_rss_ctxs(struct bnxt *bp)
{
#if defined(CONFIG_BNXT_SRIOV)
@@ -4961,6 +4962,7 @@ static unsigned int bnxt_get_max_func_vnics(struct bnxt *bp)
#endif
return bp->pf.max_vnics;
}
+#endif
unsigned int bnxt_get_max_func_stat_ctxs(struct bnxt *bp)
{
--
2.9.0
^ permalink raw reply related
* Re: net/atm: warning in alloc_tx/__might_sleep
From: Chas Williams @ 2017-01-11 14:37 UTC (permalink / raw)
To: Andrey Konovalov, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Al Viro
Cc: Dmitry Vyukov, Kostya Serebryany, Eric Dumazet, syzkaller
In-Reply-To: <CAAeHK+yZ16SKcmJbv2ARafGgAuX2wwQNE0HGdiFy1WgqPjxLMg@mail.gmail.com>
On Mon, 2017-01-09 at 18:20 +0100, Andrey Konovalov wrote:
> Hi!
>
> I've got the following error report while running the syzkaller fuzzer.
>
> On commit a121103c922847ba5010819a3f250f1f7fc84ab8 (4.10-rc3).
>
> A reproducer is attached.
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 4114 at kernel/sched/core.c:7737 __might_sleep+0x149/0x1a0
> do not call blocking ops when !TASK_RUNNING; state=1 set at
> [<ffffffff813fcb22>] prepare_to_wait+0x182/0x530
> Modules linked in:
> CPU: 0 PID: 4114 Comm: a.out Not tainted 4.10.0-rc3+ #59
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:15
> dump_stack+0x292/0x398 lib/dump_stack.c:51
> __warn+0x19f/0x1e0 kernel/panic.c:547
> warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:562
> __might_sleep+0x149/0x1a0 kernel/sched/core.c:7732
> slab_pre_alloc_hook mm/slab.h:408
> slab_alloc_node mm/slub.c:2634
> kmem_cache_alloc_node+0x14a/0x280 mm/slub.c:2744
> __alloc_skb+0x10f/0x800 net/core/skbuff.c:219
> alloc_skb ./include/linux/skbuff.h:926
> alloc_tx net/atm/common.c:75
This is likely alloc_skb(..., GFP_KERNEL) in alloc_tx(). The simplest
fix for this would be simply to switch this GFP_ATOMIC. See if this is
any better.
diff --git a/net/atm/common.c b/net/atm/common.c
index a3ca922..d84220c 100644
--- a/net/atm/common.c
+++ b/net/atm/common.c
@@ -72,7 +72,7 @@ static struct sk_buff *alloc_tx(struct atm_vcc *vcc, unsigned int size)
sk_wmem_alloc_get(sk), size, sk->sk_sndbuf);
return NULL;
}
- while (!(skb = alloc_skb(size, GFP_KERNEL)))
+ while (!(skb = alloc_skb(size, GFP_ATOMIC)))
schedule();
pr_debug("%d += %d\n", sk_wmem_alloc_get(sk), skb->truesize);
atomic_add(skb->truesize, &sk->sk_wmem_alloc);
^ permalink raw reply related
* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Johannes Berg @ 2017-01-11 14:38 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-wireless, David S. Miller, netdev, linux-kernel
In-Reply-To: <20170111143532.485827-1-arnd@arndb.de>
On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> gcc-7 complains that wl3501_cs passes NULL into a function that
> then uses the argument as the input for memcpy:
>
> drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan':
> include/net/iw_handler.h:559:3: error: argument 2 null where non-null
> expected [-Werror=nonnull]
> memcpy(stream + point_len, extra, iwe->u.data.length);
I love wext ;-)
> This works fine here because iwe->u.data.length is guaranteed to be
> NULL, and the memcpy doesn't actually have an effect.
I think you mean 0, not NULL, but I can fix that when I apply it.
johannes
^ permalink raw reply
* Re: [PATCH] sctp: Fix spelling mistake: "Atempt" -> "Attempt"
From: Neil Horman @ 2017-01-11 14:39 UTC (permalink / raw)
To: Colin King
Cc: Vlad Yasevich, David S . Miller, linux-sctp, netdev, linux-kernel
In-Reply-To: <20170110225306.14880-1-colin.king@canonical.com>
On Tue, Jan 10, 2017 at 10:53:06PM +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in WARN_ONCE message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/sctp/outqueue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index e540826..34efaa4 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1048,7 +1048,7 @@ static void sctp_outq_flush(struct sctp_outq *q, int rtx_timeout, gfp_t gfp)
> (new_transport->state == SCTP_PF)))
> new_transport = asoc->peer.active_path;
> if (new_transport->state == SCTP_UNCONFIRMED) {
> - WARN_ONCE(1, "Atempt to send packet on unconfirmed path.");
> + WARN_ONCE(1, "Attempt to send packet on unconfirmed path.");
> sctp_chunk_fail(chunk, 0);
> sctp_chunk_free(chunk);
> continue;
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Alexandre Torgue @ 2017-01-11 14:39 UTC (permalink / raw)
To: Joao Pinto, davem; +Cc: lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <a91d92f0-21a5-2225-88c3-162c8fb005f5@synopsys.com>
On 01/11/2017 03:29 PM, Joao Pinto wrote:
>
> Alex,
>
> Às 2:25 PM de 1/11/2017, Alexandre Torgue escreveu:
>> Jao,
>>
>> On 01/11/2017 12:54 PM, Joao Pinto wrote:
>>>
>>> Hi Alex,
>>>
>>> Às 11:39 AM de 1/11/2017, Alexandre Torgue escreveu:
>>>> Hi Jao,
>>>>
>>>> On 01/10/2017 03:52 PM, Joao Pinto wrote:
>>>>> This patch set removes the synopsys/dwc_eth_qos since it was merged recently
>>>>> to stmmac (dwmac-dwc-qos-eth glue driver).
>>>>>
>>>>> It also renames stmicro/stmmac to synopsys/ since it is a standard ethernet
>>>>> software package regarding synopsys ethernet controllers, supporting the
>>>>> majority of Synopsys Ethernet IPs.
>>>>
>>>> I understand the reason to rename stmmac driver. The only risk I see is that
>>>> usual user will be a little bit lost to find code. It seems there no risk of
>>>> backward compatibility with current/old DT (I assume you already checked this
>>>> point).
>>>
>>> I understand your concern, but for the Synopsys IPs users will be clearer what
>>> drivers to use and what current stmmac has to offer.
>>
>> I agree.
>>
>>>
>>> In terms of tests, I tested it and worked out of the box because the same
>>> Kconfig IDs were used assuring the retro-compatibility that David suggested a
>>> few weeks ago. For DT users no problems are expected as well.
>>
>> Ok, sounds good.
>>
>> I see that you rename also Documentation/devicetree/bindings/net/stmmac.txt. You
>> have also to change some words inside as it talks about Stmicroelectronics.
>
> You are right. Going to change that and send a v3. Counting on your ack :)
I continue to review ;)
There is another point to talk. It will be strange to have the driver
named "synopsys" but all file inside will continue to be called "stmmac"
(and also function inside files). So either you plan to keep it as it is
(and it is a little bit confusing) or you plan to change all file name +
function name (+ few variable name) ?
regards
Alex
> Thanks!
>
>>
>> Regards
>> Alex
>>
>>>
>>> Thanks,
>>> Joao
>>>
>>>> Let's see what David think about that but if there no risk of backward
>>>> compatibility with DT, I agree with the series.
>>>>
>>>> Regards
>>>> Alex
>>>>
>>>>
>>>>
>>>>>
>>>>> In the future we should make an effort to migrate to this new synopsys/
>>>>> driver package all the Ethernet Synopsys IP drivers scattered in net/ethernet.
>>>>>
>>>>> Joao Pinto (2):
>>>>> synopsys: remove dwc_eth_qos driver
>>>>> stmmac: rename it to synopsys
>>>>>
>>>>> .../bindings/net/{stmmac.txt => synopsys.txt} | 0
>>>>> MAINTAINERS | 11 +-
>>>>> arch/arm/configs/multi_v7_defconfig | 3 +-
>>>>> drivers/net/ethernet/Kconfig | 3 +-
>
^ permalink raw reply
* Re: [PATCH] cgroup: move CONFIG_SOCK_CGROUP_DATA to init/Kconfig
From: David Miller @ 2017-01-11 14:48 UTC (permalink / raw)
To: arnd; +Cc: netdev, ast, luto, augustocaringi, linux-kernel
In-Reply-To: <20170110120825.2984218-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 10 Jan 2017 13:08:06 +0100
> We now 'select SOCK_CGROUP_DATA' but Kconfig complains that this is
> not right when CONFIG_NET is disabled and there is no socket interface:
>
> warning: (CGROUP_BPF) selects SOCK_CGROUP_DATA which has unmet direct dependencies (NET)
>
> I don't know what the correct solution for this is, but simply removing
> the dependency on NET from SOCK_CGROUP_DATA by moving it out of the
> 'if NET' section avoids the warning and does not produce other build
> errors.
>
> Fixes: 483c4933ea09 ("cgroup: Fix CGROUP_BPF config")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> There was an earlier patch by Augusto Mecking Caringi, which added
> a dependency, see https://lkml.org/lkml/2017/1/2/296.
>
> I could not figure out whether CGROUP_BPF is meaningful without
> CONFIG_NET, my version of the patch assumes that it is.
> Applying either my version Augusto's to v4.10-rc will kill the
> warning.
CGROUP_BPF doesn't is not currently meaningful without CONFIG_NET,
and especially SOCK_CGROUP_DATA is not meaningful without CONFIG_NET.
Patch applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: David Miller @ 2017-01-11 14:52 UTC (permalink / raw)
To: alexandre.torgue
Cc: Joao.Pinto, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <0dcdcb5f-200b-b130-9a67-774639353114@st.com>
From: Alexandre Torgue <alexandre.torgue@st.com>
Date: Wed, 11 Jan 2017 12:39:09 +0100
> Let's see what David think about that but if there no risk of backward
> compatibility with DT, I agree with the series.
I really am generally against driver renames. The only potentially
make new users happy, but can only negatively impact existing users.
The new name is not terribly appropriate either, it is using the name
of the manufacturer rather than referring to a chipset or a class or
chipsets.
I don't see what the big deal is in leaving the name as 'stmmac' and
in a way leaving it alone shows respect for the people who have worked
on and cared for the stmmac driver for all of these years.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 14:54 UTC (permalink / raw)
To: Alexandre Torgue, Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <8bdb613c-36d3-811f-6300-9c97110c855d@st.com>
Às 2:39 PM de 1/11/2017, Alexandre Torgue escreveu:
>
>
> On 01/11/2017 03:29 PM, Joao Pinto wrote:
>>
>> Alex,
>>
>> Às 2:25 PM de 1/11/2017, Alexandre Torgue escreveu:
>>> Jao,
>>>
>>> On 01/11/2017 12:54 PM, Joao Pinto wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> Às 11:39 AM de 1/11/2017, Alexandre Torgue escreveu:
>>>>> Hi Jao,
>>>>>
>>>>> On 01/10/2017 03:52 PM, Joao Pinto wrote:
>>>>>> This patch set removes the synopsys/dwc_eth_qos since it was merged recently
>>>>>> to stmmac (dwmac-dwc-qos-eth glue driver).
>>>>>>
>>>>>> It also renames stmicro/stmmac to synopsys/ since it is a standard ethernet
>>>>>> software package regarding synopsys ethernet controllers, supporting the
>>>>>> majority of Synopsys Ethernet IPs.
>>>>>
>>>>> I understand the reason to rename stmmac driver. The only risk I see is that
>>>>> usual user will be a little bit lost to find code. It seems there no risk of
>>>>> backward compatibility with current/old DT (I assume you already checked this
>>>>> point).
>>>>
>>>> I understand your concern, but for the Synopsys IPs users will be clearer what
>>>> drivers to use and what current stmmac has to offer.
>>>
>>> I agree.
>>>
>>>>
>>>> In terms of tests, I tested it and worked out of the box because the same
>>>> Kconfig IDs were used assuring the retro-compatibility that David suggested a
>>>> few weeks ago. For DT users no problems are expected as well.
>>>
>>> Ok, sounds good.
>>>
>>> I see that you rename also Documentation/devicetree/bindings/net/stmmac.txt. You
>>> have also to change some words inside as it talks about Stmicroelectronics.
>>
>> You are right. Going to change that and send a v3. Counting on your ack :)
>
> I continue to review ;)
> There is another point to talk. It will be strange to have the driver named
> "synopsys" but all file inside will continue to be called "stmmac" (and also
> function inside files). So either you plan to keep it as it is (and it is a
> little bit confusing) or you plan to change all file name + function name (+ few
> variable name) ?
The plan would be to change incrementally, but I have no problem in doing it all
now.
I am going to give you an example of something that must be done.
Syniopsys IP portfolium does not include a GMAC4 core, because it does not
exist. I understand why stmmac calls that way, but it is not accurate. Going to
explain why. Synopsys has the eQoS IP which version began at 4.x, and for
historical reasons drivers chose to call it gmac4 or dwmac4, when in fact it
should be named eqos or dwmac_eqos. This will have to be changed since when a
new version of eQoS is released, imagine 5.00, it will become completely
confusing. This is the reason why the files and functions named after gmac4 and
dwmac4 should be called eqos and dwmac-eqos.
We can make a total rename instead of renaming basic stuff, no problem. What do
you think?
Joao
>
> regards
> Alex
>
>
>
>
>> Thanks!
>>
>>>
>>> Regards
>>> Alex
>>>
>>>>
>>>> Thanks,
>>>> Joao
>>>>
>>>>> Let's see what David think about that but if there no risk of backward
>>>>> compatibility with DT, I agree with the series.
>>>>>
>>>>> Regards
>>>>> Alex
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> In the future we should make an effort to migrate to this new synopsys/
>>>>>> driver package all the Ethernet Synopsys IP drivers scattered in
>>>>>> net/ethernet.
>>>>>>
>>>>>> Joao Pinto (2):
>>>>>> synopsys: remove dwc_eth_qos driver
>>>>>> stmmac: rename it to synopsys
>>>>>>
>>>>>> .../bindings/net/{stmmac.txt => synopsys.txt} | 0
>>>>>> MAINTAINERS | 11 +-
>>>>>> arch/arm/configs/multi_v7_defconfig | 3 +-
>>>>>> drivers/net/ethernet/Kconfig | 3 +-
>>
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: dsa: Implement ndo_get_phys_port_name()
From: David Miller @ 2017-01-11 14:59 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, vivien.didelot, andrew, jiri
In-Reply-To: <20170110203237.23907-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 10 Jan 2017 12:32:35 -0800
> This patch series implements ndo_get_phys_port_name() so we can revert
> ndo_get_phys_id() which was (ab)used in the DSA layer.
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: switchdev: Avoid sleep in atomic with DSA
From: Andrew Lunn @ 2017-01-11 14:59 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Ido Schimmel, Jiri Pirko, netdev, davem, vivien.didelot
In-Reply-To: <03ce7d38-7775-3cd7-d863-682316d949bf@gmail.com>
> Vivien, Andrew, are you aware of an use case where we have the HW
> programmed with a superset of VLANs wrt. the SW bridge?
I cannot think of any case with a superset. Subset yes, but not
superset.
Andrew
^ permalink raw reply
* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Arnd Bergmann @ 2017-01-11 15:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, David S. Miller, Networking, linux-kernel
In-Reply-To: <1484145522.29931.13.camel@sipsolutions.net>
On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
>> This works fine here because iwe->u.data.length is guaranteed to be
>> NULL, and the memcpy doesn't actually have an effect.
>
> I think you mean 0, not NULL, but I can fix that when I apply it.
Right, thanks!
Arnd
^ permalink raw reply
* Re: [PATCH net] net: ipv4: Fix multipath selection with vrf
From: David Miller @ 2017-01-11 15:00 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1484087855-4607-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Tue, 10 Jan 2017 14:37:35 -0800
> fib_select_path does not call fib_select_multipath if oif is set in the
> flow struct. For VRF use cases oif is always set, so multipath route
> selection is bypassed. Use the FLOWI_FLAG_SKIP_NH_OIF to skip the oif
> check similar to what is done in fib_table_lookup.
>
> Add saddr and proto to the flow struct for the fib lookup done by the
> VRF driver to better match hash computation for a flow.
>
> Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> ---
> IPv6 multipath selection works fine as is.
Applied and queued up for -stable, thanks David.
^ permalink raw reply
* Re: [PATCH] sctp: Fix spelling mistake: "Atempt" -> "Attempt"
From: David Miller @ 2017-01-11 15:01 UTC (permalink / raw)
To: colin.king; +Cc: vyasevich, nhorman, linux-sctp, netdev, linux-kernel
In-Reply-To: <20170110225306.14880-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 10 Jan 2017 22:53:06 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in WARN_ONCE message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] softingcs: ret is never non-zero, so remove non-zero check and -ENODEV return
From: Colin King @ 2017-01-11 15:02 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, linux-can, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The error return ret is never zero in the error handling path in
softingcs_probe, so the check for non-zero and returning -ENODEV
is logically dead code and hence redundant. Remove it and just
return ret.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/can/softing/softing_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/softing/softing_cs.c b/drivers/net/can/softing/softing_cs.c
index cdc0c74..4d44928 100644
--- a/drivers/net/can/softing/softing_cs.c
+++ b/drivers/net/can/softing/softing_cs.c
@@ -310,7 +310,7 @@ static int softingcs_probe(struct pcmcia_device *pcmcia)
pcmcia_failed:
pcmcia_disable_device(pcmcia);
pcmcia->priv = NULL;
- return ret ?: -ENODEV;
+ return ret;
}
static const struct pcmcia_device_id softingcs_ids[] = {
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
From: David Miller @ 2017-01-11 15:03 UTC (permalink / raw)
To: rmk+kernel
Cc: f.fainelli, andrew, charles-antoine.couret, linux-arm-kernel,
netdev
In-Reply-To: <E1cR5bt-0000O8-1T@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 10 Jan 2017 23:13:45 +0000
> When an Marvell 88E1512 PHY is connected to a nic in SGMII mode, the
> fiber page is used for the SGMII host-side connection. The PHY driver
> notices that SUPPORTED_FIBRE is set, so it tries reading the fiber page
> for the link status, and ends up reading the MAC-side status instead of
> the outgoing (copper) link. This leads to incorrect results reported
> via ethtool.
>
> If the PHY is connected via SGMII to the host, ignore the fiber page.
> However, continue to allow the existing power management code to
> suspend and resume the fiber page.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied, thanks Russell.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
From: David Miller @ 2017-01-11 15:03 UTC (permalink / raw)
To: f.fainelli
Cc: andrew, rmk+kernel, netdev, linux-arm-kernel,
charles-antoine.couret
In-Reply-To: <61950d83-cbe1-6e1b-4afc-bc471b386ff3@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 10 Jan 2017 15:24:11 -0800
> Fixes: 6cfb3bcc0641 ("Marvell phy: check link status in case of fiber
> link.")
Thanks, I added this to Russell's commit message.
^ permalink raw reply
* Re: [PATCH] net: vrf: do not allow table id 0
From: David Miller @ 2017-01-11 15:04 UTC (permalink / raw)
To: dsa; +Cc: netdev, frank.kellermann
In-Reply-To: <1484090545-16407-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Tue, 10 Jan 2017 15:22:25 -0800
> Frank reported that vrf devices can be created with a table id of 0.
> This breaks many of the run time table id checks and should not be
> allowed. Detect this condition at create time and fail with EINVAL.
>
> Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
> Reported-by: Frank Kellermann <frank.kellermann@atos.net>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied and queued up for -stable, thanks David.
^ permalink raw reply
* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Johannes Berg @ 2017-01-11 15:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-wireless, David S. Miller, Networking, linux-kernel
In-Reply-To: <CAK8P3a2mOT=BG=9yxJ1e-q__5FYq6dfF3t3bT1vqcgFaQAUjog@mail.gmail.com>
On Wed, 2017-01-11 at 16:00 +0100, Arnd Bergmann wrote:
> On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> > > This works fine here because iwe->u.data.length is guaranteed to
> > > be
> > > NULL, and the memcpy doesn't actually have an effect.
> >
> > I think you mean 0, not NULL, but I can fix that when I apply it.
>
> Right, thanks!
Applied. Also fixed the typo in the subject :)
johannes
^ 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