* Re: [PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
From: David Miller @ 2017-01-20 16:31 UTC (permalink / raw)
To: colin.king; +Cc: vyasevich, nhorman, linux-sctp, netdev, linux-kernel
In-Reply-To: <20170120134542.21104-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 20 Jan 2017 13:45:42 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> Table sctp_timer_tbl is missing a TIMEOUT_RECONF string so
> add this in. Also compare timeout with the size of the array
> sctp_timer_tbl rather than SCTP_EVENT_TIMEOUT_MAX. Also add
> a build time check that SCTP_EVENT_TIMEOUT_MAX is correct
> so we don't ever get this kind of mismatch between the table
> and SCTP_EVENT_TIMEOUT_MAX in the future.
>
> Kudos to Marcel Ricardo Leitner for spotting the missing string
> and suggesting the build time sanity check.
>
> Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Well, my bad... I reverted V1, that's fine.
But this patch doesn't even compile.
In file included from ./include/uapi/linux/stddef.h:1:0,
from ./include/linux/stddef.h:4,
from ./include/uapi/linux/posix_types.h:4,
from ./include/uapi/linux/types.h:13,
from ./include/linux/types.h:5,
from ./include/net/sctp/sctp.h:58,
from net/sctp/debug.c:41:
net/sctp/debug.c: In function ‘sctp_tname’:
./include/linux/compiler.h:518:38: error: call to ‘__compiletime_assert_170’ declared with attribute error: BUILD_BUG_ON failed: SCTP_EVENT_TIMEOUT_MAX + 1 != ARRAY_SIZE(sctp_timer_tbl)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags
From: Larry Finger @ 2017-01-20 16:30 UTC (permalink / raw)
To: Bharat Kumar Gogada, chaoming_li@realsil.com.cn,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: kvalo@codeaurora.org, netdev@vger.kernel.org, Ravikiran Gummaluri
In-Reply-To: <8520D5D51A55D047800579B094147198263CA86D@XAP-PVEXMBX02.xlnx.xilinx.com>
On 01/20/2017 08:14 AM, Bharat Kumar Gogada wrote:
> > On 01/19/2017 04:14 AM, Bharat Kumar Gogada wrote:
>>> -Realtek 8192CE chipset maintains local irq flags after enabling/disabling
>>> hardware interrupts.
>>> -Hardware interrupts are enabled before enabling the local irq
>>> flags(these flags are being checked in interrupt handler),
>>> leading to race condition on some RP, where the irq line between
>>> bridge and GIC goes high at ASSERT_INTx and goes low only
>>> at DEASSERT_INTx. In this kind of RP by the time ASSERT_INTx is seen
>>> irq_enable flag is still set to false, resulting in continuous
>>> interrupts seen by CPU as DEASSERT_INTx cannot be sent since
>>> flag is still false and making CPU stall.
>>> -Changing the sequence of setting these irq flags.
>>>
>>> Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
>>> ---
>>
>> This patch should be enhanced with the smb_xx() calls as suggested by by Lino.
>>
>> The subject should be changed. I would suggest something like "rtlwifi:
>> rtl8192ce: Prevent race condition when enabling interrupts", as it explains the
>> condition you are preventing.
>>
>> The other PCI drivers also have the same problem. Do you want to prepare the
>> patches, or should I do it?
>>
> Thanks Larry. Please send out the patches adding the above enhancements suggested by Lino.
I have prepared a patch fixing all the drivers. By the way, what CPU hardware
showed this problem?
Larry
^ permalink raw reply
* Re: [PATCH net-next] net: remove bh disabling around percpu_counter accesses
From: David Miller @ 2017-01-20 16:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1484917568.16328.110.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 20 Jan 2017 05:06:08 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Shaohua Li made percpu_counter irq safe in commit 098faf5805c8
> ("percpu_counter: make APIs irq safe")
>
> We can safely remove BH disable/enable sections around various
> percpu_counter manipulations.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Looks great, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: sctp: fix array overrun read on sctp_timer_tbl
From: David Miller @ 2017-01-20 16:26 UTC (permalink / raw)
To: colin.king; +Cc: vyasevich, nhorman, linux-sctp, netdev, linux-kernel
In-Reply-To: <20170120130157.20034-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 20 Jan 2017 13:01:57 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> The comparison on the timeout can lead to an array overrun
> read on sctp_timer_tbl because of an off-by-one error. Fix
> this by using < instead of <= and also compare to the array
> size rather than SCTP_EVENT_TIMEOUT_MAX.
>
> Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Fix unused variable warning
From: David Miller @ 2017-01-20 16:16 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, hariprasad
In-Reply-To: <1484903839-5890-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Fri, 20 Jan 2017 14:47:19 +0530
> Fix unused variable warning when CONFIG_PCI_IOV is not
> defined.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Arnd already submitted a fix for this, and unlike your's his provided
a proper Fixes-by: tag.
Thanks.
^ permalink raw reply
* [PATCH net-next] bnx2x: avoid two atomic ops per page on x86
From: Eric Dumazet @ 2017-01-20 16:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Gabriel Krisman Bertazi, Yuval Mintz, Ariel Elior
From: Eric Dumazet <edumazet@google.com>
Commit 4cace675d687 ("bnx2x: Alloc 4k fragment for each rx ring buffer
element") added extra put_page() and get_page() calls on arches where
PAGE_SIZE=4K like x86
Reorder things to avoid this overhead.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Cc: Yuval Mintz <Yuval.Mintz@cavium.com>
Cc: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 15 ++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 3e199d3e461ef5dd237e3176bcb666f878ac..c0dac0e5696d7d01457a42c2c13f1640c2e2 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -549,14 +549,7 @@ static int bnx2x_alloc_rx_sge(struct bnx2x *bp, struct bnx2x_fastpath *fp,
struct bnx2x_alloc_pool *pool = &fp->page_pool;
dma_addr_t mapping;
- if (!pool->page || (PAGE_SIZE - pool->offset) < SGE_PAGE_SIZE) {
-
- /* put page reference used by the memory pool, since we
- * won't be using this page as the mempool anymore.
- */
- if (pool->page)
- put_page(pool->page);
-
+ if (!pool->page) {
pool->page = alloc_pages(gfp_mask, PAGES_PER_SGE_SHIFT);
if (unlikely(!pool->page))
return -ENOMEM;
@@ -571,7 +564,6 @@ static int bnx2x_alloc_rx_sge(struct bnx2x *bp, struct bnx2x_fastpath *fp,
return -ENOMEM;
}
- get_page(pool->page);
sw_buf->page = pool->page;
sw_buf->offset = pool->offset;
@@ -581,7 +573,10 @@ static int bnx2x_alloc_rx_sge(struct bnx2x *bp, struct bnx2x_fastpath *fp,
sge->addr_lo = cpu_to_le32(U64_LO(mapping));
pool->offset += SGE_PAGE_SIZE;
-
+ if (PAGE_SIZE - pool->offset >= SGE_PAGE_SIZE)
+ get_page(pool->page);
+ else
+ pool->page = NULL;
return 0;
}
^ permalink raw reply related
* Re: [RFC PATCH] net: stmicro: eQOS IP Core
From: David Miller @ 2017-01-20 16:20 UTC (permalink / raw)
To: Joao.Pinto; +Cc: peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <4584830fd1416af69ddb2e0168f78b1e343c33fe.1484914583.git.jpinto@synopsys.com>
From: Joao Pinto <Joao.Pinto@synopsys.com>
Date: Fri, 20 Jan 2017 12:27:33 +0000
> For historical reasons the Designware eQOS IP Core started in version 4.x,
> instead of starting in 1.x. This caused some misunderstanding, which resulted
> in calling this IP as GMAC4. If you go to Synopsys website and check the
> Ethernet portfolio there is no GMAC4 IP:
> https://www.synopsys.com/designware-ip/interface-ip/ethernet.html
>
> There is a new version of eQOS comming out (5.x) that will have the same
> mac, dma registers and flow, with an extra set of registers to enable
> features like TSN. The creation of a dwmac5 or gmac5 would be wrong, and
> including those new features related to eQOS 5.x in dwmac4 would also not
> be very correct.
>
> This patch suggests to rename dwmac4_* driver to eqos_*, turning it the
> official driver for eQOS IP. The registers definitions are also now
> called QOS_ instead of GMAC4_.
>
> For more information about eQOS IP please check:
> https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_qos
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Sorry, you're not renaming every function in the driver that meets this
qualification.
I understand you want to work hard on the driver, but part of that is
_accepting_ things how they have been for years and making code
improvements and additions rather than messing around playing
rename-this/rename-that games until it looks how you want it to.
Please stop this charade of renaming, I'm getting really tired of it and
I think you really have no concept what kind of effect it has on people
who have to review, apply, and backport this code.
Kconfig text changes and clarifications, that's fine. But all of these
function and variable name changes to the driver, and comment sweeps, no
it is not acceptable to me.
^ permalink raw reply
* Re: [PATCH 1/3] cxgb4: hide unused warnings
From: David Miller @ 2017-01-20 16:15 UTC (permalink / raw)
To: arnd; +Cc: hariprasad, ganeshgr, rahul.lakkireddy, varun, netdev,
linux-kernel
In-Reply-To: <20170118145306.1004008-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 18 Jan 2017 15:52:51 +0100
> The two new variables are only used inside of an #ifdef and cause
> harmless warnings when that is disabled:
>
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function 'init_one':
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4646:9: error: unused variable 'port_vec' [-Werror=unused-variable]
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4646:6: error: unused variable 'v' [-Werror=unused-variable]
>
> This adds another #ifdef around the declarations.
>
> Fixes: 96fe11f27b70 ("cxgb4: Implement ndo_get_phys_port_id for mgmt dev")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH] stmicro: add more information to Kconfig
From: Joao Pinto @ 2017-01-20 16:00 UTC (permalink / raw)
To: davem; +Cc: rayagond, netdev
In-Reply-To: <8e4b7bbd48a0b2ff1374fdffe6d07dc00659e951.1484664500.git.jpinto@synopsys.com>
My e-mail client went bogus, please ignore 2 past e-mails.
Very sorry.
Best Regards,
Joao Pinto
Às 3:57 PM de 1/20/2017, Joao Pinto escreveu:
> This patch adds more info to stmicro' Kconfig files in order to be clearer
> that the driver can be used by ethernet cards based on 10/100/1000/EQOS
> Synopsys IP Cores.
>
> EQOS was also added stmmac/Kconfig Kconfig, since dwmac4 is in fact EQoS,
> one of Synopsys Ethernet IPs. More info at:
> https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_qos
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> ---
> drivers/net/ethernet/stmicro/Kconfig | 3 ++-
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 15 +++++++--------
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/Kconfig b/drivers/net/ethernet/stmicro/Kconfig
> index 1c1157d..ecd7a5e 100644
> --- a/drivers/net/ethernet/stmicro/Kconfig
> +++ b/drivers/net/ethernet/stmicro/Kconfig
> @@ -7,7 +7,8 @@ config NET_VENDOR_STMICRO
> default y
> depends on HAS_IOMEM
> ---help---
> - If you have a network (Ethernet) card belonging to this class, say Y.
> + If you have a network (Ethernet) card based on Synopsys Ethernet IP
> + Cores, say Y.
>
> Note that the answer to this question doesn't directly affect the
> kernel: saying N will just cause the configurator to skip all
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index 99594e3..cfbe363 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -1,5 +1,5 @@
> config STMMAC_ETH
> - tristate "STMicroelectronics 10/100/1000 Ethernet driver"
> + tristate "STMicroelectronics 10/100/1000/EQOS Ethernet driver"
> depends on HAS_IOMEM && HAS_DMA
> select MII
> select PHYLIB
> @@ -7,9 +7,8 @@ config STMMAC_ETH
> imply PTP_1588_CLOCK
> select RESET_CONTROLLER
> ---help---
> - This is the driver for the Ethernet IPs are built around a
> - Synopsys IP Core and only tested on the STMicroelectronics
> - platforms.
> + This is the driver for the Ethernet IPs built around a
> + Synopsys IP Core.
>
> if STMMAC_ETH
>
> @@ -152,11 +151,11 @@ config STMMAC_PCI
> tristate "STMMAC PCI bus support"
> depends on STMMAC_ETH && PCI
> ---help---
> - This is to select the Synopsys DWMAC available on PCI devices,
> - if you have a controller with this interface, say Y or M here.
> + This selects the platform specific bus support for the stmmac driver.
> + This driver was tested on XLINX XC2V3000 FF1152AMT0221
> + D1215994A VIRTEX FPGA board and SNPS QoS IPK Prototyping Kit.
>
> - This PCI support is tested on XLINX XC2V3000 FF1152AMT0221
> - D1215994A VIRTEX FPGA board.
> + If you have a controller with this interface, say Y or M here.
>
> If unsure, say N.
> endif
>
^ permalink raw reply
* Re: [PATCH net] ipv6: seg6_genl_set_tunsrc() must check kmemdup() return value
From: David Miller @ 2017-01-20 16:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, david.lebrun
In-Reply-To: <1484927862.16328.123.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 20 Jan 2017 07:57:42 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> seg6_genl_get_tunsrc() and set_tun_src() do not handle tun_src being
> possibly NULL, so we must check kmemdup() return value and abort if
> it is NULL
>
> Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* [PATCH net-next] ipv6: add NUMA awareness to seg6_hmac_init_algo()
From: Eric Dumazet @ 2017-01-20 16:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, David Lebrun
From: Eric Dumazet <edumazet@google.com>
Since we allocate per cpu storage, let's also use NUMA hints.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/seg6_hmac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index 5215e1eba01030dc9345b847eee5ac5ef3bed1b9..b274f1d95e037c93e8e0e6531cfc51709f71297c 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -389,7 +389,8 @@ static int seg6_hmac_init_algo(void)
return -ENOMEM;
for_each_possible_cpu(cpu) {
- shash = kzalloc(shsize, GFP_KERNEL);
+ shash = kzalloc_node(shsize, GFP_KERNEL,
+ cpu_to_node(cpu));
if (!shash)
return -ENOMEM;
*per_cpu_ptr(algo->shashs, cpu) = shash;
^ permalink raw reply related
* [PATCH] net: stmicro: fix LS field mask in EEE configuration
From: Joao Pinto @ 2017-01-20 16:00 UTC (permalink / raw)
To: davem; +Cc: rayagond, netdev, Joao Pinto
This patch fixes the LS mask when setting EEE timer.
LS field is 10 bits long and not 11 as currently.
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Reported-By: Rayagond Kokatanur <rayagond@vayavyalabs.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 834f40f..202216c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -184,7 +184,7 @@ static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
{
void __iomem *ioaddr = hw->pcsr;
- int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
+ int value = ((tw & 0xffff)) | ((ls & 0x3ff) << 16);
/* Program the timers in the LPI timer control register:
* LS: minimum time (ms) for which the link
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net] r8152: fix rtl8152_post_reset function
From: David Miller @ 2017-01-20 16:06 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-234-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Fri, 20 Jan 2017 14:33:55 +0800
> The rtl8152_post_reset() should sumbit rx urb and interrupt transfer,
> otherwise the rx wouldn't work and the linking change couldn't be
> detected.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] ipv6: seg6_genl_set_tunsrc() must check kmemdup() return value
From: David Lebrun @ 2017-01-20 16:06 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev
In-Reply-To: <1484927862.16328.123.camel@edumazet-glaptop3.roam.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
On 01/20/2017 04:57 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> seg6_genl_get_tunsrc() and set_tun_src() do not handle tun_src being
> possibly NULL, so we must check kmemdup() return value and abort if
> it is NULL
>
> Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: David Lebrun <david.lebrun@uclouvain.be>
> ---
> net/ipv6/seg6.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
> index b172d85c650a376f541ea05d72046c76b8404303..a855eb325b030a666fe92c56a2d432c77d9dfe7a 100644
> --- a/net/ipv6/seg6.c
> +++ b/net/ipv6/seg6.c
> @@ -176,6 +176,8 @@ static int seg6_genl_set_tunsrc(struct sk_buff *skb, struct genl_info *info)
>
> val = nla_data(info->attrs[SEG6_ATTR_DST]);
> t_new = kmemdup(val, sizeof(*val), GFP_KERNEL);
> + if (!t_new)
> + return -ENOMEM;
>
> mutex_lock(&sdata->lock);
>
>
>
Thanks :)
Acked-by: David Lebrun <david.lebrun@uclouvain.be>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply
* Re: [PATCH] stmmac: adding EEE to GMAC4
From: Joao Pinto @ 2017-01-20 15:58 UTC (permalink / raw)
To: Rayagond Kokatanur, Joao Pinto
Cc: David Miller, Giuseppe Cavallaro, Alexandre Torgue, linux-kernel,
netdev
In-Reply-To: <CAJ3bTp7XHNd+oc9QsX25iX_umARFjSveehPY_a+quJBnj-okkA@mail.gmail.com>
Sorry, please ignore, wrong patch file.
Joao Pinto
Às 6:01 AM de 1/19/2017, Rayagond Kokatanur escreveu:
> On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>> This patch adds Energy Efficiency Ethernet to GMAC4.
>>
>> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 12 +++++
>> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59 +++++++++++++++++++++++
>> 2 files changed, 71 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> index b524598..73d1dab 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> @@ -90,6 +90,18 @@ enum power_event {
>> power_down = 0x00000001,
>> };
>>
>> +/* Energy Efficient Ethernet (EEE) for GMAC4
>> + *
>> + * LPI status, timer and control register offset
>> + */
>> +#define GMAC4_LPI_CTRL_STATUS 0xd0
>> +#define GMAC4_LPI_TIMER_CTRL 0xd4
>> +
>> +/* LPI control and status defines */
>> +#define GMAC4_LPI_CTRL_STATUS_LPITXA BIT(19) /* Enable LPI TX Automate */
>> +#define GMAC4_LPI_CTRL_STATUS_PLS BIT(17) /* PHY Link Status */
>> +#define GMAC4_LPI_CTRL_STATUS_LPIEN BIT(16) /* LPI Enable */
>> +
>> /* MAC Debug bitmap */
>> #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
>> #define GMAC_DEBUG_TFCSTS_SHIFT 17
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> index ecfbf57..02eab79 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info *hw,
>> GMAC_ADDR_LOW(reg_n));
>> }
>>
>> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + /* Enable the link status receive on RGMII, SGMII ore SMII
>> + * receive path and instruct the transmit to enter in LPI
>> + * state.
>> + */
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA);
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +
>> + if (link)
>> + value |= GMAC4_LPI_CTRL_STATUS_PLS;
>> + else
>> + value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
>
> If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
> should AND 0x3ff.
>
> int value = ((tw & 0xffff)) | ((ls & 0x3ff) << 16);
>
>> +
>> + /* Program the timers in the LPI timer control register:
>> + * LS: minimum time (ms) for which the link
>> + * status from PHY should be ok before transmitting
>> + * the LPI pattern.
>> + * TW: minimum time (us) for which the core waits
>> + * after it has stopped transmitting the LPI pattern.
>> + */
>> + writel(value, ioaddr + GMAC4_LPI_TIMER_CTRL);
>> +}
>> +
>> static void dwmac4_set_filter(struct mac_device_info *hw,
>> struct net_device *dev)
>> {
>> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
>> .pmt = dwmac4_pmt,
>> .set_umac_addr = dwmac4_set_umac_addr,
>> .get_umac_addr = dwmac4_get_umac_addr,
>> + .set_eee_mode = dwmac4_set_eee_mode,
>> + .reset_eee_mode = dwmac4_reset_eee_mode,
>> + .set_eee_timer = dwmac4_set_eee_timer,
>> + .set_eee_pls = dwmac4_set_eee_pls,
>> .pcs_ctrl_ane = dwmac4_ctrl_ane,
>> .pcs_rane = dwmac4_rane,
>> .pcs_get_adv_lp = dwmac4_get_adv_lp,
>> --
>> 2.9.3
>>
>
>
>
^ permalink raw reply
* Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving
From: David Miller @ 2017-01-20 16:03 UTC (permalink / raw)
To: jasowang; +Cc: rolf.neugebauer, netdev, mst, linux-kernel, virtualization
In-Reply-To: <1484893962-7614-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 20 Jan 2017 14:32:42 +0800
> Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
> xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
> fixing this by adding a hint (has_data_valid) and set it only on the
> receiving path.
>
> Cc: Rolf Neugebauer <rolf.neugebauer@docker.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks Jason.
^ permalink raw reply
* [PATCH net] ipv6: seg6_genl_set_tunsrc() must check kmemdup() return value
From: Eric Dumazet @ 2017-01-20 15:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, David Lebrun
From: Eric Dumazet <edumazet@google.com>
seg6_genl_get_tunsrc() and set_tun_src() do not handle tun_src being
possibly NULL, so we must check kmemdup() return value and abort if
it is NULL
Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Lebrun <david.lebrun@uclouvain.be>
---
net/ipv6/seg6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
index b172d85c650a376f541ea05d72046c76b8404303..a855eb325b030a666fe92c56a2d432c77d9dfe7a 100644
--- a/net/ipv6/seg6.c
+++ b/net/ipv6/seg6.c
@@ -176,6 +176,8 @@ static int seg6_genl_set_tunsrc(struct sk_buff *skb, struct genl_info *info)
val = nla_data(info->attrs[SEG6_ATTR_DST]);
t_new = kmemdup(val, sizeof(*val), GFP_KERNEL);
+ if (!t_new)
+ return -ENOMEM;
mutex_lock(&sdata->lock);
^ permalink raw reply related
* Re: [PATCH] stmmac: adding EEE to GMAC4
From: Joao Pinto @ 2017-01-20 15:49 UTC (permalink / raw)
To: Rayagond Kokatanur, Joao Pinto
Cc: David Miller, Giuseppe Cavallaro, Alexandre Torgue, linux-kernel,
netdev
In-Reply-To: <CAJ3bTp7XHNd+oc9QsX25iX_umARFjSveehPY_a+quJBnj-okkA@mail.gmail.com>
Hi Rayagond,
Às 6:01 AM de 1/19/2017, Rayagond Kokatanur escreveu:
> On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>> This patch adds Energy Efficiency Ethernet to GMAC4.
>>
>> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 12 +++++
>> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59 +++++++++++++++++++++++
>> 2 files changed, 71 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> index b524598..73d1dab 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> @@ -90,6 +90,18 @@ enum power_event {
>> power_down = 0x00000001,
>> };
>>
>> +/* Energy Efficient Ethernet (EEE) for GMAC4
>> + *
>> + * LPI status, timer and control register offset
>> + */
>> +#define GMAC4_LPI_CTRL_STATUS 0xd0
>> +#define GMAC4_LPI_TIMER_CTRL 0xd4
>> +
>> +/* LPI control and status defines */
>> +#define GMAC4_LPI_CTRL_STATUS_LPITXA BIT(19) /* Enable LPI TX Automate */
>> +#define GMAC4_LPI_CTRL_STATUS_PLS BIT(17) /* PHY Link Status */
>> +#define GMAC4_LPI_CTRL_STATUS_LPIEN BIT(16) /* LPI Enable */
>> +
>> /* MAC Debug bitmap */
>> #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
>> #define GMAC_DEBUG_TFCSTS_SHIFT 17
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> index ecfbf57..02eab79 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info *hw,
>> GMAC_ADDR_LOW(reg_n));
>> }
>>
>> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + /* Enable the link status receive on RGMII, SGMII ore SMII
>> + * receive path and instruct the transmit to enter in LPI
>> + * state.
>> + */
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA);
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +
>> + if (link)
>> + value |= GMAC4_LPI_CTRL_STATUS_PLS;
>> + else
>> + value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
>
> If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
> should AND 0x3ff.
>
> int value = ((tw & 0xffff)) | ((ls & 0x3ff) << 16);
You are absolutely right. LS is related to 25:16 (10 bits).
Thank you for checking it!
Joao
>
>> +
>> + /* Program the timers in the LPI timer control register:
>> + * LS: minimum time (ms) for which the link
>> + * status from PHY should be ok before transmitting
>> + * the LPI pattern.
>> + * TW: minimum time (us) for which the core waits
>> + * after it has stopped transmitting the LPI pattern.
>> + */
>> + writel(value, ioaddr + GMAC4_LPI_TIMER_CTRL);
>> +}
>> +
>> static void dwmac4_set_filter(struct mac_device_info *hw,
>> struct net_device *dev)
>> {
>> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
>> .pmt = dwmac4_pmt,
>> .set_umac_addr = dwmac4_set_umac_addr,
>> .get_umac_addr = dwmac4_get_umac_addr,
>> + .set_eee_mode = dwmac4_set_eee_mode,
>> + .reset_eee_mode = dwmac4_reset_eee_mode,
>> + .set_eee_timer = dwmac4_set_eee_timer,
>> + .set_eee_pls = dwmac4_set_eee_pls,
>> .pcs_ctrl_ane = dwmac4_ctrl_ane,
>> .pcs_rane = dwmac4_rane,
>> .pcs_get_adv_lp = dwmac4_get_adv_lp,
>> --
>> 2.9.3
>>
>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] at803x: double check SGMII side autoneg
From: Zefir Kurtisi @ 2017-01-20 15:31 UTC (permalink / raw)
To: Timur Tabi, netdev; +Cc: andrew, f.fainelli
In-Reply-To: <44eb0b95-1868-396b-db6b-18d233eff853@codeaurora.org>
On 01/20/2017 03:38 AM, Timur Tabi wrote:
> Zefir Kurtisi wrote:
>> It always operates at 675MHz, which with two lines gives 1.25Gbps,
>> which at 10/8 coding gives exactly 1Gbps net data rate. If the
>> at803x's copper side autonegotiates to 1Gbps, the bits traversing
>> over the SGMII match the copper side 1:1. In case the copper side
>> autonegotiates to e.g. 100Mbps, each bit at the copper side on the
>> SGMII bus is replicated and sent 10x times - or 100x times in case of
>> 10Mbps. The MAC side of the ETH needs to be aware of how the SGMII
>> data has to be interpreted, and this is why you have to set the bits
>> you are referring to.
>
> So does this mean that the SGMII link should not be autonegotiated? I currently
> have this code:
>
> if (phydev->autoneg == AUTONEG_ENABLE) {
> val &= ~(FORCE_AN_RX_CFG | FORCE_AN_TX_CFG);
> val |= AN_ENABLE;
> writel(val, phy->base + EMAC_SGMII_PHY_AUTONEG_CFG2);
> } else {
> ...
>
> So if the external PHY is set to autonegotiate, then the SGMII block is set to
> also negotiate. Now that I think about it, this seems wrong. And in fact, I'm not
> sure how it works. It seems that the this only makes sense if the SGMII block is
> configured to act as the only PHY. This is an option that the hardware supports
> but my driver does not. So perhaps I should remove this part, and just do the rest:
>
>
> u32 speed_cfg;
>
> switch (phydev->speed) {
> case SPEED_10:
> speed_cfg = SPDMODE_10;
> break;
> case SPEED_100:
> speed_cfg = SPDMODE_100;
> break;
> case SPEED_1000:
> speed_cfg = SPDMODE_1000;
> break;
> default:
> return -EINVAL;
> }
>
> if (phydev->duplex == DUPLEX_FULL)
> speed_cfg |= DUPLEX_MODE;
>
> val &= ~AN_ENABLE;
> writel(speed_cfg, phy->base + EMAC_SGMII_PHY_SPEED_CFG1);
> writel(val, phy->base + EMAC_SGMII_PHY_AUTONEG_CFG2);
>
> Should I be doing this all the time?
>
Hm, that might be product dependent. From my experience with the gianfar/at8031
this is what I can share: there is a known flaw in some revisions of the eTSEC
that causes random failures in SGMII autonegotiation. As a workaround FSL proposes
to use fixed speed. I spent lots of time getting this working, but in the end it
turned out it does not. Setting fixed Gbps speed on both ends of the link is
reported to be ok (link failure bits clean, page transmitted ok), but no data goes
through the link.
>From a source I can't remember atm I was told that autonegotiation is mandatory
for SGMII, therefore I believe there is no need to change the autoneg bits for
SGMII in your case. I'd assume that resetting the link before setting the speed
value should be enough, i.e. the second write to EMAC_SGMII_PHY_AUTONEG_CFG2 might
be useless. YMMV
>> To track down who is causing the additional message, I would proceed
>> with following technique that helped me dig down a similar problem:
>> since you control the events in question and there is no risk of
>> flooding the kernel log, in the top of phy.c::phy_print_status() add
>> a dump_stack() call. In the debug log ensure that all of the traces
>> end up in the same phydev->adjust_link() callback handler (in your
>> case emac_adjust_link()).
>
> That's a good idea, thanks.
>
As Florian responded, it seems you need to double check for real changes before
printing the link status to get rid of the double printed notifications.
Good Luck.
^ permalink raw reply
* Re: [PATCH] inet: don't use sk_v6_rcv_saddr directly
From: Josef Bacik @ 2017-01-20 14:18 UTC (permalink / raw)
To: davem, tom, netdev, kafai
In-Reply-To: <1484866066-25407-1-git-send-email-jbacik@fb.com>
On Thu, Jan 19, 2017 at 5:47 PM, Josef Bacik <jbacik@fb.com> wrote:
> When comparing two sockets we need to use inet6_rcv_saddr so we get a
> NULL
> sk_v6_rcv_saddr if the socket isn't AF_INET6, otherwise our
> comparison function
> can be wrong.
>
> Fixes: 637bc8b ("inet: reset tb->fastreuseport when adding a
> reuseport sk")
> Signed-off-by: Josef Bacik <jbacik@fb.com>
> ---
> net/ipv4/inet_connection_sock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/inet_connection_sock.c
> b/net/ipv4/inet_connection_sock.c
> index 096a085..a336c42 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -99,7 +99,7 @@ int inet_rcv_saddr_equal(const struct sock *sk,
> const struct sock *sk2,
> #if IS_ENABLED(CONFIG_IPV6)
> if (sk->sk_family == AF_INET6)
> return ipv6_rcv_saddr_equal(&sk->sk_v6_rcv_saddr,
> - &sk2->sk_v6_rcv_saddr,
> + inet6_rcv_saddr(sk2),
> sk->sk_rcv_saddr,
> sk2->sk_rcv_saddr,
> ipv6_only_sock(sk),
> --
> 2.5.5
Sorry I forgot to tag this, it's for net-next. Thanks,
Josef
^ permalink raw reply
* RE: [PATCHv3 net-next 3/4] sctp: add support for generating stream reconf add incoming/outgoing streams request chunk
From: David Laight @ 2017-01-20 14:50 UTC (permalink / raw)
To: 'Xin Long', network dev, linux-sctp@vger.kernel.org
Cc: Marcelo Ricardo Leitner, Neil Horman, Vlad Yasevich,
davem@davemloft.net
In-Reply-To: <0d8d8e5482205ead64a2cfd2d414e918ce5602dd.1484845510.git.lucien.xin@gmail.com>
From: Xin Long
> Sent: 19 January 2017 17:19
> This patch is to define Add Incoming/Outgoing Streams Request
> Parameter described in rfc6525 section 4.5 and 4.6. They can
> be in one same chunk trunk as rfc6525 section 3.1-7 describes,
> so make them in one function.
...
> +struct sctp_strreset_addstrm {
> + sctp_paramhdr_t param_hdr;
> + __u32 request_seq;
> + __u16 number_of_streams;
> + __u16 reserved;
> +} __packed;
...
> + addstrm.param_hdr.type = SCTP_PARAM_RESET_ADD_OUT_STREAMS;
> + addstrm.param_hdr.length = htons(size);
> + addstrm.number_of_streams = htons(out);
> + addstrm.request_seq = htonl(asoc->strreset_outseq);
> + addstrm.reserved = 0;
> +
> + sctp_addto_chunk(retval, size, &addstrm);
Since you allocate the sctp_strreset_addstrm structure on stack
there is no requirement for it to be packed.
David
^ permalink raw reply
* [PATCH] 6lowpan: use rb_entry()
From: Geliang Tang @ 2017-01-20 14:36 UTC (permalink / raw)
To: Alexander Aring, Jukka Rissanen, David S. Miller
Cc: Geliang Tang, linux-bluetooth, linux-wpan, netdev, linux-kernel
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
net/6lowpan/nhc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/6lowpan/nhc.c b/net/6lowpan/nhc.c
index 7008d53..4fa2fdd 100644
--- a/net/6lowpan/nhc.c
+++ b/net/6lowpan/nhc.c
@@ -27,8 +27,8 @@ static int lowpan_nhc_insert(struct lowpan_nhc *nhc)
/* Figure out where to put new node */
while (*new) {
- struct lowpan_nhc *this = container_of(*new, struct lowpan_nhc,
- node);
+ struct lowpan_nhc *this = rb_entry(*new, struct lowpan_nhc,
+ node);
int result, len_dif, len;
len_dif = nhc->idlen - this->idlen;
@@ -69,8 +69,8 @@ static struct lowpan_nhc *lowpan_nhc_by_nhcid(const struct sk_buff *skb)
const u8 *nhcid_skb_ptr = skb->data;
while (node) {
- struct lowpan_nhc *nhc = container_of(node, struct lowpan_nhc,
- node);
+ struct lowpan_nhc *nhc = rb_entry(node, struct lowpan_nhc,
+ node);
u8 nhcid_skb_ptr_masked[LOWPAN_NHC_MAX_ID_LEN];
int result, i;
--
2.9.3
^ permalink raw reply related
* [PATCH] net/mlx4: use rb_entry()
From: Geliang Tang @ 2017-01-20 14:36 UTC (permalink / raw)
To: Yishai Hadas; +Cc: Geliang Tang, netdev, linux-rdma, linux-kernel
In-Reply-To: <c6a809ea5820242a4ae126b03cdcd910a36e5cae.1484817152.git.geliangtang@gmail.com>
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 1822382..6da6e01 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -236,8 +236,8 @@ static void *res_tracker_lookup(struct rb_root *root, u64 res_id)
struct rb_node *node = root->rb_node;
while (node) {
- struct res_common *res = container_of(node, struct res_common,
- node);
+ struct res_common *res = rb_entry(node, struct res_common,
+ node);
if (res_id < res->res_id)
node = node->rb_left;
@@ -255,8 +255,8 @@ static int res_tracker_insert(struct rb_root *root, struct res_common *res)
/* Figure out where to put new node */
while (*new) {
- struct res_common *this = container_of(*new, struct res_common,
- node);
+ struct res_common *this = rb_entry(*new, struct res_common,
+ node);
parent = *new;
if (res->res_id < this->res_id)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v7 11/13] net: ethernet: aquantia: Ethtool support
From: Rami Rosen @ 2017-01-20 14:33 UTC (permalink / raw)
To: Netdev
In-Reply-To: <733a83f4-892e-f77b-3c90-8a3a26642e3e@gmail.com>
+1
Many times this information is needed, and "ethtool -i" is a
convenient way to get it.
Rami Rosen
^ permalink raw reply
* [PATCH] sock: use hlist_entry_safe
From: Geliang Tang @ 2017-01-20 14:27 UTC (permalink / raw)
To: David S. Miller; +Cc: Geliang Tang, netdev, linux-kernel
Use hlist_entry_safe() instead of open-coding it.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
include/net/sock.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 4077ec4..c4e1caf1 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -544,8 +544,7 @@ static inline struct sock *sk_nulls_head(const struct hlist_nulls_head *head)
static inline struct sock *sk_next(const struct sock *sk)
{
- return sk->sk_node.next ?
- hlist_entry(sk->sk_node.next, struct sock, sk_node) : NULL;
+ return hlist_entry_safe(sk->sk_node.next, struct sock, sk_node);
}
static inline struct sock *sk_nulls_next(const struct sock *sk)
--
2.9.3
^ 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